The configuration has the following schema: <contribution id="buildmagic.includemodule"> <include path="pathInClassPath" (optional) setup-id=".."/> or <include-default module-id="...." path=""/> </contribution>
The custom RegistryBuilder gets when constructed an setup-id matcher. Module-Descritpors defined in <include> are added to the wrapped RegistryBuilder if they have no setup-id or the setup-id matches. Modules defined in <include-default> are only added if no module with the given id has been added through the default location or through <include>. The <include-default> is for module designers to provide default services contributions.
This aproache has the major disadvantage that I have to maintain an extra module-xml for each different config/module pair - so I'd very apriciate Howards proposal. On the other side the aproache makes it possible to split modules in a 'Hivemind way' - no extra xmls or so - and additional to make the setup very flexible - not only service implementations but also contributions etc for different setups. It's more flexible and less resource intensive. By using a magic config point it also ahs the nice side affect that the way in which the different modules where loaded is directly reflected in the registry.
On Mon, 5 Apr 2004 16:32:08 -0400, Howard M. Lewis Ship <[EMAIL PROTECTED]> wrote:
Seems like what we need is *one* extra layer of indirection.
Currently, you can use the BuilderFactory to get a reference to a particular service. That is,
<set-service> means, "lookup service foo.Bar and assign it to this property."
I think, for these cases, we need to define a ServiceLookup interface whose job is to provide the
actual service to use.
BuilderFactory could have a <set-indirect-service> element, perhaps, that says: "go to service
foo.Bar and ask it what service to plug into this property".
It would then be simple to provide implementations of the ServiceLookup interface that used whatever
technique was appropriate to find the actual service.
-- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator, Tapestry: Java Web Components http://howardlewisship.com
-----Original Message----- From: Achim Huegen [mailto:[EMAIL PROTECTED] Sent: Monday, April 05, 2004 3:56 PM To: Jakarta Commons Developers List Subject: Re: [HiveMind] Separating service declarations from their implementations
> You solution is pretty much what I've always envisioned. > > The problem isn't the indirection ... its the *selection*. > ... > Putting any specific solution into the framework creates a kind of lock > that will be hard to break > in the future. Providing a reasonably flexible solution in the standard > library or (the forthcoming) > contributions library is a better approach ... the less in the core > framework, the better. The > HiveMind framework is supposed to be the bare minimum needed to > construct more elaborate solutions > ... the more that's in the framework itself, the more locked into a > specific solution we become, and > that's a trap to avoid!
I regard switching of services as a very important feature which shouldn't be completely moved to the contributions library. I fear that without direct support in the core, it could be very expensive to setup in terms of needed configurations, factories etc. So I would suggest that the core libary at least "acknowledges" that there is the need to switch between different implementations, but the selection mechanism is left to the user. For example we could allow the definition of multiple implementations of a service :
<service-point id="Simple" interface="hivemind.test.services.SimpleService"> </service-point>
<implementation service-id="Simple" id="impl1" > <create-instance class="hivemind.test.services.impl.SimpleServiceImpl1"/> </implementation>
<implementation service-id="Simple" id="impl2" > <create-instance class="hivemind.test.services.impl.SimpleServiceImpl2"/> </implementation>
The first time this service is used, a special service broker (you already mentioned this one in a previous mail) is used for selecting the right implementation. The default (core) implementation of the broker could just raise an exception, or select the first implementation found. This is the current behaviour in this case. If there is a well defined interface for changing the implementation of the service broker itself, the user could choose from different selection strategies that are available in the contribution library. Properties, configuration or environment variable, choose whatever you want and configure it at a central location for all of your services.
This solution is not too specific but eases things a lot.
Achim Huegen
--------------------------------------------------------------------- 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]
--
Christian Essl
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
