geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: Implementing Global JNDI
Date Thu, 27 Apr 2006 16:16:03 GMT
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"  
    <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.


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