Catalin, On 7/22/05, Catalin Grigoroscuta <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
