Implementing Global JNDI

[Krishnakumar B <ww...@gmail.com>]

Hi,

In geronimo road map there was a requirement for implementing Global
JNDI for geronimo.

An approach to implementing the same is posted below. Kindly post your
valuable feedback.

* Write and Deploy a GBean For Global JNDI
* GBean on startup of server would introspect the server and build JNDI tree
   - jdbc
   - jms
   - ejb etc...
* JNDI tree is stored in Hashmap and we can use
ComponentContextBuilder to build this tree.
* We can use EnterpriseNamingContext to create a context.
* The Context is stored as a static variable in the Local Factory Class.
* During deployment a new entry is added to Context ( Hashmap.)
* During undeployment an entry is removed from Context ( Hashmap )
* We can reuse the existing the geronimo-naming package for directory
operations.

We have done some initial ground work ( Writing Gbean, Building JNDI
Tree ) and would be glad to know how such an implementation would fit
into geronimo server, limitations if any so that we know we are using
the right approach.

Regards
Krish

Re: Implementing Global JNDI

[Guillaume Nodet <gu...@worldonline.fr>]

I would be glad to help writing / testing this feature.
Is the code available somewhere ?
I also just have one question: when I was looking at how to use Geronimo 
JNDI implementation, i faced the problem that to access one of the proxy 
in the JNDI tree, Geronimo requires the main interface name (which is 
usually given by deployment descriptors).  How did you work around that ?

Cheers,
Guillaume Nodet

Krishnakumar B wrote:

>Hi,
>
>In geronimo road map there was a requirement for implementing Global
>JNDI for geronimo.
>
>An approach to implementing the same is posted below. Kindly post your
>valuable feedback.
>
>* Write and Deploy a GBean For Global JNDI
>* GBean on startup of server would introspect the server and build JNDI tree
>   - jdbc
>   - jms
>   - ejb etc...
>* JNDI tree is stored in Hashmap and we can use
>ComponentContextBuilder to build this tree.
>* We can use EnterpriseNamingContext to create a context.
>* The Context is stored as a static variable in the Local Factory Class.
>* During deployment a new entry is added to Context ( Hashmap.)
>* During undeployment an entry is removed from Context ( Hashmap )
>* We can reuse the existing the geronimo-naming package for directory
>operations.
>
>We have done some initial ground work ( Writing Gbean, Building JNDI
>Tree ) and would be glad to know how such an implementation would fit
>into geronimo server, limitations if any so that we know we are using
>the right approach.
>
>Regards
>Krish
>
>
>  
>

Re: Implementing Global JNDI

[Guillaume Nodet <gu...@worldonline.fr>]

I would be glad to help writing / testing this feature.
Is the code available somewhere ?
I also just have one question: when I was looking at how to use Geronimo 
JNDI implementation, i faced the problem that to access one of the proxy 
in the JNDI tree, Geronimo requires the main interface name (which is 
usually given by deployment descriptors).  How did you work around that ?

Cheers,
Guillaume Nodet

Krishnakumar B wrote:

>Hi,
>
>In geronimo road map there was a requirement for implementing Global
>JNDI for geronimo.
>
>An approach to implementing the same is posted below. Kindly post your
>valuable feedback.
>
>* Write and Deploy a GBean For Global JNDI
>* GBean on startup of server would introspect the server and build JNDI tree
>   - jdbc
>   - jms
>   - ejb etc...
>* JNDI tree is stored in Hashmap and we can use
>ComponentContextBuilder to build this tree.
>* We can use EnterpriseNamingContext to create a context.
>* The Context is stored as a static variable in the Local Factory Class.
>* During deployment a new entry is added to Context ( Hashmap.)
>* During undeployment an entry is removed from Context ( Hashmap )
>* We can reuse the existing the geronimo-naming package for directory
>operations.
>
>We have done some initial ground work ( Writing Gbean, Building JNDI
>Tree ) and would be glad to know how such an implementation would fit
>into geronimo server, limitations if any so that we know we are using
>the right approach.
>
>Regards
>Krish
>
>
>  
>

Re: Implementing Global JNDI

[Matt Hogstrom <ma...@hogstrom.org>]

Its been noted that we need a R/W JNDI Impl.  I believe its on the roadmap.

Guillaume Nodet 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* <david_jencks@yahoo.com 
>> <ma...@yahoo.com>> 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
>>
>>
> 
> 
> 

Re: Implementing Global JNDI

[Krishnakumar B <ww...@gmail.com>]

Hi David,

Few days back i had attached a implementation to JIRA-2153. Would be
glad if u can provide ur review comments for the same.

Regards
Krishnakumar

