james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: svn commit: r420948 - in /james/server/trunk/src/java/org/apache/james: smtpserver/ transport/ userrepository/ util/connection/
Date Thu, 13 Jul 2006 08:00:21 GMT
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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message