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]