On 7/18/06, Krishnakumar B <ww...@gmail.com> wrote:
> Hi David,
>
> I have updated the JIRA-2153 with Context implementation and GBean
> that binds to JNDI.
>
> Kindly provide ur comments.
>
> Regards
> Krish
>
>
> On 7/6/06, David Jencks <da...@yahoo.com> wrote:
> > See my comment in the jira about this, I don't think you need to use
> > any naming References at all, nor do you need anything but a GBean
> > reference to the appropriate GBean.
> >
> > http://issues.apache.org/jira/browse/GERONIMO-2153
> >
> > thanks
> > david jencks
> >
> > On Jul 6, 2006, at 6:06 AM, Krishnakumar B wrote:
> >
> > > Hi David,
> > >
> > > I tried this and it works for Custom Resource Adapters. There is still
> > > a problem for Registering GBeans in Global JNDI through the builder (
> > > ServiceConfigBuilder ). The Builder is a part of
> > > geronimo-gbean-deployer plan which is parent of j2ee-deployer.  The
> > > geronimo-naming jars are loaded in j2ee-deployer. Hence we dont get
> > > access in ServiceConfigBuilder to GBeanReference thats part of naming.
> > >
> > > Currently all the binding GBeans are in naming package. So it works
> > > for all j2ee deployments.
> > >
> > > Is there a way to work around this ClassLoading problem heirarchy for
> > > binding GBeans through builder?
> > >
> > > Regards
> > > Krishnakumar
> > >
> > >
> > > On 6/28/06, David Jencks <da...@yahoo.com> wrote:
> > >>
> > >> I think there is a simpler solution, or perhaps I don't understand
> > >> all the
> > >> details of what you are proposing.  I think if you give your
> > >> binding gbeans
> > >> the magic classLoader attribute everything will work.  This will
> > >> be set to
> > >> the configuration classloader for the configuration the gbean is
> > >> in, not the
> > >> configuration the gbeans class is loaded in.  This classloader
> > >> should always
> > >> have the necessary classes in it.
> > >>
> > >> thanks
> > >> david jencks
> > >>
> > >>
> > >> On Jun 28, 2006, at 12:39 AM, Manu George wrote:
> > >> Hi,
> > >>          The problem we are facing regarding adapters is because
> > >> the binding
> > >> gbeans were added to the naming module of geronimo. We are
> > >> planning to
> > >> change this by creating a separate module for global jndi and then
> > >> adding it
> > >> as a dependency in the configuration that is getting deployed.
> > >> This will be
> > >> done in the builders.  All the reference creation logic can also
> > >> be moved to
> > >> the gbeans.The Binding GBeans will then have access to application
> > >> level
> > >> classes as they will be loaded in the app class loader.  We hope this
> > >> approach will solve the current problem.  We will post the code
> > >> again after
> > >> making these changes.
> > >>
> > >> Thanks
> > >> Manu
> > >>
> > >> On 6/28/06, Krishnakumar B <ww...@gmail.com> wrote:
> > >> > Hi,
> > >> >
> > >> > We have created  a JIRA
> > >> > (http://issues.apache.org/jira/browse/GERONIMO-2153  )
> > >> and attached
> > >> > the initial draft. We have tried two approaches.
> > >> >
> > >> > * Adding to plan
> > >> > * Deploying from Builder.
> > >> >
> > >> > The EJBJNDIBindingGBean deploys from OpenEJBModuleBuilder and
> > >> has a tag
> > >> >   <global-jndi/> in opene ejb plan.
> > >> >
> > >> > Resource Adapter and GBean have a gbean plan added to deployment
> > >> plan.
> > >> >
> > >> > <gbean name="JMSQueueFactoryJNDIBindingGBean"
> > >> >
> > >> class="org.apache.geronimo.connector.jndi.ConnectorJNDIBindingGBean">
> > >> > <attribute
> > >> name="configId">test/jms.rar/1.0/rar</attribute>
> > >> > <attribute
> > >> name="jndiName">globalJMSQueueFactory</attribute>
> > >> > <attribute
> > >> name="componentName">JMSQueueFactory</attribute>
> > >> > <attribute
> > >> name="j2eeType">JCAManagedConnectionFactory</attribute>
> > >> > <attribute
> > >> name="interfaceName">org.apache.geronimo.jms.connector.JMSQueueConnec
> > >> tionFactory</attribute>
> > >> > </gbean>
> > >> >
> > >> > and
> > >> >
> > >> > <gbean name="TestGBeanJNDIBindingGBean"
> > >> >
> > >> class="org.apache.geronimo.service.jndi.ServiceJNDIBindingGBean">
> > >> > <attribute name="configId">test/gbean/1.0/car</attribute>
> > >> > <attribute name="jndiName">globalTestGBean</attribute>
> > >> > <attribute name="componentName">TestGBean</attribute>
> > >> > <attribute name="j2eeType">GBean</attribute>
> > >> > <attribute name="className">gbean.test.TestGBean</attribute>
> > >> > </gbean>
> > >> >
> > >> > We have a Classloading issue when trying to maintain all the
> > >> > BindingGbeans at one level. ( rmi-naming ). For GBeans and Resource
> > >> > Adapters that are not J2EE interfaces like javax.sql.DataSource /
> > >> > javax.jms.QueueConnectionFactory we get a ClassNotFound
> > >> as the class
> > >> > is not available at Classloader of rmi-naming.
> > >> >
> > >> > We spent a lot of time trying to solve this issue but are not
> > >> able to
> > >> > find a solution as the application level interface or class is not
> > >> > available. This problem will not occur for j2ee interfaces like
> > >> > DataSource, EJB interfaces, Queue, Topic etc..
> > >> >
> > >> > If the approach is correct we would like to add the other
> > >> features to
> > >> > make this more suitable for adding into the product.
> > >> >
> > >> > Regards
> > >> > Krishnakumar B
> > >> >
> > >> >
> > >> > On 6/26/06, Jacek Laskowski <ja...@laskowski.net.pl> wrote:
> > >> > > On 6/23/06, Krishnakumar B < www.bkk@gmail.com> wrote:
> > >> > >
> > >> > > > The plan needs to have some XML Tag to say this resource
> > >> needs to gets
> > >> > > > into Global JNDI and the builder can then add it to
> > >> geronimo: Context.
> > >> > > > This is not implemented yet. Currently if we deploy a
> > >> connector it
> > >> > > > gets in global jndi.
> > >> > >
> > >> > > I might've misunderstood it, but isn't Global JNDI == geronimo:
> > >> > > context == global: context? If so, why is this copying from
> > >> Global
> > >> > > JNDI to the geronimo: namespace?
> > >> > >
> > >> > > Looking forward to seeing your patch for it. Just as Guillaume
> > >> > > suggested, please create an JIRA issue and attach the patch to
> > >> it.
> > >> > >
> > >> > > > Krishnakumar B
> > >> > >
> > >> > > Jacek
> > >> > >
> > >> > > --
> > >> > > Jacek Laskowski
> > >> > > http://www.laskowski.net.pl
> > >> > >
> > >> >
> > >>
> > >>
> > >>
> >
> >
>

Re: Implementing Global JNDI

[Krishnakumar B <ww...@gmail.com>]

Hi David,

I have updated the JIRA-2153 with Context implementation and GBean
that binds to JNDI.

Kindly provide ur comments.

Regards
Krish


On 7/6/06, David Jencks <da...@yahoo.com> wrote:
> See my comment in the jira about this, I don't think you need to use
> any naming References at all, nor do you need anything but a GBean
> reference to the appropriate GBean.
>
> http://issues.apache.org/jira/browse/GERONIMO-2153
>
> thanks
> david jencks
>
> On Jul 6, 2006, at 6:06 AM, Krishnakumar B wrote:
>
> > Hi David,
> >
> > I tried this and it works for Custom Resource Adapters. There is still
> > a problem for Registering GBeans in Global JNDI through the builder (
> > ServiceConfigBuilder ). The Builder is a part of
> > geronimo-gbean-deployer plan which is parent of j2ee-deployer.  The
> > geronimo-naming jars are loaded in j2ee-deployer. Hence we dont get
> > access in ServiceConfigBuilder to GBeanReference thats part of naming.
> >
> > Currently all the binding GBeans are in naming package. So it works
> > for all j2ee deployments.
> >
> > Is there a way to work around this ClassLoading problem heirarchy for
> > binding GBeans through builder?
> >
> > Regards
> > Krishnakumar
> >
> >
> > On 6/28/06, David Jencks <da...@yahoo.com> wrote:
> >>
> >> I think there is a simpler solution, or perhaps I don't understand
> >> all the
> >> details of what you are proposing.  I think if you give your
> >> binding gbeans
> >> the magic classLoader attribute everything will work.  This will
> >> be set to
> >> the configuration classloader for the configuration the gbean is
> >> in, not the
> >> configuration the gbeans class is loaded in.  This classloader
> >> should always
> >> have the necessary classes in it.
> >>
> >> thanks
> >> david jencks
> >>
> >>
> >> On Jun 28, 2006, at 12:39 AM, Manu George wrote:
> >> Hi,
> >>          The problem we are facing regarding adapters is because
> >> the binding
> >> gbeans were added to the naming module of geronimo. We are
> >> planning to
> >> change this by creating a separate module for global jndi and then
> >> adding it
> >> as a dependency in the configuration that is getting deployed.
> >> This will be
> >> done in the builders.  All the reference creation logic can also
> >> be moved to
> >> the gbeans.The Binding GBeans will then have access to application
> >> level
> >> classes as they will be loaded in the app class loader.  We hope this
> >> approach will solve the current problem.  We will post the code
> >> again after
> >> making these changes.
> >>
> >> Thanks
> >> Manu
> >>
> >> On 6/28/06, Krishnakumar B <ww...@gmail.com> wrote:
> >> > Hi,
> >> >
> >> > We have created  a JIRA
> >> > (http://issues.apache.org/jira/browse/GERONIMO-2153  )
> >> and attached
> >> > the initial draft. We have tried two approaches.
> >> >
> >> > * Adding to plan
> >> > * Deploying from Builder.
> >> >
> >> > The EJBJNDIBindingGBean deploys from OpenEJBModuleBuilder and
> >> has a tag
> >> >   <global-jndi/> in opene ejb plan.
> >> >
> >> > Resource Adapter and GBean have a gbean plan added to deployment
> >> plan.
> >> >
> >> > <gbean name="JMSQueueFactoryJNDIBindingGBean"
> >> >
> >> class="org.apache.geronimo.connector.jndi.ConnectorJNDIBindingGBean">
> >> > <attribute
> >> name="configId">test/jms.rar/1.0/rar</attribute>
> >> > <attribute
> >> name="jndiName">globalJMSQueueFactory</attribute>
> >> > <attribute
> >> name="componentName">JMSQueueFactory</attribute>
> >> > <attribute
> >> name="j2eeType">JCAManagedConnectionFactory</attribute>
> >> > <attribute
> >> name="interfaceName">org.apache.geronimo.jms.connector.JMSQueueConnec
> >> tionFactory</attribute>
> >> > </gbean>
> >> >
> >> > and
> >> >
> >> > <gbean name="TestGBeanJNDIBindingGBean"
> >> >
> >> class="org.apache.geronimo.service.jndi.ServiceJNDIBindingGBean">
> >> > <attribute name="configId">test/gbean/1.0/car</attribute>
> >> > <attribute name="jndiName">globalTestGBean</attribute>
> >> > <attribute name="componentName">TestGBean</attribute>
> >> > <attribute name="j2eeType">GBean</attribute>
> >> > <attribute name="className">gbean.test.TestGBean</attribute>
> >> > </gbean>
> >> >
> >> > We have a Classloading issue when trying to maintain all the
> >> > BindingGbeans at one level. ( rmi-naming ). For GBeans and Resource
> >> > Adapters that are not J2EE interfaces like javax.sql.DataSource /
> >> > javax.jms.QueueConnectionFactory we get a ClassNotFound
> >> as the class
> >> > is not available at Classloader of rmi-naming.
> >> >
> >> > We spent a lot of time trying to solve this issue but are not
> >> able to
> >> > find a solution as the application level interface or class is not
> >> > available. This problem will not occur for j2ee interfaces like
> >> > DataSource, EJB interfaces, Queue, Topic etc..
> >> >
> >> > If the approach is correct we would like to add the other
> >> features to
> >> > make this more suitable for adding into the product.
> >> >
> >> > Regards
> >> > Krishnakumar B
> >> >
> >> >
> >> > On 6/26/06, Jacek Laskowski <ja...@laskowski.net.pl> wrote:
> >> > > On 6/23/06, Krishnakumar B < www.bkk@gmail.com> wrote:
> >> > >
> >> > > > The plan needs to have some XML Tag to say this resource
> >> needs to gets
> >> > > > into Global JNDI and the builder can then add it to
> >> geronimo: Context.
> >> > > > This is not implemented yet. Currently if we deploy a
> >> connector it
> >> > > > gets in global jndi.
> >> > >
> >> > > I might've misunderstood it, but isn't Global JNDI == geronimo:
> >> > > context == global: context? If so, why is this copying from
> >> Global
> >> > > JNDI to the geronimo: namespace?
> >> > >
> >> > > Looking forward to seeing your patch for it. Just as Guillaume
> >> > > suggested, please create an JIRA issue and attach the patch to
> >> it.
> >> > >
> >> > > > Krishnakumar B
> >> > >
> >> > > Jacek
> >> > >
> >> > > --
> >> > > Jacek Laskowski
> >> > > http://www.laskowski.net.pl
> >> > >
> >> >
> >>
> >>
> >>
>
>

Re: Implementing Global JNDI

[David Jencks <da...@yahoo.com>]

See my comment in the jira about this, I don't think you need to use  
any naming References at all, nor do you need anything but a GBean  
reference to the appropriate GBean.

http://issues.apache.org/jira/browse/GERONIMO-2153

thanks
david jencks

On Jul 6, 2006, at 6:06 AM, Krishnakumar B wrote:

> Hi David,
>
> I tried this and it works for Custom Resource Adapters. There is still
> a problem for Registering GBeans in Global JNDI through the builder (
> ServiceConfigBuilder ). The Builder is a part of
> geronimo-gbean-deployer plan which is parent of j2ee-deployer.  The
> geronimo-naming jars are loaded in j2ee-deployer. Hence we dont get
> access in ServiceConfigBuilder to GBeanReference thats part of naming.
>
> Currently all the binding GBeans are in naming package. So it works
> for all j2ee deployments.
>
> Is there a way to work around this ClassLoading problem heirarchy for
> binding GBeans through builder?
>
> Regards
> Krishnakumar
>
>
> On 6/28/06, David Jencks <da...@yahoo.com> wrote:
>>
>> I think there is a simpler solution, or perhaps I don't understand  
>> all the
>> details of what you are proposing.  I think if you give your  
>> binding gbeans
>> the magic classLoader attribute everything will work.  This will  
>> be set to
>> the configuration classloader for the configuration the gbean is  
>> in, not the
>> configuration the gbeans class is loaded in.  This classloader  
>> should always
>> have the necessary classes in it.
>>
>> thanks
>> david jencks
>>
>>
>> On Jun 28, 2006, at 12:39 AM, Manu George wrote:
>> Hi,
>>          The problem we are facing regarding adapters is because  
>> the binding
>> gbeans were added to the naming module of geronimo. We are  
>> planning to
>> change this by creating a separate module for global jndi and then  
>> adding it
>> as a dependency in the configuration that is getting deployed.  
>> This will be
>> done in the builders.  All the reference creation logic can also  
>> be moved to
>> the gbeans.The Binding GBeans will then have access to application  
>> level
>> classes as they will be loaded in the app class loader.  We hope this
>> approach will solve the current problem.  We will post the code  
>> again after
>> making these changes.
>>
>> Thanks
>> Manu
>>
>> On 6/28/06, Krishnakumar B <ww...@gmail.com> wrote:
>> > Hi,
>> >
>> > We have created  a JIRA
>> > (http://issues.apache.org/jira/browse/GERONIMO-2153  )
>> and attached
>> > the initial draft. We have tried two approaches.
>> >
>> > * Adding to plan
>> > * Deploying from Builder.
>> >
>> > The EJBJNDIBindingGBean deploys from OpenEJBModuleBuilder and  
>> has a tag
>> >   <global-jndi/> in opene ejb plan.
>> >
>> > Resource Adapter and GBean have a gbean plan added to deployment  
>> plan.
>> >
>> > <gbean name="JMSQueueFactoryJNDIBindingGBean"
>> >
>> class="org.apache.geronimo.connector.jndi.ConnectorJNDIBindingGBean">
>> > <attribute
>> name="configId">test/jms.rar/1.0/rar</attribute>
>> > <attribute
>> name="jndiName">globalJMSQueueFactory</attribute>
>> > <attribute
>> name="componentName">JMSQueueFactory</attribute>
>> > <attribute
>> name="j2eeType">JCAManagedConnectionFactory</attribute>
>> > <attribute
>> name="interfaceName">org.apache.geronimo.jms.connector.JMSQueueConnec 
>> tionFactory</attribute>
>> > </gbean>
>> >
>> > and
>> >
>> > <gbean name="TestGBeanJNDIBindingGBean"
>> >
>> class="org.apache.geronimo.service.jndi.ServiceJNDIBindingGBean">
>> > <attribute name="configId">test/gbean/1.0/car</attribute>
>> > <attribute name="jndiName">globalTestGBean</attribute>
>> > <attribute name="componentName">TestGBean</attribute>
>> > <attribute name="j2eeType">GBean</attribute>
>> > <attribute name="className">gbean.test.TestGBean</attribute>
>> > </gbean>
>> >
>> > We have a Classloading issue when trying to maintain all the
>> > BindingGbeans at one level. ( rmi-naming ). For GBeans and Resource
>> > Adapters that are not J2EE interfaces like javax.sql.DataSource /
>> > javax.jms.QueueConnectionFactory we get a ClassNotFound
>> as the class
>> > is not available at Classloader of rmi-naming.
>> >
>> > We spent a lot of time trying to solve this issue but are not  
>> able to
>> > find a solution as the application level interface or class is not
>> > available. This problem will not occur for j2ee interfaces like
>> > DataSource, EJB interfaces, Queue, Topic etc..
>> >
>> > If the approach is correct we would like to add the other  
>> features to
>> > make this more suitable for adding into the product.
>> >
>> > Regards
>> > Krishnakumar B
>> >
>> >
>> > On 6/26/06, Jacek Laskowski <ja...@laskowski.net.pl> wrote:
>> > > On 6/23/06, Krishnakumar B < www.bkk@gmail.com> wrote:
>> > >
>> > > > The plan needs to have some XML Tag to say this resource  
>> needs to gets
>> > > > into Global JNDI and the builder can then add it to  
>> geronimo: Context.
>> > > > This is not implemented yet. Currently if we deploy a  
>> connector it
>> > > > gets in global jndi.
>> > >
>> > > I might've misunderstood it, but isn't Global JNDI == geronimo:
>> > > context == global: context? If so, why is this copying from  
>> Global
>> > > JNDI to the geronimo: namespace?
>> > >
>> > > Looking forward to seeing your patch for it. Just as Guillaume
>> > > suggested, please create an JIRA issue and attach the patch to  
>> it.
>> > >
>> > > > Krishnakumar B
>> > >
>> > > Jacek
>> > >
>> > > --
>> > > Jacek Laskowski
>> > > http://www.laskowski.net.pl
>> > >
>> >
>>
>>
>>

Re: Implementing Global JNDI

[Krishnakumar B <ww...@gmail.com>]

Hi David,

I tried this and it works for Custom Resource Adapters. There is still
a problem for Registering GBeans in Global JNDI through the builder (
ServiceConfigBuilder ). The Builder is a part of
geronimo-gbean-deployer plan which is parent of j2ee-deployer.  The
geronimo-naming jars are loaded in j2ee-deployer. Hence we dont get
access in ServiceConfigBuilder to GBeanReference thats part of naming.

Currently all the binding GBeans are in naming package. So it works
for all j2ee deployments.

Is there a way to work around this ClassLoading problem heirarchy for
binding GBeans through builder?

Regards
Krishnakumar


On 6/28/06, David Jencks <da...@yahoo.com> wrote:
>
> I think there is a simpler solution, or perhaps I don't understand all the
> details of what you are proposing.  I think if you give your binding gbeans
> the magic classLoader attribute everything will work.  This will be set to
> the configuration classloader for the configuration the gbean is in, not the
> configuration the gbeans class is loaded in.  This classloader should always
> have the necessary classes in it.
>
> thanks
> david jencks
>
>
> On Jun 28, 2006, at 12:39 AM, Manu George wrote:
> Hi,
>          The problem we are facing regarding adapters is because the binding
> gbeans were added to the naming module of geronimo. We are planning to
> change this by creating a separate module for global jndi and then adding it
> as a dependency in the configuration that is getting deployed. This will be
> done in the builders.  All the reference creation logic can also be moved to
> the gbeans.The Binding GBeans will then have access to application level
> classes as they will be loaded in the app class loader.  We hope this
> approach will solve the current problem.  We will post the code again after
> making these changes.
>
> Thanks
> Manu
>
> On 6/28/06, Krishnakumar B <ww...@gmail.com> wrote:
> > Hi,
> >
> > We have created  a JIRA
> > (http://issues.apache.org/jira/browse/GERONIMO-2153  )
> and attached
> > the initial draft. We have tried two approaches.
> >
> > * Adding to plan
> > * Deploying from Builder.
> >
> > The EJBJNDIBindingGBean deploys from OpenEJBModuleBuilder and has a tag
> >   <global-jndi/> in opene ejb plan.
> >
> > Resource Adapter and GBean have a gbean plan added to deployment plan.
> >
> > <gbean name="JMSQueueFactoryJNDIBindingGBean"
> >
> class="org.apache.geronimo.connector.jndi.ConnectorJNDIBindingGBean">
> > <attribute
> name="configId">test/jms.rar/1.0/rar</attribute>
> > <attribute
> name="jndiName">globalJMSQueueFactory</attribute>
> > <attribute
> name="componentName">JMSQueueFactory</attribute>
> > <attribute
> name="j2eeType">JCAManagedConnectionFactory</attribute>
> > <attribute
> name="interfaceName">org.apache.geronimo.jms.connector.JMSQueueConnectionFactory</attribute>
> > </gbean>
> >
> > and
> >
> > <gbean name="TestGBeanJNDIBindingGBean"
> >
> class="org.apache.geronimo.service.jndi.ServiceJNDIBindingGBean">
> > <attribute name="configId">test/gbean/1.0/car</attribute>
> > <attribute name="jndiName">globalTestGBean</attribute>
> > <attribute name="componentName">TestGBean</attribute>
> > <attribute name="j2eeType">GBean</attribute>
> > <attribute name="className">gbean.test.TestGBean</attribute>
> > </gbean>
> >
> > We have a Classloading issue when trying to maintain all the
> > BindingGbeans at one level. ( rmi-naming ). For GBeans and Resource
> > Adapters that are not J2EE interfaces like javax.sql.DataSource /
> > javax.jms.QueueConnectionFactory we get a ClassNotFound
> as the class
> > is not available at Classloader of rmi-naming.
> >
> > We spent a lot of time trying to solve this issue but are not able to
> > find a solution as the application level interface or class is not
> > available. This problem will not occur for j2ee interfaces like
> > DataSource, EJB interfaces, Queue, Topic etc..
> >
> > If the approach is correct we would like to add the other features to
> > make this more suitable for adding into the product.
> >
> > Regards
> > Krishnakumar B
> >
> >
> > On 6/26/06, Jacek Laskowski <ja...@laskowski.net.pl> wrote:
> > > On 6/23/06, Krishnakumar B < www.bkk@gmail.com> wrote:
> > >
> > > > The plan needs to have some XML Tag to say this resource needs to gets
> > > > into Global JNDI and the builder can then add it to geronimo: Context.
> > > > This is not implemented yet. Currently if we deploy a connector it
> > > > gets in global jndi.
> > >
> > > I might've misunderstood it, but isn't Global JNDI == geronimo:
> > > context == global: context? If so, why is this copying from Global
> > > JNDI to the geronimo: namespace?
> > >
> > > Looking forward to seeing your patch for it. Just as Guillaume
> > > suggested, please create an JIRA issue and attach the patch to it.
> > >
> > > > Krishnakumar B
> > >
> > > Jacek
> > >
> > > --
> > > Jacek Laskowski
> > > http://www.laskowski.net.pl
> > >
> >
>
>
>

Re: Implementing Global JNDI

[David Jencks <da...@yahoo.com>]

I think there is a simpler solution, or perhaps I don't understand  
all the details of what you are proposing.  I think if you give your  
binding gbeans the magic classLoader attribute everything will work.   
This will be set to the configuration classloader for the  
configuration the gbean is in, not the configuration the gbeans class  
is loaded in.  This classloader should always have the necessary  
classes in it.

thanks
david jencks

On Jun 28, 2006, at 12:39 AM, Manu George wrote:

> Hi,
>          The problem we are facing regarding adapters is because  
> the binding gbeans were added to the naming module of geronimo. We  
> are planning to change this by creating a separate module for  
> global jndi and then adding it as a dependency in the configuration  
> that is getting deployed. This will be done in the builders.  All  
> the reference creation logic can also be moved to the gbeans.The  
> Binding GBeans will then have access to application level classes  
> as they will be loaded in the app class loader.  We hope this  
> approach will solve the current problem.  We will post the code  
> again after making these changes.
>
> Thanks
> Manu
>
> On 6/28/06, Krishnakumar B <ww...@gmail.com> wrote:
> Hi,
>
> We have created  a JIRA
> (http://issues.apache.org/jira/browse/GERONIMO-2153  ) and attached
> the initial draft. We have tried two approaches.
>
> * Adding to plan
> * Deploying from Builder.
>
> The EJBJNDIBindingGBean deploys from OpenEJBModuleBuilder and has a  
> tag
>   <global-jndi/> in opene ejb plan.
>
> Resource Adapter and GBean have a gbean plan added to deployment plan.
>
> <gbean name="JMSQueueFactoryJNDIBindingGBean"
> class="org.apache.geronimo.connector.jndi.ConnectorJNDIBindingGBean">
> <attribute name="configId">test/jms.rar/1.0/rar</attribute>
> <attribute name="jndiName">globalJMSQueueFactory</attribute>
> <attribute name="componentName">JMSQueueFactory</attribute>
> <attribute name="j2eeType">JCAManagedConnectionFactory</attribute>
> <attribute  
> name="interfaceName">org.apache.geronimo.jms.connector.JMSQueueConnect 
> ionFactory</attribute>
> </gbean>
>
> and
>
> <gbean name="TestGBeanJNDIBindingGBean"
> class="org.apache.geronimo.service.jndi.ServiceJNDIBindingGBean">
> <attribute name="configId">test/gbean/1.0/car</attribute>
> <attribute name="jndiName">globalTestGBean</attribute>
> <attribute name="componentName">TestGBean</attribute>
> <attribute name="j2eeType">GBean</attribute>
> <attribute name="className">gbean.test.TestGBean</attribute>
> </gbean>
>
> We have a Classloading issue when trying to maintain all the
> BindingGbeans at one level. ( rmi-naming ). For GBeans and Resource
> Adapters that are not J2EE interfaces like javax.sql.DataSource /
> javax.jms.QueueConnectionFactory we get a ClassNotFound as the class
> is not available at Classloader of rmi-naming.
>
> We spent a lot of time trying to solve this issue but are not able to
> find a solution as the application level interface or class is not
> available. This problem will not occur for j2ee interfaces like
> DataSource, EJB interfaces, Queue, Topic etc..
>
> If the approach is correct we would like to add the other features to
> make this more suitable for adding into the product.
>
> Regards
> Krishnakumar B
>
>
> On 6/26/06, Jacek Laskowski <ja...@laskowski.net.pl> wrote:
> > On 6/23/06, Krishnakumar B < www.bkk@gmail.com> wrote:
> >
> > > The plan needs to have some XML Tag to say this resource needs  
> to gets
> > > into Global JNDI and the builder can then add it to geronimo:  
> Context.
> > > This is not implemented yet. Currently if we deploy a connector it
> > > gets in global jndi.
> >
> > I might've misunderstood it, but isn't Global JNDI == geronimo:
> > context == global: context? If so, why is this copying from Global
> > JNDI to the geronimo: namespace?
> >
> > Looking forward to seeing your patch for it. Just as Guillaume
> > suggested, please create an JIRA issue and attach the patch to it.
> >
> > > Krishnakumar B
> >
> > Jacek
> >
> > --
> > Jacek Laskowski
> > http://www.laskowski.net.pl
> >
>

Re: Implementing Global JNDI

[Manu George <ma...@gmail.com>]

Hi,
         The problem we are facing regarding adapters is because the binding
gbeans were added to the naming module of geronimo. We are planning to
change this by creating a separate module for global jndi and then adding it
as a dependency in the configuration that is getting deployed. This will be
done in the builders.  All the reference creation logic can also be moved to
the gbeans.The Binding GBeans will then have access to application level
classes as they will be loaded in the app class loader.  We hope this
approach will solve the current problem.  We will post the code again after
making these changes.

Thanks
Manu

On 6/28/06, Krishnakumar B <ww...@gmail.com> wrote:
>
> Hi,
>
> We have created  a JIRA
> (http://issues.apache.org/jira/browse/GERONIMO-2153  ) and attached
> the initial draft. We have tried two approaches.
>
> * Adding to plan
> * Deploying from Builder.
>
> The EJBJNDIBindingGBean deploys from OpenEJBModuleBuilder and has a tag
>   <global-jndi/> in opene ejb plan.
>
> Resource Adapter and GBean have a gbean plan added to deployment plan.
>
> <gbean name="JMSQueueFactoryJNDIBindingGBean"
> class="org.apache.geronimo.connector.jndi.ConnectorJNDIBindingGBean">
> <attribute name="configId">test/jms.rar/1.0/rar</attribute>
> <attribute name="jndiName">globalJMSQueueFactory</attribute>
> <attribute name="componentName">JMSQueueFactory</attribute>
> <attribute name="j2eeType">JCAManagedConnectionFactory</attribute>
> <attribute name="interfaceName">
> org.apache.geronimo.jms.connector.JMSQueueConnectionFactory</attribute>
> </gbean>
>
> and
>
> <gbean name="TestGBeanJNDIBindingGBean"
> class="org.apache.geronimo.service.jndi.ServiceJNDIBindingGBean">
> <attribute name="configId">test/gbean/1.0/car</attribute>
> <attribute name="jndiName">globalTestGBean</attribute>
> <attribute name="componentName">TestGBean</attribute>
> <attribute name="j2eeType">GBean</attribute>
> <attribute name="className">gbean.test.TestGBean</attribute>
> </gbean>
>
> We have a Classloading issue when trying to maintain all the
> BindingGbeans at one level. ( rmi-naming ). For GBeans and Resource
> Adapters that are not J2EE interfaces like javax.sql.DataSource /
> javax.jms.QueueConnectionFactory we get a ClassNotFound as the class
> is not available at Classloader of rmi-naming.
>
> We spent a lot of time trying to solve this issue but are not able to
> find a solution as the application level interface or class is not
> available. This problem will not occur for j2ee interfaces like
> DataSource, EJB interfaces, Queue, Topic etc..
>
> If the approach is correct we would like to add the other features to
> make this more suitable for adding into the product.
>
> Regards
> Krishnakumar B
>
>
> On 6/26/06, Jacek Laskowski <ja...@laskowski.net.pl> wrote:
> > On 6/23/06, Krishnakumar B <ww...@gmail.com> wrote:
> >
> > > The plan needs to have some XML Tag to say this resource needs to gets
> > > into Global JNDI and the builder can then add it to geronimo: Context.
> > > This is not implemented yet. Currently if we deploy a connector it
> > > gets in global jndi.
> >
> > I might've misunderstood it, but isn't Global JNDI == geronimo:
> > context == global: context? If so, why is this copying from Global
> > JNDI to the geronimo: namespace?
> >
> > Looking forward to seeing your patch for it. Just as Guillaume
> > suggested, please create an JIRA issue and attach the patch to it.
> >
> > > Krishnakumar B
> >
> > Jacek
> >
> > --
> > Jacek Laskowski
> > http://www.laskowski.net.pl
> >
>

Re: Implementing Global JNDI

[Krishnakumar B <ww...@gmail.com>]

Hi,

We have created  a JIRA
(http://issues.apache.org/jira/browse/GERONIMO-2153  ) and attached
the initial draft. We have tried two approaches.

* Adding to plan
* Deploying from Builder.

The EJBJNDIBindingGBean deploys from OpenEJBModuleBuilder and has a tag
  <global-jndi/> in opene ejb plan.

Resource Adapter and GBean have a gbean plan added to deployment plan.

<gbean name="JMSQueueFactoryJNDIBindingGBean"
class="org.apache.geronimo.connector.jndi.ConnectorJNDIBindingGBean">
<attribute name="configId">test/jms.rar/1.0/rar</attribute>
<attribute name="jndiName">globalJMSQueueFactory</attribute>
<attribute name="componentName">JMSQueueFactory</attribute>
<attribute name="j2eeType">JCAManagedConnectionFactory</attribute>
<attribute name="interfaceName">org.apache.geronimo.jms.connector.JMSQueueConnectionFactory</attribute>
</gbean>

and

<gbean name="TestGBeanJNDIBindingGBean"
class="org.apache.geronimo.service.jndi.ServiceJNDIBindingGBean">
<attribute name="configId">test/gbean/1.0/car</attribute>
<attribute name="jndiName">globalTestGBean</attribute>
<attribute name="componentName">TestGBean</attribute>
<attribute name="j2eeType">GBean</attribute>
<attribute name="className">gbean.test.TestGBean</attribute>
</gbean>

We have a Classloading issue when trying to maintain all the
BindingGbeans at one level. ( rmi-naming ). For GBeans and Resource
Adapters that are not J2EE interfaces like javax.sql.DataSource /
javax.jms.QueueConnectionFactory we get a ClassNotFound as the class
is not available at Classloader of rmi-naming.

We spent a lot of time trying to solve this issue but are not able to
find a solution as the application level interface or class is not
available. This problem will not occur for j2ee interfaces like
DataSource, EJB interfaces, Queue, Topic etc..

If the approach is correct we would like to add the other features to
make this more suitable for adding into the product.

Regards
Krishnakumar B


On 6/26/06, Jacek Laskowski <ja...@laskowski.net.pl> wrote:
> On 6/23/06, Krishnakumar B <ww...@gmail.com> wrote:
>
> > The plan needs to have some XML Tag to say this resource needs to gets
> > into Global JNDI and the builder can then add it to geronimo: Context.
> > This is not implemented yet. Currently if we deploy a connector it
> > gets in global jndi.
>
> I might've misunderstood it, but isn't Global JNDI == geronimo:
> context == global: context? If so, why is this copying from Global
> JNDI to the geronimo: namespace?
>
> Looking forward to seeing your patch for it. Just as Guillaume
> suggested, please create an JIRA issue and attach the patch to it.
>
> > Krishnakumar B
>
> Jacek
>
> --
> Jacek Laskowski
> http://www.laskowski.net.pl
>

Re: Implementing Global JNDI

[Jacek Laskowski <ja...@laskowski.net.pl>]

On 6/23/06, Krishnakumar B <ww...@gmail.com> wrote:

> The plan needs to have some XML Tag to say this resource needs to gets
> into Global JNDI and the builder can then add it to geronimo: Context.
> This is not implemented yet. Currently if we deploy a connector it
> gets in global jndi.

I might've misunderstood it, but isn't Global JNDI == geronimo:
context == global: context? If so, why is this copying from Global
JNDI to the geronimo: namespace?

Looking forward to seeing your patch for it. Just as Guillaume
suggested, please create an JIRA issue and attach the patch to it.

> Krishnakumar B

Jacek

-- 
Jacek Laskowski
http://www.laskowski.net.pl

Re: Implementing Global JNDI

[Guillaume Nodet <gn...@gmail.com>]

Could you raise a JIRA and attach the patch for review ?

Thanks,
Guillaume Nodet

On 6/23/06, Krishnakumar B <ww...@gmail.com> wrote:
>
> hi,
>
> We ( Me & Manu )  have created a implementation of global JNDI based
> on the feedback received on the dev list.
>
> It works like this.
>
> * The implementation uses GeronimoRootContext and ReadOnlyContext
> thats part of naming module to create the root context ( geronimo: ).
> The  Context is accessed by means of a Factory
> GeronimoInitialContextFactory that implements InitialContextFactory.
>
> * A GBean ( GeronimoContextGBean ) loads on start of server and
> creates the Root Context.  Now applications can bind to this context.
>
> * We have added GBeans to naming ( GlobalJNDIBindingGBean for RA,
> DataSource, QCF/TCF,Queue, Topic  and EJBJNDIBindingGBean for EJB )
> that are deployed when an app is deployed.
>
> * The builders add the Gbeans during the deployment process. [
> ConnectorModule Builder, OpenEJBModuleBuilder, ServiceConfigBuilder ].
>
> The plan needs to have some XML Tag to say this resource needs to gets
> into Global JNDI and the builder can then add it to geronimo: Context.
> This is not implemented yet. Currently if we deploy a connector it
> gets in global jndi.
>
> The current code we can add DataSource, RA, EJB, QCF, Queue/Topic,
> GBeans to geronimo: Context. With some changes to context
> implementation any object can be bound to global JNDI. ( Have not
> looked at security aspect and would need some ideas on how to proceed
> ).
>
> This may need some more work and changes before it takes final form to
> get into product. Kindly provide your review, comments and
> contributions from others who are interested and have better ideas.
>
> We are not able to attach the code as mailing list rejects attachments.
>
> Regards
> Krishnakumar B
>
>
> On 5/24/06, Krishnakumar B <ww...@gmail.com> wrote:
> > Thanks for the feedback and inputs.
> >
> > Regards
> > Krishnakumar
> >
> >
> > On 5/24/06, Dain Sundstrom <da...@iq80.com> wrote:
> > > On May 23, 2006, at 5:19 PM, David Jencks wrote:
> > >
> > > >
> > > > On May 23, 2006, at 6:28 AM, Krishnakumar B wrote:
> > > >
> > > >> Hi,
> > > >>
> > > >> I have a few doubts related to implementation of global jndi.
> > > >>
> > > >> * Currently we have java:comp/env stored in Local JNDI. In Global
> > > >> JNDI
> > > >> should objects be bound using a different namespace e.g) java: or
> > > >> java:global?
> > > >
> > > > IIUC java: is reserved by the j2ee spec for what it requires: thus
> > > > IMO we should use something else.  IIRC the original global jndi
> > > > context used geronimo:  I'm OK with that or maybe global:.
> > >
> > > IIRC some servers use just "/foo/bar" with no context.  If I am
> > > correct, we should support that also (but not the default).
> > >
> > > >>
> > > >> * When we implement global JNDI we have some entries in Global and
> > > >> All
> > > >> entries related to application in Local. When a user creates a
> > > >> context
> > > >> he needs to get from either global or local based on what he needs.
> > > >> Would it be right for lookup code to decide from where to fetch the
> > > >> entry based on how the Context is created?
> > > >>
> > > >> for e.g) if i say InitialContext iniCtx = new
> > > >> InitialContext("java:comp/env"); fetch from local
> > > >> and if InitialContext iniCtx = new InitialContext("java:global");
> > > >> fetch from global
> > > >
> > > > I'm not sure what you're asking about here.  Unless you do
> > > > something screwy to link one of these to the other, the contents of
> > > > these contexts will be completely unrelated.
> > >
> > > Looking at the JavaDocs for InitialContext, it does not have a
> > > constructor that takes a String.  Did you mean:
> > >
> > >   Context context = (Context) new InitialContext().lookup("java:comp/
> > > env");
> > >   Context context = (Context) new InitialContext().lookup("global:");
> > >
> > > >> * Currently in Local JNDI we store Resource References. Should
> global
> > > >> JNDI also use the same approach or can we use Object references for
> > > >> e.g) DataSource reference directly put in JNDI
> > > >
> > > > For j2ee components I think we should bind the same kinds of
> > > > References in the global jndi tree as we bind in the current java:
> > > > context.  What we bind for stuff that can't get into the java:
> > > > context needs more thought: it probably depends on what it is.  Of
> > > > course if the context is not read-only an app can bind whatever it
> > > > wants wherever it wants, thus bringing to mind the need for
> > > > security and permissions for this stuff.
> > >
> > > I don't think we can use the current Reference object we bind into
> > > our read only context because they do cache the value and never
> > > release it.  It is expected that the referece will be GCed when the
> > > J2EE application is unloaded.  It shouldn't be hard to either turn
> > > off the cache or to register listener for the reference target life-
> > > cycle events.
> > >
> > > >> Would appreciate any thoughts as i am still learning and might have
> > > >> missed some points to consider while trying to implement something
> > > >> like this.
> > > >
> > > > My plan for implementing this was:
> > > >
> > > > 1. Look at the current ReadOnlyContext implementation and figure
> > > > out how to make a sufficiently synchronized version of it.  I'm
> > > > hoping that we can have synchronized wrappers around this
> > > > implementation rather than needing a copy, subclass, or new
> > > > implementation.
> > >
> > > I think a read only JNDI and a mutable one are different enough that
> > > they need separate implementations.  Currently our ENC is using a the
> > > EnterpriseNamingContext which does not extend ReadOnlyContext (as it
> > > isn't really read only).  I'd like to keep the
> > > EnterpriseNamingContext simple and strictly read only.  Therefore,
> > > I'd like to see an new separate implementation.  If I were going to
> > > write it, I'd base it on ConcurrentReaderHashMap and future objects
> > > in Java5 (or backport-concurrent-util), but I'm not writing it, so I
> > > say do whatever you are comfortable with.
> > >
> > > > 2. Remind myself of how the geronimo: context used to be
> > > > installed.  I think the same method will still work.  We might want
> > > > a gbean to specifically install it.  Make sure that programmatic
> > > > binding and lookup works.
> > >
> > > IIRC, we add set naming provider package to
> > > org.apache.geronimo.naming and when a user tries to access the "foo:"
> > > root-context, the jvm looks for the class
> > > org.apache.geronimo.naming.foo.fooURLContextFactory.  We still have
> > > one named global that most likely gets loaded when someone looks up
> > > "global:"
> > >
> > > > 3. Figure out how to bind stuff into this context from plans rather
> > > > than java code.  Currently my idea is to do this with binding
> > > > gbeans: I'm not entirely sure how to do this but one possibility
> > > > would be to have them contain a Reference object and the name to
> > > > bind it under.  Another possibility would be to not use References
> > > > but rather have a binding gbean with say a gbean  reference to a
> > > > ManagedConnectionFactoryWrapper: the gbean would call $getResource
> > > > () on it and then bind the result directly into jndi.  This would
> > > > result in simpler builders but more gbeans: we'd need one for
> > > > resource-refs and resource-env-refs, and another one for ejbs, and
> > > > another for plain gbean bindings.  One thing I like about this
> > > > second plan is that  the object would only be bound in jndi while
> > > > the resource was actually available.  Of course, the component that
> > > > looks up the entry can still keep it until the underlying gbean
> > > > support is long gone, and get exceptions when it tries to use the
> > > > entry.
> > >
> > > I think binding will be the hardest part :)
> > >
> > > -dain
> > >
> >
>

Re: Implementing Global JNDI

[Krishnakumar B <ww...@gmail.com>]

hi,

We ( Me & Manu )  have created a implementation of global JNDI based
on the feedback received on the dev list.

It works like this.

* The implementation uses GeronimoRootContext and ReadOnlyContext
thats part of naming module to create the root context ( geronimo: ).
The  Context is accessed by means of a Factory
GeronimoInitialContextFactory that implements InitialContextFactory.

* A GBean ( GeronimoContextGBean ) loads on start of server and
creates the Root Context.  Now applications can bind to this context.

* We have added GBeans to naming ( GlobalJNDIBindingGBean for RA,
DataSource, QCF/TCF,Queue, Topic  and EJBJNDIBindingGBean for EJB )
that are deployed when an app is deployed.

* The builders add the Gbeans during the deployment process. [
ConnectorModule Builder, OpenEJBModuleBuilder, ServiceConfigBuilder ].

The plan needs to have some XML Tag to say this resource needs to gets
into Global JNDI and the builder can then add it to geronimo: Context.
This is not implemented yet. Currently if we deploy a connector it
gets in global jndi.

The current code we can add DataSource, RA, EJB, QCF, Queue/Topic,
GBeans to geronimo: Context. With some changes to context
implementation any object can be bound to global JNDI. ( Have not
looked at security aspect and would need some ideas on how to proceed
).

This may need some more work and changes before it takes final form to
get into product. Kindly provide your review, comments and
contributions from others who are interested and have better ideas.

We are not able to attach the code as mailing list rejects attachments.

Regards
Krishnakumar B


On 5/24/06, Krishnakumar B <ww...@gmail.com> wrote:
> Thanks for the feedback and inputs.
>
> Regards
> Krishnakumar
>
>
> On 5/24/06, Dain Sundstrom <da...@iq80.com> wrote:
> > On May 23, 2006, at 5:19 PM, David Jencks wrote:
> >
> > >
> > > On May 23, 2006, at 6:28 AM, Krishnakumar B wrote:
> > >
> > >> Hi,
> > >>
> > >> I have a few doubts related to implementation of global jndi.
> > >>
> > >> * Currently we have java:comp/env stored in Local JNDI. In Global
> > >> JNDI
> > >> should objects be bound using a different namespace e.g) java: or
> > >> java:global?
> > >
> > > IIUC java: is reserved by the j2ee spec for what it requires: thus
> > > IMO we should use something else.  IIRC the original global jndi
> > > context used geronimo:  I'm OK with that or maybe global:.
> >
> > IIRC some servers use just "/foo/bar" with no context.  If I am
> > correct, we should support that also (but not the default).
> >
> > >>
> > >> * When we implement global JNDI we have some entries in Global and
> > >> All
> > >> entries related to application in Local. When a user creates a
> > >> context
> > >> he needs to get from either global or local based on what he needs.
> > >> Would it be right for lookup code to decide from where to fetch the
> > >> entry based on how the Context is created?
> > >>
> > >> for e.g) if i say InitialContext iniCtx = new
> > >> InitialContext("java:comp/env"); fetch from local
> > >> and if InitialContext iniCtx = new InitialContext("java:global");
> > >> fetch from global
> > >
> > > I'm not sure what you're asking about here.  Unless you do
> > > something screwy to link one of these to the other, the contents of
> > > these contexts will be completely unrelated.
> >
> > Looking at the JavaDocs for InitialContext, it does not have a
> > constructor that takes a String.  Did you mean:
> >
> >   Context context = (Context) new InitialContext().lookup("java:comp/
> > env");
> >   Context context = (Context) new InitialContext().lookup("global:");
> >
> > >> * Currently in Local JNDI we store Resource References. Should global
> > >> JNDI also use the same approach or can we use Object references for
> > >> e.g) DataSource reference directly put in JNDI
> > >
> > > For j2ee components I think we should bind the same kinds of
> > > References in the global jndi tree as we bind in the current java:
> > > context.  What we bind for stuff that can't get into the java:
> > > context needs more thought: it probably depends on what it is.  Of
> > > course if the context is not read-only an app can bind whatever it
> > > wants wherever it wants, thus bringing to mind the need for
> > > security and permissions for this stuff.
> >
> > I don't think we can use the current Reference object we bind into
> > our read only context because they do cache the value and never
> > release it.  It is expected that the referece will be GCed when the
> > J2EE application is unloaded.  It shouldn't be hard to either turn
> > off the cache or to register listener for the reference target life-
> > cycle events.
> >
> > >> Would appreciate any thoughts as i am still learning and might have
> > >> missed some points to consider while trying to implement something
> > >> like this.
> > >
> > > My plan for implementing this was:
> > >
> > > 1. Look at the current ReadOnlyContext implementation and figure
> > > out how to make a sufficiently synchronized version of it.  I'm
> > > hoping that we can have synchronized wrappers around this
> > > implementation rather than needing a copy, subclass, or new
> > > implementation.
> >
> > I think a read only JNDI and a mutable one are different enough that
> > they need separate implementations.  Currently our ENC is using a the
> > EnterpriseNamingContext which does not extend ReadOnlyContext (as it
> > isn't really read only).  I'd like to keep the
> > EnterpriseNamingContext simple and strictly read only.  Therefore,
> > I'd like to see an new separate implementation.  If I were going to
> > write it, I'd base it on ConcurrentReaderHashMap and future objects
> > in Java5 (or backport-concurrent-util), but I'm not writing it, so I
> > say do whatever you are comfortable with.
> >
> > > 2. Remind myself of how the geronimo: context used to be
> > > installed.  I think the same method will still work.  We might want
> > > a gbean to specifically install it.  Make sure that programmatic
> > > binding and lookup works.
> >
> > IIRC, we add set naming provider package to
> > org.apache.geronimo.naming and when a user tries to access the "foo:"
> > root-context, the jvm looks for the class
> > org.apache.geronimo.naming.foo.fooURLContextFactory.  We still have
> > one named global that most likely gets loaded when someone looks up
> > "global:"
> >
> > > 3. Figure out how to bind stuff into this context from plans rather
> > > than java code.  Currently my idea is to do this with binding
> > > gbeans: I'm not entirely sure how to do this but one possibility
> > > would be to have them contain a Reference object and the name to
> > > bind it under.  Another possibility would be to not use References
> > > but rather have a binding gbean with say a gbean  reference to a
> > > ManagedConnectionFactoryWrapper: the gbean would call $getResource
> > > () on it and then bind the result directly into jndi.  This would
> > > result in simpler builders but more gbeans: we'd need one for
> > > resource-refs and resource-env-refs, and another one for ejbs, and
> > > another for plain gbean bindings.  One thing I like about this
> > > second plan is that  the object would only be bound in jndi while
> > > the resource was actually available.  Of course, the component that
> > > looks up the entry can still keep it until the underlying gbean
> > > support is long gone, and get exceptions when it tries to use the
> > > entry.
> >
> > I think binding will be the hardest part :)
> >
> > -dain
> >
>

Re: Implementing Global JNDI

[Krishnakumar B <ww...@gmail.com>]

Thanks for the feedback and inputs.

Regards
Krishnakumar


On 5/24/06, Dain Sundstrom <da...@iq80.com> wrote:
> On May 23, 2006, at 5:19 PM, David Jencks wrote:
>
> >
> > On May 23, 2006, at 6:28 AM, Krishnakumar B wrote:
> >
> >> Hi,
> >>
> >> I have a few doubts related to implementation of global jndi.
> >>
> >> * Currently we have java:comp/env stored in Local JNDI. In Global
> >> JNDI
> >> should objects be bound using a different namespace e.g) java: or
> >> java:global?
> >
> > IIUC java: is reserved by the j2ee spec for what it requires: thus
> > IMO we should use something else.  IIRC the original global jndi
> > context used geronimo:  I'm OK with that or maybe global:.
>
> IIRC some servers use just "/foo/bar" with no context.  If I am
> correct, we should support that also (but not the default).
>
> >>
> >> * When we implement global JNDI we have some entries in Global and
> >> All
> >> entries related to application in Local. When a user creates a
> >> context
> >> he needs to get from either global or local based on what he needs.
> >> Would it be right for lookup code to decide from where to fetch the
> >> entry based on how the Context is created?
> >>
> >> for e.g) if i say InitialContext iniCtx = new
> >> InitialContext("java:comp/env"); fetch from local
> >> and if InitialContext iniCtx = new InitialContext("java:global");
> >> fetch from global
> >
> > I'm not sure what you're asking about here.  Unless you do
> > something screwy to link one of these to the other, the contents of
> > these contexts will be completely unrelated.
>
> Looking at the JavaDocs for InitialContext, it does not have a
> constructor that takes a String.  Did you mean:
>
>   Context context = (Context) new InitialContext().lookup("java:comp/
> env");
>   Context context = (Context) new InitialContext().lookup("global:");
>
> >> * Currently in Local JNDI we store Resource References. Should global
> >> JNDI also use the same approach or can we use Object references for
> >> e.g) DataSource reference directly put in JNDI
> >
> > For j2ee components I think we should bind the same kinds of
> > References in the global jndi tree as we bind in the current java:
> > context.  What we bind for stuff that can't get into the java:
> > context needs more thought: it probably depends on what it is.  Of
> > course if the context is not read-only an app can bind whatever it
> > wants wherever it wants, thus bringing to mind the need for
> > security and permissions for this stuff.
>
> I don't think we can use the current Reference object we bind into
> our read only context because they do cache the value and never
> release it.  It is expected that the referece will be GCed when the
> J2EE application is unloaded.  It shouldn't be hard to either turn
> off the cache or to register listener for the reference target life-
> cycle events.
>
> >> Would appreciate any thoughts as i am still learning and might have
> >> missed some points to consider while trying to implement something
> >> like this.
> >
> > My plan for implementing this was:
> >
> > 1. Look at the current ReadOnlyContext implementation and figure
> > out how to make a sufficiently synchronized version of it.  I'm
> > hoping that we can have synchronized wrappers around this
> > implementation rather than needing a copy, subclass, or new
> > implementation.
>
> I think a read only JNDI and a mutable one are different enough that
> they need separate implementations.  Currently our ENC is using a the
> EnterpriseNamingContext which does not extend ReadOnlyContext (as it
> isn't really read only).  I'd like to keep the
> EnterpriseNamingContext simple and strictly read only.  Therefore,
> I'd like to see an new separate implementation.  If I were going to
> write it, I'd base it on ConcurrentReaderHashMap and future objects
> in Java5 (or backport-concurrent-util), but I'm not writing it, so I
> say do whatever you are comfortable with.
>
> > 2. Remind myself of how the geronimo: context used to be
> > installed.  I think the same method will still work.  We might want
> > a gbean to specifically install it.  Make sure that programmatic
> > binding and lookup works.
>
> IIRC, we add set naming provider package to
> org.apache.geronimo.naming and when a user tries to access the "foo:"
> root-context, the jvm looks for the class
> org.apache.geronimo.naming.foo.fooURLContextFactory.  We still have
> one named global that most likely gets loaded when someone looks up
> "global:"
>
> > 3. Figure out how to bind stuff into this context from plans rather
> > than java code.  Currently my idea is to do this with binding
> > gbeans: I'm not entirely sure how to do this but one possibility
> > would be to have them contain a Reference object and the name to
> > bind it under.  Another possibility would be to not use References
> > but rather have a binding gbean with say a gbean  reference to a
> > ManagedConnectionFactoryWrapper: the gbean would call $getResource
> > () on it and then bind the result directly into jndi.  This would
> > result in simpler builders but more gbeans: we'd need one for
> > resource-refs and resource-env-refs, and another one for ejbs, and
> > another for plain gbean bindings.  One thing I like about this
> > second plan is that  the object would only be bound in jndi while
> > the resource was actually available.  Of course, the component that
> > looks up the entry can still keep it until the underlying gbean
> > support is long gone, and get exceptions when it tries to use the
> > entry.
>
> I think binding will be the hardest part :)
>
> -dain
>

Re: Implementing Global JNDI

[Dain Sundstrom <da...@iq80.com>]

On May 23, 2006, at 5:19 PM, David Jencks wrote:

>
> On May 23, 2006, at 6:28 AM, Krishnakumar B wrote:
>
>> Hi,
>>
>> I have a few doubts related to implementation of global jndi.
>>
>> * Currently we have java:comp/env stored in Local JNDI. In Global  
>> JNDI
>> should objects be bound using a different namespace e.g) java: or
>> java:global?
>
> IIUC java: is reserved by the j2ee spec for what it requires: thus  
> IMO we should use something else.  IIRC the original global jndi  
> context used geronimo:  I'm OK with that or maybe global:.

