Noel J. Bergman wrote:
Stefano Bagnara wrote:
init(Config) where Config contains a Context that in turn contains a
mean to retrieve services is just an obfuscated way to use the Avalon
serviceLocator pattern (service(ServiceManager s)).
Well, you can say obfuscated and I can say that it is the commmon mechanism
used throughout the J2EE specifications for configuring container managed
components. Passing a configuration object from which one can get to a
context object is a common pattern, along with JNDI. But we can agree that
we can have one init() instead of N setter methods, where N is unbounded.
Yes, JNDI exists since 1997. The fact that is a specification and that
is used in J2EE specs does not give it much more credits. You know that
most of the J2EE specs has been abandoned in newer versions because they
were not so easy to use.
Btw, not another religious war, we'll vote about this.
Imho dependencies have to be shown in the clearest of the ways.
Clear, yes. But everytime you add a new dependency you have to change the
API.
JNDI is another service locator, but less powerful than ServiceManager.
JNDI is more powerful than the Avalon Service Manager, if one really
understands it.
Well, I used JNDI since 2000, but I'm not sure I really understand it:
What I think is that it is always feasible to write a ServiceManager
implementation that lookups the services in JNDI while it is not so easy
(not possible at all) to write a JNDI context that takes the objects
from the ServiceManager that would be provided to that component.
Can you make me an example of what you can do with JNDI that cannot be
done with a JNDI implementation of the ServiceManager?
I'm against the direct use of JNDI for services lookup: we fortunately
are not under the J2EE umbrella and we can skip it.
The only way I know to correctly manage JNDI contexts and having
flexible environments is by complex classloader hierarchies: and I think
this would slow down the entire James development.
As a summary my main argument is: if we use service injection or service
locator injection we can pass an implementation that make use of JNDI,
while viceversa is not possible.
I'll start a vote for this: as this have a great impact on our codebase
and we can't discuss months about religious concepts.
In fact with Avalon Serviceable it is easy to have 2 instances of the
same component configured in totally different ways because they receive
a different ServiceManager. To do that with JNDI you add one level of
complexity.
The container is responsible for providing the appropriate InitialContext to
the contained component. No extra levels of anything.
Not all components are created by the container itself: we may have
components created by other components (we have them).
It would be much better to introduce our own "serviceable" interface
and if you like JNDI use JNDI inside the ServiceManager you pass
to the object. This way the plain objects does not depends on JNDI
but only on the serviceable interface.
Servicable is just a means of providing the lookup service (Service
Manager). If we really want to drink the DI koolaid, we should add a setter
for every service. Then the container can inspect everyone to see what
service(s) they need.
--- Noel
In fact the proposal was to refactor the current service() methods to
lookup the services and use public setters to inject them, so in the
future we can write a ServiceInjector (see Bernd message from yesterday)
that skip the service method and directly search for setters (either via
reflection of setter names or looking for enabling interfaces).
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
