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 08:22:15 GMT
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  

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.

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