IIRC some servers use just "/foo/bar" with no context.  If I am  
correct, we should support that also (but not the default).

>>
>> * When we implement global JNDI we have some entries in Global and  
>> All
>> entries related to application in Local. When a user creates a  
>> context
>> he needs to get from either global or local based on what he needs.
>> Would it be right for lookup code to decide from where to fetch the
>> entry based on how the Context is created?
>>
>> for e.g) if i say InitialContext iniCtx = new
>> InitialContext("java:comp/env"); fetch from local
>> and if InitialContext iniCtx = new InitialContext("java:global");
>> fetch from global
>
> I'm not sure what you're asking about here.  Unless you do  
> something screwy to link one of these to the other, the contents of  
> these contexts will be completely unrelated.

Looking at the JavaDocs for InitialContext, it does not have a  
constructor that takes a String.  Did you mean:

   Context context = (Context) new InitialContext().lookup("java:comp/ 
env");
   Context context = (Context) new InitialContext().lookup("global:");

>> * Currently in Local JNDI we store Resource References. Should global
>> JNDI also use the same approach or can we use Object references for
>> e.g) DataSource reference directly put in JNDI
>
> For j2ee components I think we should bind the same kinds of  
> References in the global jndi tree as we bind in the current java:  
> context.  What we bind for stuff that can't get into the java:  
> context needs more thought: it probably depends on what it is.  Of  
> course if the context is not read-only an app can bind whatever it  
> wants wherever it wants, thus bringing to mind the need for  
> security and permissions for this stuff.

