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.
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 ...
* 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".
* 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
Guillaume Nodet
Manu George wrote:
Hi, Guillaume
I guess if a writable context is implemented still the approach
given above should work. As we will be using the ENCConfigBuilder
only to populate the ENC during startup the interfaces can be used to
refer to the gbeans representing the deployed artefacts. Whatever we
will be writing to context from apps would be done after startup of
server and lost at shutdown. So there would not be any problem due to
geronimo using interfaces to get the GBean names as what we will be
adding at runtime will not be gbeans and we will not use
ENCConfigBuilder. Am I right?
Now a new property for jndiname will also be required in the plans for
the connectors.
P.S.This property was actually present in the older versions of
geronimo but was removed. I also remember david jencks mentioning in
the mailing list that he had a working implementation of a context
which he removed for some reason.
Thanks
Manu
>
>On 4/26/06, Guillaume Nodet < [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
>
>
>>When a JNDI context is created for a given configuration, the
interface
>>name is used to determine the name of the gbean that will be
mapped to
>>this JNDI reference (and to create a proxy ?).
>>Take a look at o.a.g.naming.ENCConfigBuilder#addResourceRefs.
>>But I guess this is irrelevant if the objects are bound when
they are
>>created.
>>
>>Btw, should the global JNDI tree be read-only, or read-write ?
>>IMHO, a read-write global JNDI tree would be very usefull.
>>
>>Cheers,
>>Guillaume Nodet
>>
>>
>>Manu George wrote:
>>
>>
>>
>>>Thanks David.
>>>
>>>Guillaume , Which proxy in the JNDI Tree are you referring where
>>>geronimo requires the main interface name? Are you speaking of
>>>UserTransaction etc? I thought those were standard names that
we can
>>>use to access them and will not be provided in DD? Please
clarify and
>>>correct me if I am wrong.
>>>
>>>Thanks
>>>Manu
>>>
>>>On 4/25/06, *David Jencks* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
>>><mailto: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>> wrote:
>>>
>>> It's required for corba ejb references.
>>>
>>> david jencks
>>>
>>> On Apr 25, 2006, at 7:34 AM, Manu George wrote:
>>>
>>> > Hi,
>>> > I have a question regarding one of the objects
present in
>>> > the current application local JNDI Context. What is the
>>> > HandleDelegate entry for?
>>> >
>>> > Thanks
>>> > Manu
>>>
>>>
>>>
>>>
>
>
>
>
