geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Monson-Haefel <>
Subject Re: [jndi] Have we found a JNDI impl yet?
Date Fri, 29 Aug 2003 11:25:32 GMT
On 8/29/03 12:36 AM, in article, "Alex Blewitt"
<> wrote:

> On Friday, Aug 29, 2003, at 08:55 Europe/London, Richard Monson-Haefel
> wrote:
>> All this sounds great, Alex, but I¹m a little concerned that its
>> overkill for the JNDI ENC.  The JNDI ENC is totally static at runtime
>> (per deployment) and therefore a very simple, and fast, in-memeory
>> caching strategy works best.
> Is this necessarily the case? It has to be able to start up EJBs and
> write into the JNDI ENC during runtime; if it is going to support
> on-the-fly deployment of other EJBs, I'd say that it must be able to
> handle additional extras inserted in at runtime.

Well, not really.  Each deployment's ENC is static, so if you deploy a bean,
the container simply creates its ENC at that moment, but once its created
its static. It cannot be changed by the bean nor can any values be modified,
bound or unbound. 

> I also don't see why code cannot necessarily register additional things
> in the JNDI ENC, such as other databases populated by an initialisation
> code. I know that it's not likely that this will be the case, but
> assuming that it is totally static seems a wrong decision.

That's just the way it is. J2EE specifies that the JNDI ENC is read-only. If
you want to access a non-static JNDI resource, you must connect to it

> Of course caching is always likely to provide better performance in any
> case, but it still does not have to be static.

If you want it to be conformant it does.

Don't get me wrong. I think we need LDAP functionality and I would like
nothing better than to see LDAPd used in Geronimo, I just don't think its a
proper fit for the JNDI ENC unless it provides the kind of caching that I
discussed earlier.

> Alex (B).

View raw message