geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Implementing Global JNDI
Date Thu, 27 Apr 2006 18:30:17 GMT

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  

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

View raw message