I don't think we can use the current Reference object we bind into  
our read only context because they do cache the value and never  
release it.  It is expected that the referece will be GCed when the  
J2EE application is unloaded.  It shouldn't be hard to either turn  
off the cache or to register listener for the reference target life- 
cycle events.

>> Would appreciate any thoughts as i am still learning and might have
>> missed some points to consider while trying to implement something
>> like this.
>
> My plan for implementing this was:
>
> 1. Look at the current ReadOnlyContext implementation and figure  
> out how to make a sufficiently synchronized version of it.  I'm  
> hoping that we can have synchronized wrappers around this  
> implementation rather than needing a copy, subclass, or new  
> implementation.

I think a read only JNDI and a mutable one are different enough that  
they need separate implementations.  Currently our ENC is using a the  
EnterpriseNamingContext which does not extend ReadOnlyContext (as it  
isn't really read only).  I'd like to keep the  
EnterpriseNamingContext simple and strictly read only.  Therefore,  
I'd like to see an new separate implementation.  If I were going to  
write it, I'd base it on ConcurrentReaderHashMap and future objects  
in Java5 (or backport-concurrent-util), but I'm not writing it, so I  
say do whatever you are comfortable with.

> 2. Remind myself of how the geronimo: context used to be  
> installed.  I think the same method will still work.  We might want  
> a gbean to specifically install it.  Make sure that programmatic  
> binding and lookup works.

IIRC, we add set naming provider package to  
org.apache.geronimo.naming and when a user tries to access the "foo:"  
root-context, the jvm looks for the class  
org.apache.geronimo.naming.foo.fooURLContextFactory.  We still have  
one named global that most likely gets loaded when someone looks up  
"global:"

> 3. Figure out how to bind stuff into this context from plans rather  
> than java code.  Currently my idea is to do this with binding  
> gbeans: I'm not entirely sure how to do this but one possibility  
> would be to have them contain a Reference object and the name to  
> bind it under.  Another possibility would be to not use References  
> but rather have a binding gbean with say a gbean  reference to a  
> ManagedConnectionFactoryWrapper: the gbean would call $getResource 
> () on it and then bind the result directly into jndi.  This would  
> result in simpler builders but more gbeans: we'd need one for  
> resource-refs and resource-env-refs, and another one for ejbs, and  
> another for plain gbean bindings.  One thing I like about this  
> second plan is that  the object would only be bound in jndi while  
> the resource was actually available.  Of course, the component that  
> looks up the entry can still keep it until the underlying gbean  
> support is long gone, and get exceptions when it tries to use the  
> entry.

I think binding will be the hardest part :)

