geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Manu George" <>
Subject Re: Implementing Global JNDI
Date Thu, 27 Apr 2006 06:56:17 GMT
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.


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.


View raw message