avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@citi-us.com>
Subject RE: [PROPOSAL] Context Defined
Date Mon, 09 Dec 2002 13:39:18 GMT
> From: Noel J. Bergman [mailto:noel@devtech.com]
> > > Which you could do as:
> > >   "urn:NID:NSS"
> > >   "jini:<jini lookup info>"
> > >   "role:<role-descriptor>"
> > with a single interface exposed to the invoking object.
> > Theres already a framework for that - JNDI.
> <<grin>> You noticed that, did you. :-)  Having written both 
> JNDI clients
> and JNDI service providers, it wouldn't bother me to use JNDI 
> as a standard.
> It is a bit of overkill, but I could live with it.  However, 
> since it can
> impact the ability to get small, my thought was to limit the initial
> requirement to the composite name lookup aspect, which is 
> fairly trivial to
> code (and delegate).

This is a point we agonized over in the past.  JNDI has the
benefit of being #1 a standard and #2 familiar contracts.
It also has the ability to be quite resource intensive depending
on what is going on behind the scenes.

Beyond the heavy-weight argument, there are a couple other reasons
why we finally decided not to go with JNDI:

*  No clear separation between obtaining a reference to a service
   or data.

*  Precludes effective J2ME programming (phones do not have near
   the capacity as a PDA--although they are getting more powerful).

*  The biggest reason is no IoC.  The container has to set them up
   statically, and either run components in separate threads or unify
   the namespace.  In the end, the only way to have a separate
   namespace for all the components would be generally unworkable
   in the real world.

I'm sure in the archives you will find a very interesting debate
between Peter, Fede, and I on the topic.  In fact, Peter and I
managed to convince each other so well of the other person's
viewpoint that we flip-flopped positions once or twice.

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message