-dain

Re: Implementing Global JNDI

[David Jencks <da...@yahoo.com>]

On May 23, 2006, at 6:28 AM, Krishnakumar B wrote:

> Hi,
>
> I have a few doubts related to implementation of global jndi.
>
> * Currently we have java:comp/env stored in Local JNDI. In Global JNDI
> should objects be bound using a different namespace e.g) java: or
> java:global?

IIUC java: is reserved by the j2ee spec for what it requires: thus  
IMO we should use something else.  IIRC the original global jndi  
context used geronimo:  I'm OK with that or maybe global:.

>
> * When we implement global JNDI we have some entries in Global and All
> entries related to application in Local. When a user creates a context
> he needs to get from either global or local based on what he needs.
> Would it be right for lookup code to decide from where to fetch the
> entry based on how the Context is created?
>
> for e.g) if i say InitialContext iniCtx = new
> InitialContext("java:comp/env"); fetch from local
> and if InitialContext iniCtx = new InitialContext("java:global");
> fetch from global

I'm not sure what you're asking about here.  Unless you do something  
screwy to link one of these to the other, the contents of these  
contexts will be completely unrelated.

>
> * Currently in Local JNDI we store Resource References. Should global
> JNDI also use the same approach or can we use Object references for
> e.g) DataSource reference directly put in JNDI

