Re: Implementing Global JNDI

[David Jencks]

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:.


* 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.


* 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.

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.

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.

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 was planning to work on this for 1.2, but I will be more than happy  
to work with you if you would like to implement it.  Please let us  
know of your intentions, progress, and please, if you decide not to  
implement it let us know :-)

I'll be mostly offline for the next few days but will try to check  
for messages and respond as often as I can.

many thanks
david jencks


Regards
Krishnakumar


On 4/28/06, David Jencks <[EMAIL PROTECTED]> wrote:

On Apr 27, 2006, at 9:16 AM, Dain Sundstrom wrote:

> I think we need to provide a non-persistent r/w global jndi tree
> since there are so many apps that depend on it.  In addition, I
> think we need a way for users to provide a set of bindings (JNDI,
> cos-naming, jaxr... really anything) to EJBs, RAs, and any GBean so
> that the services they need are available where their application
> expect.
>
> I have been thinking about the binding problem for a while and just
> haven't had time to work on it myself.  I think we can do something
> as simple as this for most services:
>
> <gbean name="foo-binding"
> class="org.apache.geronimo.naming.JndiBinding">
>    <reference name="object"><name>myService</...>
>    <attribute name="address">services/myService</...>
> </...>
>
> For J2EE services we want to bind, I think the xml above is way to
> complex and we need to provide some syntactic sugar.

That's basically what I had in mind, but expressed more clearly and
concretely

thanks
david jencks

>
> -dain
>
> On Apr 27, 2006, at 1:22 AM, David Jencks wrote:
>
>> I'm not convinced this discussion has got to the hard parts
>> yet :-)  I hope there turn out not to be any :-)
>>
>> Please don't change stuff in the read-only java:comp/env context
>> since it is pretty much completely specified by the spec.  Note
>> also that according to the spec a j2ee compliant app will only use
>> this jndi context, and only use the entries defined in the j2ee
>> deployment descriptors.
>>
>> I think you can use a lot of the jndi infrastructure we already
>> have including the geronimo context and the references to jca
>> connection factories, ejbs, etc.
>>
>> The missing part is how to get these references bound into your
>> context.  One approach is to write gbeans that install a reference
>> when started and remove it when stopped.  I would start by just
>> including these as plain gbeans in plans, and once that works
>> consider modifying the builders to add them automatically based on
>> xml in the geronimo plans.
>>
>> An alternative might be to investigating using say Directory to
>> persist the references directly.  I don't know enough about ldap
>> to know if this makes any sense at all.
>>
>> thanks
>> david jencks
>>
>> On Apr 26, 2006, at 11:56 PM, Manu George wrote:
>>
>>> Comments inline
>>>
>>> On 4/26/06, Guillaume Nodet <[EMAIL PROTECTED]>
>>> wrote: Looking more closely, it seems I was wrong.
>>> Gbeans with a j2eeType=JCAManagedConnectionFactory have a
>>> connectionFactoryInterface attribute that gives the name of  
the main
>>> interface to use when binding the object to the JNDI context.
>>> For EJB, GBeans with a j2eeType=StatelessSessionBean (or
>>> EntityBean ...)
>>> have attributes for the home and business interfaces.
>>> So i guess it should be ok.
>>>
>>> great
>>>
>>> Another way to handle that would be to bind the resource to the
>>> global
>>> JNDI tree when the resource is created: each configuration would
>>> contain
>>> a list of gbeans to bind in the jndi tree when the  
configuration is
>>> loaded.  Else, we will need some listener to listen to gbeans
>>> creation /
>>> destruction so that we can bind / unbind them from the global
>>> jndi context.
>>>
>>> Binding the resource during creation seems to be the simpler way.
>>> But what about the next time the server starts up. How is the
>>> context initialised? Do we populate during startup of each
>>> resource or application again or is persistence used in some way?
>>>
>>> In the case of listeners the above problem won't arise.
>>>
>>>
>>> A few questions:
>>> * I' m wondering how the global JNDI context will coexist with  
the
>>> existing ENC context, especially if the global jndi context is
>>> read-write ... Maybe there is no need for a local jndi  
context ...
>>>
>>> Yes that is a question i also have :-) . The local jndi context
>>> allows us to have app specific contexts and this has some
>>> advantages. A global jndi also has some advantages. Probably by
>>> default we can use the local context and if the user specifies a
>>> custom factory the global one or vice versa.
>>>
>>> * what is the purpose of the jndiname property ? If this is the
>>> key for
>>> a gbean in the jndi tree, I thought we could use the name
>>> attribute of
>>> the gbean: "jdbc/TradeDataSource" , "jms/QueueConnectionFactory".
>>>
>>> These names can also be TradeDatasource so then we may need to
>>> add jdbc and if jdbc is there in the name as you mentioned do we
>>> need to add jdbc to the name or not. These are a few issues which
>>> made me propose the jndiName property .
>>>
>>>   * what about conflicting names for JCA resources... currently
>>> there is
>>> nothing to prevent deploying JCA resource (or other resources
>>> that would
>>> be bound to jndi) with the same name
>>> I think deployment should fail with an resource already bound
>>> exception. Not sure if this or any other validation is
>>> implemented for the local context.
>>>
>>>
>>> Thanks
>>> Manu
>>
>