Hi,
Thanks for your answer, but I have some more questions:
1. If I implement my own factory, do I have to implement everything
that's already implemented in the default factory, regarding service
initialization? I mean, I still need to use the <set-configuration> and
all the other service initialization logic. I only want to avoid using
the constructor, but still use the initialization mechanism.
Could you pint out an example of writing such a factory?
2. In point two, I meant some sort of <create-object> that uses a static
getInstance method instead of calling the constructor.
3. Overloading the setter does not work. It was the first thing I tried.
Somehow, it still finds the other setter. The only thing that works is
implementing a setter with a different name (like
setConfigurationByHivemind).
Anyway, thanks for the constructor tip, it might be what I needed.
Thank you,
Catalin
[EMAIL PROTECTED] wrote:
Hi,
For point 1 just write your own factory (implementing
ServiceImplementationFactory) and use getInstance() to return the
instance from the createCoreServiceImplementation method.
I'm not sure I understand point 2, but something similar might apply.
For 3, I'm not sure adding one overloaded method constitutes ugliness,
but you could inject the configuration in the constructor instead if you
prefer (<configuration> instead of <set-configuration>).
Good luck
John
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.
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.
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.
These are all the (major) problems I ran into.
Could somebody tell me if there are Hivemind issues indeed, or if I am
using Hivemind in the wrong way? And maybe there are some workarounds...
Thank you,
Catalin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