For j2ee components I think we should bind the same kinds of  
References in the global jndi tree as we bind in the current java:  
context.  What we bind for stuff that can't get into the java:  
context needs more thought: it probably depends on what it is.  Of  
course if the context is not read-only an app can bind whatever it  
wants wherever it wants, thus bringing to mind the need for security  
and permissions for this stuff.
>
> Would appreciate any thoughts as i am still learning and might have
> missed some points to consider while trying to implement something
> like this.

My plan for implementing this was:

1. Look at the current ReadOnlyContext implementation and figure out  
how to make a sufficiently synchronized version of it.  I'm hoping  
that we can have synchronized wrappers around this implementation  
rather than needing a copy, subclass, or new implementation.

2. Remind myself of how the geronimo: context used to be installed.   
I think the same method will still work.  We might want a gbean to  
specifically install it.  Make sure that programmatic binding and  
lookup works.

3. Figure out how to bind stuff into this context from plans rather  
than java code.  Currently my idea is to do this with binding gbeans:  
I'm not entirely sure how to do this but one possibility would be to  
have them contain a Reference object and the name to bind it under.   
Another possibility would be to not use References but rather have a  
binding gbean with say a gbean  reference to a  
ManagedConnectionFactoryWrapper: the gbean would call $getResource()  
on it and then bind the result directly into jndi.  This would result  
in simpler builders but more gbeans: we'd need one for resource-refs  
and resource-env-refs, and another one for ejbs, and another for  
plain gbean bindings.  One thing I like about this second plan is  
that  the object would only be bound in jndi while the resource was  
actually available.  Of course, the component that looks up the entry  
can still keep it until the underlying gbean support is long gone,  
and get exceptions when it tries to use the entry.

