geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@iq80.com>
Subject Re: Implementing Global JNDI
Date Wed, 24 May 2006 02:04:44 GMT
On May 23, 2006, at 5:19 PM, David Jencks wrote:

>
> On May 23, 2006, at 6:28 AM, Krishnakumar B wrote:
>
>> Hi,
>>
>> I have a few doubts related to implementation of global jndi.
>>
>> * Currently we have java:comp/env stored in Local JNDI. In Global  
>> JNDI
>> should objects be bound using a different namespace e.g) java: or
>> java:global?
>
> IIUC java: is reserved by the j2ee spec for what it requires: thus  
> IMO we should use something else.  IIRC the original global jndi  
> context used geronimo:  I'm OK with that or maybe global:.

IIRC some servers use just "/foo/bar" with no context.  If I am  
correct, we should support that also (but not the default).

>>
>> * When we implement global JNDI we have some entries in Global and  
>> All
>> entries related to application in Local. When a user creates a  
>> context
>> he needs to get from either global or local based on what he needs.
>> Would it be right for lookup code to decide from where to fetch the
>> entry based on how the Context is created?
>>
>> for e.g) if i say InitialContext iniCtx = new
>> InitialContext("java:comp/env"); fetch from local
>> and if InitialContext iniCtx = new InitialContext("java:global");
>> fetch from global
>
> I'm not sure what you're asking about here.  Unless you do  
> something screwy to link one of these to the other, the contents of  
> these contexts will be completely unrelated.

Looking at the JavaDocs for InitialContext, it does not have a  
constructor that takes a String.  Did you mean:

   Context context = (Context) new InitialContext().lookup("java:comp/ 
env");
   Context context = (Context) new InitialContext().lookup("global:");

>> * Currently in Local JNDI we store Resource References. Should global
>> JNDI also use the same approach or can we use Object references for
>> e.g) DataSource reference directly put in JNDI
>
> For j2ee components I think we should bind the same kinds of  
> References in the global jndi tree as we bind in the current java:  
> context.  What we bind for stuff that can't get into the java:  
> context needs more thought: it probably depends on what it is.  Of  
> course if the context is not read-only an app can bind whatever it  
> wants wherever it wants, thus bringing to mind the need for  
> security and permissions for this stuff.

I don't think we can use the current Reference object we bind into  
our read only context because they do cache the value and never  
release it.  It is expected that the referece will be GCed when the  
J2EE application is unloaded.  It shouldn't be hard to either turn  
off the cache or to register listener for the reference target life- 
cycle events.

>> Would appreciate any thoughts as i am still learning and might have
>> missed some points to consider while trying to implement something
>> like this.
>
> My plan for implementing this was:
>
> 1. Look at the current ReadOnlyContext implementation and figure  
> out how to make a sufficiently synchronized version of it.  I'm  
> hoping that we can have synchronized wrappers around this  
> implementation rather than needing a copy, subclass, or new  
> implementation.

I think a read only JNDI and a mutable one are different enough that  
they need separate implementations.  Currently our ENC is using a the  
EnterpriseNamingContext which does not extend ReadOnlyContext (as it  
isn't really read only).  I'd like to keep the  
EnterpriseNamingContext simple and strictly read only.  Therefore,  
I'd like to see an new separate implementation.  If I were going to  
write it, I'd base it on ConcurrentReaderHashMap and future objects  
in Java5 (or backport-concurrent-util), but I'm not writing it, so I  
say do whatever you are comfortable with.

> 2. Remind myself of how the geronimo: context used to be  
> installed.  I think the same method will still work.  We might want  
> a gbean to specifically install it.  Make sure that programmatic  
> binding and lookup works.

IIRC, we add set naming provider package to  
org.apache.geronimo.naming and when a user tries to access the "foo:"  
root-context, the jvm looks for the class  
org.apache.geronimo.naming.foo.fooURLContextFactory.  We still have  
one named global that most likely gets loaded when someone looks up  
"global:"

> 3. Figure out how to bind stuff into this context from plans rather  
> than java code.  Currently my idea is to do this with binding  
> gbeans: I'm not entirely sure how to do this but one possibility  
> would be to have them contain a Reference object and the name to  
> bind it under.  Another possibility would be to not use References  
> but rather have a binding gbean with say a gbean  reference to a  
> ManagedConnectionFactoryWrapper: the gbean would call $getResource 
> () on it and then bind the result directly into jndi.  This would  
> result in simpler builders but more gbeans: we'd need one for  
> resource-refs and resource-env-refs, and another one for ejbs, and  
> another for plain gbean bindings.  One thing I like about this  
> second plan is that  the object would only be bound in jndi while  
> the resource was actually available.  Of course, the component that  
> looks up the entry can still keep it until the underlying gbean  
> support is long gone, and get exceptions when it tries to use the  
> entry.

I think binding will be the hardest part :)

-dain

Mime
View raw message