hivemind-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Wannheden <knut.wannhe...@gmail.com>
Subject Re: Using Hivemind in an existing application
Date Fri, 22 Jul 2005 09:32:31 GMT
Catalin,

On 7/22/05, Catalin Grigoroscuta <c.grigoroscuta@moodmedia.ro> wrote:
> 
> I'm working on a (quite large) application, split in several modules,
> and I want to start managing inter-modules dependencies using Hivemind
> (sort of like Eclipse plugin extension mechanism).
> It seems like Hivemind configuration-point and service mechanism is
> exactly what I need (although I would need module lifecycle, but is not
> such important as I already have built a mechanism for that).
> 

As you've correctly noticed HiveMind doesn't define and manage a
lifecycle for modules. This in turn means that if you want to add /
remove / update a module you will have to recreate the HiveMind
Registry. I just thought you should be aware of that, in case you not
already were :-)

> I want to add hivemind little by little, without major changes in the
> application - in other words, I need an on-the-fly migration, not a
> stop-and-change-everything one. The non-intrusiveness principle of
> Hivemind is great in this aspect.
> 
> However, here are the first issues I ran into:
> 
> 1. I have something similar to services, implemented as singletons. I
> want to change those to hivemind services with singletons model, but
> this should be transparent for the rest of the application - i.e. if
> other parts of the code use this as a normal singleton, it should work.
> The problem is in telling Hivemind to get the service implementation
> using the singleton getter method (called getInstance). Hivemind seems
> to always want to instantiate the class itself using a constructor, or
> my constructor is private and must remain so.
> What I would need is a way to specify in <invoke-factory> to use the
> static method (getInstance) of the class to instantiate it instead of
> the constructor.
> 

You could of course implement your own service implementation factory.
It is currently although still somewhat cumbersome to implement a
factory which should extend the features of BuilderFactory. We are
looking into simplifying this. If your factory OTOH doesn't require
many features (e.g. no autowiring) then it's a simple task.

Another option you have is to make the HiveMind Registry statically
available and have the various getInstance() methods delegate to that.

> 2. Same problem with configuration points: I have main configuration
> classes implemented as singletons, but there is no way in <rules>
> section to put on the stack an object created by a static method of a
> class instead of an object created using constructor.
> 

Using <custom> you can use your custom rules. Or again, your singleton
accessors could delegate to the HiveMind Registry...

> 3. A problem with <set-configuration>: the setter method is expected to
> receive a List object. This is correct for configuration points with
> 0..n cardinality, but there are some issues with configuration points
> with occurs=1.
> In the (future) service class, I already have a method
> setConfiguration(Configuration), which is called now by hand. If I want
> to make that class a service, and Configuration a configuration point, I
> would have to change the method signature setConfiguration(List), and
> the list would always have one element. But this will make the service
> class look quite ugly, and I think it's also against the
> non-intrusiveness principle of Hivemind.
> 

You're the second person to ask about this in the last few days. This
is definitely on our TODO list.

Regards,

--knut

---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org


Mime
View raw message