I was planning to work on this for 1.2, but I will be more than happy  
to work with you if you would like to implement it.  Please let us  
know of your intentions, progress, and please, if you decide not to  
implement it let us know :-)

I'll be mostly offline for the next few days but will try to check  
for messages and respond as often as I can.

many thanks
david jencks

>
> Regards
> Krishnakumar
>
>
> On 4/28/06, David Jencks <da...@yahoo.com> wrote:
>>
>> 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
>> concretely
>>
>> thanks
>> 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 <gu...@worldonline.fr>
>> >>> 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
>> >>
>> >
>>
>>

Re: Implementing Global JNDI

[Krishnakumar B <ww...@gmail.com>]

Hi,

I have a few doubts related to implementation of global jndi.

* Currently we have java:comp/env stored in Local JNDI. In Global JNDI
should objects be bound using a different namespace e.g) java: or
java:global?

* When we implement global JNDI we have some entries in Global and All
entries related to application in Local. When a user creates a context
he needs to get from either global or local based on what he needs.
Would it be right for lookup code to decide from where to fetch the
entry based on how the Context is created?

for e.g) if i say InitialContext iniCtx = new
InitialContext("java:comp/env"); fetch from local
and if InitialContext iniCtx = new InitialContext("java:global");
fetch from global

* Currently in Local JNDI we store Resource References. Should global
JNDI also use the same approach or can we use Object references for
e.g) DataSource reference directly put in JNDI

