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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: >> > > On 6/23/06, Krishnakumar B < [EMAIL PROTECTED]> 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 >> > > >> > >> >> >>
