You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Krishnakumar B <ww...@gmail.com> on 2006/06/23 16:42:13 UTC
Re: Implementing Global JNDI
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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
> > >
> >
>