Hivemind integration and Refactoring in GData Server

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Hivemind integration and Refactoring in GData Server

Simon Willnauer
Hello all,

I already send some infromations about my plans of using a IoC
container for GData Server which adds some features to the whole
system and removes some testing and development pain. Here comes a
list of new implementations and refactorings:

1. Adding binary webservice support
I did implement a generic solution for the hessian webservice protocol
to enable users to expose almost every interface which exist inside
the server as a webservice. this aims also to replication of stateful
data like login tokens within a cluster or administration features
like adding feeds or accounts. The current REST approach like Solr
uses will remain but be refactored (see below).

2. Dependency Injection for the core classes
Currently there is a Registry holding references to the "modules" and
their services configured in the server config. These services are
created at server startup and can be looked up by other parts of the
application. This creates a strong dependency on the Registry overall
the classes and causes some pain in tests. So I wanna remove this
registry completely and create dependencies via setter methods
controlled by the IoC container. The default container will be apache
hivemind but using pico, spring or whatever is still possible. (little
metadata overhead ;)

I guess I have to touch a lot of classes so there will be a lot of
commits due to that.

3. Default stable persistence layer
I have to work on the persitence layer an will remove the lucene based
persistence which is not a database as we all know. I suffer from
performance problems due to the extensive io. This is not what lucene
has to deal with in my eyes. Currently there is a DB4O impl. which is
more or less a hack due to the short amount of time I had within SoC,
so this will be refactored by creating a clean DAO layer behind the
storage facade.Other persistence layers can still be implemented.

4. Refactoring of the REST admin func.

Currently there is a mix of patterns used for handling the requests
wich is not a good idea so I will pick up the solr approach of
different render classes creating the output and little
requesthandlers talking to the API and the storage. calling a renderer
to create the output. Providing this functionality only via
webservices is not a good idea as you always have problems with
different languages. If someone wants to expose a admin interface via
WS it is just a single line in the hivemind descriptor.

5. Admin application
as soon as all these stuff is done (that could take a while as I have
to study) I will create the admin application either as a extra webapp
or included in the server. In the second case this will be plugable.
No deeper thoughts about that so far.

Any suggestions and / or ideas are highly appreciated.

best regards Simon

To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]