Would appreciate any thoughts as i am still learning and might have
missed some points to consider while trying to implement something
like this.

Regards
Krishnakumar


On 4/28/06, David Jencks <da...@yahoo.com> wrote:
>
> 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
> concretely
>
> thanks
> 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 <gu...@worldonline.fr>
> >>> 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
> >>
> >
>
>

Re: Implementing Global JNDI

[David Jencks <da...@yahoo.com>]

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  
concretely

thanks
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 <gu...@worldonline.fr>  
>>> 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
>>
>

Re: Implementing Global JNDI

[Dain Sundstrom <da...@iq80.com>]

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.

-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 <gu...@worldonline.fr>  
>> 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
>

Re: Implementing Global JNDI

[David Jencks <da...@yahoo.com>]

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 <gu...@worldonline.fr> 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

Re: Implementing Global JNDI

[Manu George <ma...@gmail.com>]

Comments inline

On 4/26/06, Guillaume Nodet <gu...@worldonline.fr> 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

Re: Implementing Global JNDI

[Guillaume Nodet <gu...@worldonline.fr>]

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 < guillaume.nodet@worldonline.fr
>     <ma...@worldonline.fr>> 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* <david_jencks@yahoo.com
>     <ma...@yahoo.com>
>     >>><mailto: david_jencks@yahoo.com
>     <ma...@yahoo.com>>> 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
>     >>>
>     >>>
>     >>>
>     >>>
>     >
>     >
>     >
>     >
>
>

Re: Implementing Global JNDI

[Manu George <ma...@gmail.com>]

I agree with what Dain said.  I also believe that as the spec says the J2EE
component enviroment should not be writable and we need not provide any
option for that either. It is not necessary. Apps can bind to other
namespaces.

On 4/26/06, Dain Sundstrom <da...@iq80.com> wrote:
>
> Are you planning on making the J2EE component enviroment (java:comp/
> env) writable?  I can see making the global tree writable, but am
> concerned about making the component environment itself writable.
> The J2EE 1.4 spec page 64 states:
>
> The container must ensure that the application component instances
> have only
> read access to their environment variables. The container must throw the
> javax.naming.OperationNotSupportedException from all the methods of the
> javax.naming.Context interface that modify the environment naming
> context
> and its subcontexts
>
> I suppose we could add an optional flag for non-compliant
> applications to allow them to modify their environment, but I think
> the default for the component environment should be read-only.
>
> BTW, I am in favor of making everything else writable.
>
> -dain
>
> On Apr 26, 2006, at 6:32 AM, 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 < guillaume.nodet@worldonline.fr> 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* <david_jencks@yahoo.com
> > >>><mailto: david_jencks@yahoo.com>> 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
> > >>>
> > >>>
> > >>>
> > >>>
> > >
> > >
> > >
> > >
> >
>
>

Re: Implementing Global JNDI

[Dain Sundstrom <da...@iq80.com>]

Are you planning on making the J2EE component enviroment (java:comp/ 
env) writable?  I can see making the global tree writable, but am  
concerned about making the component environment itself writable.   
The J2EE 1.4 spec page 64 states:

The container must ensure that the application component instances  
have only
read access to their environment variables. The container must throw the
javax.naming.OperationNotSupportedException from all the methods of the
javax.naming.Context interface that modify the environment naming  
context
and its subcontexts

I suppose we could add an optional flag for non-compliant  
applications to allow them to modify their environment, but I think  
the default for the component environment should be read-only.

BTW, I am in favor of making everything else writable.

-dain

On Apr 26, 2006, at 6:32 AM, 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 < guillaume.nodet@worldonline.fr> 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* <david_jencks@yahoo.com
> >>><mailto: david_jencks@yahoo.com>> 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
> >>>
> >>>
> >>>
> >>>
> >
> >
> >
> >
>

Re: Implementing Global JNDI

[Manu George <ma...@gmail.com>]

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 <gu...@worldonline.fr> 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* <david_jencks@yahoo.com
> >>><ma...@yahoo.com>> 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
> >>>
> >>>
> >>>
> >>>
> >
> >
> >
> >
>

Re: Implementing Global JNDI

[Guillaume Nodet <gu...@worldonline.fr>]

It seems that these informations are stored in the configuration which 
is serialized and loaded when the configuration is started.

Cheers,
Guillaume Nodet

Krishnakumar B wrote:

>Hi Guillaume,
>
>The ENCConfigBuilder and ComponentContextBuilder are called when u
>deploy an application and need a JNDI reference. How does it happen
>when u start the app server with some apps already deployed? How is
>the Context built?
>
>Regards
>Krish
>
>On 4/26/06, Guillaume Nodet <gu...@worldonline.fr> 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* <david_jencks@yahoo.com
>>><ma...@yahoo.com>> 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
>>>
>>>
>>>      
>>>
>
>
>  
>

Re: Implementing Global JNDI

[Krishnakumar B <ww...@gmail.com>]

Hi Guillaume,

The ENCConfigBuilder and ComponentContextBuilder are called when u
deploy an application and need a JNDI reference. How does it happen
when u start the app server with some apps already deployed? How is
the Context built?

Regards
Krish

On 4/26/06, Guillaume Nodet <gu...@worldonline.fr> 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* <david_jencks@yahoo.com
> > <ma...@yahoo.com>> 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
> >
> >
>

Re: Implementing Global JNDI

[Guillaume Nodet <gu...@worldonline.fr>]

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* <david_jencks@yahoo.com 
> <ma...@yahoo.com>> 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
>
>

Re: Implementing Global JNDI

[Manu George <ma...@gmail.com>]

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 <da...@yahoo.com> 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
>
>

Re: Implementing Global JNDI

[David Jencks <da...@yahoo.com>]

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

Re: Implementing Global JNDI

[Manu George <ma...@gmail.com>]

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