[JBoss-dev] JNDI binding for J2EE1.4 compliant webservices
Hi all, there seems to be some confusion about how webservices are bound to JNDI. Here is my interpretation of the JSR109 spec. Maybe you whant to throw your 2 cents in. server programming model --- No mention of JNDI. The server makes the webservice available at a URL. A potential client connects to the webservice through that URL. The service is handled by the server invoking a stateless session bean, or web component. The client does not need to know which. When the client obtains the WSDL from the URL, the port address should reflect the actual location of the webservice on the server. The deployed WSDL may contain a dummy port address, which the server will have to tweak when feeding back the WSDL to a client. A deployment that contains a webservices.xml does not cause a webservice binding in JNDI. client programming model -- The deployer provides a WSDL with a valid port address in the WSDL. The client container provides the runtime environment (javax.xml.rpc.Service) in JNDI to access that webservice, ehich may point to any webservice anywhere. The client accesses that webservice like a local object through the SEI. The client container may provide an imlementation of the SEI as static stub, dynamic proxy, or DII. A deployment that contains a webservicesclient.xml causes a global webservice binding in JNDI. A client that has the webservice mapped to his java:comp/env cheers -thomas --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JNDI binding for J2EE1.4 compliant webservices
I agree with that, so what is the confusion? -- Scott Stark Chief Technology Officer JBoss Group, LLC [EMAIL PROTECTED] wrote: Hi all, there seems to be some confusion about how webservices are bound to JNDI. Here is my interpretation of the JSR109 spec. Maybe you whant to throw your 2 cents in. server programming model --- No mention of JNDI. The server makes the webservice available at a URL. A potential client connects to the webservice through that URL. The service is handled by the server invoking a stateless session bean, or web component. The client does not need to know which. When the client obtains the WSDL from the URL, the port address should reflect the actual location of the webservice on the server. The deployed WSDL may contain a dummy port address, which the server will have to tweak when feeding back the WSDL to a client. A deployment that contains a webservices.xml does not cause a webservice binding in JNDI. client programming model -- The deployer provides a WSDL with a valid port address in the WSDL. The client container provides the runtime environment (javax.xml.rpc.Service) in JNDI to access that webservice, ehich may point to any webservice anywhere. The client accesses that webservice like a local object through the SEI. The client container may provide an imlementation of the SEI as static stub, dynamic proxy, or DII. A deployment that contains a webservicesclient.xml causes a global webservice binding in JNDI. A client that has the webservice mapped to his java:comp/env cheers -thomas --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] JNDI binding for J2EE1.4 compliant webservices
-Ursprüngliche Nachricht- Von: Scott M Stark [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 20. November 2003 16:07 An: [EMAIL PROTECTED] Betreff: Re: [JBoss-dev] JNDI binding for J2EE1.4 compliant webservices I agree with that, so what is the confusion? From my reading, I was seeing the relation between server and client programming more analogously to the existing EJB/J2EE specification bits. I was proposing to bind the service references into (global) JNDI by the JSR109Deployer regardless of whether a client app is present (as we do with the ejb stubs). The JSR109ClientDeployer would then only live in client processes and just dealing with generating link-refs into the local client JNDI. Furthermore, there is IMHO the possibility (requirement) to use service-endpoint references in the server programming model just as ejb-ref and servlet-ref. CGJ ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: AW: [JBoss-dev] JNDI binding for J2EE1.4 compliant webservices
I don't see a problem with doing that, and in fact, if the behavior of the deployer is more consistent with existing, can reuse existing logic, etc. if this is the mode of operation then this is fine. Its really an implementation detail that the spec is not going to define. It would also probably simplify the j2ee application client because without the server side setup of the jax-rpc binding the app client deployer has to do this. -- Scott Stark Chief Technology Officer JBoss Group, LLC Jung , Dr. Christoph wrote: From my reading, I was seeing the relation between server and client programming more analogously to the existing EJB/J2EE specification bits. I was proposing to bind the service references into (global) JNDI by the JSR109Deployer regardless of whether a client app is present (as we do with the ejb stubs). The JSR109ClientDeployer would then only live in client processes and just dealing with generating link-refs into the local client JNDI. Furthermore, there is IMHO the possibility (requirement) to use service-endpoint references in the server programming model just as ejb-ref and servlet-ref. CGJ --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
FW: [JBoss-dev] JNDI lookup problem with webservice client
Scott, the problem with the JNDI lookup of org.apache.axis.client.Service lies within the org.apache.axis.client.ServiceFactory. It wants either the service classname or the WSDL location. If neither is set, it'll return null. The JNDI spec allows for a null return from ObjectFactory.getObjectInstance when the object cannot be created. Cheers -thomas -Original Message- From: Thomas Diesler [mailto:[EMAIL PROTECTED] Sent: Thursday, November 13, 2003 9:44 AM To: '[EMAIL PROTECTED]' Subject: RE: [JBoss-dev] JNDI lookup problem with webservice client ... here is the test: org.jboss.test.webservice.ws4eeclient.HelloClientTestCase thanks -thomas -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Scott M Stark Sent: Tuesday, November 11, 2003 9:43 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JNDI lookup problem with webservice client No, not that I can see from this. Check the test in and let me look at it. -- Scott Stark Chief Technology Officer JBoss Group, LLC [EMAIL PROTECTED] wrote: Scott, working on the webservice client programing model, I need to bind a javax.xml.rpc.Service to JNDI. In the test below I bind it to the global JNDI namespace. However, when I lookup the service I get null without a NamingException. The code below first tests if the service object can be serialized without JNDI involvement, then it tests if bind/lookup of a trival string object works. Finally the actual service is bound (I can see it in jmx-console) and then looked up again. The last assertion fails. Any idea? cheers -thomas -- String SERVICE_JNDI_NAME = service/HelloWsService1; Service service = new org.apache.axis.client.Service(); // first try to marshal/unmarshal the service without JNDI ByteArrayOutputStream baos = new ByteArrayOutputStream(1024); ObjectOutputStream oos = new ObjectOutputStream(baos); oos.writeObject(service); oos.close(); ByteArrayInputStream bais = new ByteArrayInputStream(baos.toByteArray()); ObjectInputStream ois = new ObjectInputStream(bais); service = (Service)ois.readObject(); assertNotNull(cannot serialize service, service); // test JNDI lookup with a trivial String InitialContext iniCtx = getInitialContext(); Util.bind(iniCtx, SERVICE_JNDI_NAME, Test JNDI); assertEquals(Test JNDI, iniCtx.lookup(SERVICE_JNDI_NAME)); Util.unbind(iniCtx, SERVICE_JNDI_NAME); service = new org.apache.axis.client.Service(); // now do the actual binding and lookup Util.bind(iniCtx, SERVICE_JNDI_NAME, service); service = (Service)iniCtx.lookup(SERVICE_JNDI_NAME); assertNotNull (cannot lookup service, service); Util.unbind(iniCtx, SERVICE_JNDI_NAME); --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] JNDI lookup problem with webservice client
Thomas, Another possibility of binding webservices into JNDI is using references and an associated ServiceFactory (see the behaviour of external web service references in jboss.net). With that approach, you have more control about the serialisation process, classloading issues and engine affiliations. CGJ -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 11. November 2003 21:27 An: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Betreff: [JBoss-dev] JNDI lookup problem with webservice client Scott, working on the webservice client programing model, I need to bind a javax.xml.rpc.Service to JNDI. In the test below I bind it to the global JNDI namespace. However, when I lookup the service I get null without a NamingException. The code below first tests if the service object can be serialized without JNDI involvement, then it tests if bind/lookup of a trival string object works. Finally the actual service is bound (I can see it in jmx-console) and then looked up again. The last assertion fails. Any idea? cheers -thomas -- String SERVICE_JNDI_NAME = service/HelloWsService1; Service service = new org.apache.axis.client.Service(); // first try to marshal/unmarshal the service without JNDI ByteArrayOutputStream baos = new ByteArrayOutputStream(1024); ObjectOutputStream oos = new ObjectOutputStream(baos); oos.writeObject(service); oos.close(); ByteArrayInputStream bais = new ByteArrayInputStream(baos.toByteArray()); ObjectInputStream ois = new ObjectInputStream(bais); service = (Service)ois.readObject(); assertNotNull(cannot serialize service, service); // test JNDI lookup with a trivial String InitialContext iniCtx = getInitialContext(); Util.bind(iniCtx, SERVICE_JNDI_NAME, Test JNDI); assertEquals(Test JNDI, iniCtx.lookup(SERVICE_JNDI_NAME)); Util.unbind(iniCtx, SERVICE_JNDI_NAME); service = new org.apache.axis.client.Service(); // now do the actual binding and lookup Util.bind(iniCtx, SERVICE_JNDI_NAME, service); service = (Service)iniCtx.lookup(SERVICE_JNDI_NAME); assertNotNull (cannot lookup service, service); Util.unbind(iniCtx, SERVICE_JNDI_NAME); --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JNDI lookup problem with webservice client
Scott, working on the webservice client programing model, I need to bind a javax.xml.rpc.Service to JNDI. In the test below I bind it to the global JNDI namespace. However, when I lookup the service I get null without a NamingException. The code below first tests if the service object can be serialized without JNDI involvement, then it tests if bind/lookup of a trival string object works. Finally the actual service is bound (I can see it in jmx-console) and then looked up again. The last assertion fails. Any idea? cheers -thomas -- String SERVICE_JNDI_NAME = service/HelloWsService1; Service service = new org.apache.axis.client.Service(); // first try to marshal/unmarshal the service without JNDI ByteArrayOutputStream baos = new ByteArrayOutputStream(1024); ObjectOutputStream oos = new ObjectOutputStream(baos); oos.writeObject(service); oos.close(); ByteArrayInputStream bais = new ByteArrayInputStream(baos.toByteArray()); ObjectInputStream ois = new ObjectInputStream(bais); service = (Service)ois.readObject(); assertNotNull(cannot serialize service, service); // test JNDI lookup with a trivial String InitialContext iniCtx = getInitialContext(); Util.bind(iniCtx, SERVICE_JNDI_NAME, Test JNDI); assertEquals(Test JNDI, iniCtx.lookup(SERVICE_JNDI_NAME)); Util.unbind(iniCtx, SERVICE_JNDI_NAME); service = new org.apache.axis.client.Service(); // now do the actual binding and lookup Util.bind(iniCtx, SERVICE_JNDI_NAME, service); service = (Service)iniCtx.lookup(SERVICE_JNDI_NAME); assertNotNull (cannot lookup service, service); Util.unbind(iniCtx, SERVICE_JNDI_NAME); --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JNDI lookup problem with webservice client
No, not that I can see from this. Check the test in and let me look at it. -- Scott Stark Chief Technology Officer JBoss Group, LLC [EMAIL PROTECTED] wrote: Scott, working on the webservice client programing model, I need to bind a javax.xml.rpc.Service to JNDI. In the test below I bind it to the global JNDI namespace. However, when I lookup the service I get null without a NamingException. The code below first tests if the service object can be serialized without JNDI involvement, then it tests if bind/lookup of a trival string object works. Finally the actual service is bound (I can see it in jmx-console) and then looked up again. The last assertion fails. Any idea? cheers -thomas -- String SERVICE_JNDI_NAME = service/HelloWsService1; Service service = new org.apache.axis.client.Service(); // first try to marshal/unmarshal the service without JNDI ByteArrayOutputStream baos = new ByteArrayOutputStream(1024); ObjectOutputStream oos = new ObjectOutputStream(baos); oos.writeObject(service); oos.close(); ByteArrayInputStream bais = new ByteArrayInputStream(baos.toByteArray()); ObjectInputStream ois = new ObjectInputStream(bais); service = (Service)ois.readObject(); assertNotNull(cannot serialize service, service); // test JNDI lookup with a trivial String InitialContext iniCtx = getInitialContext(); Util.bind(iniCtx, SERVICE_JNDI_NAME, Test JNDI); assertEquals(Test JNDI, iniCtx.lookup(SERVICE_JNDI_NAME)); Util.unbind(iniCtx, SERVICE_JNDI_NAME); service = new org.apache.axis.client.Service(); // now do the actual binding and lookup Util.bind(iniCtx, SERVICE_JNDI_NAME, service); service = (Service)iniCtx.lookup(SERVICE_JNDI_NAME); assertNotNull (cannot lookup service, service); Util.unbind(iniCtx, SERVICE_JNDI_NAME); --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JNDI
Title: JNDI is there a reason why a ctx.lookup() would give one result within the JBoss JMV and a different result outside the JBoss JVM? thanks, frank
Re: [JBoss-dev] jndi props in testsuite
Scott is correct as to the solution. The problem: if the loading is done with codeclassloader.getResource(jndi.properties);/code then the classloading goes parent and finds classpath ones and returns that. This is a reason why in JBoss 2.x we use local CL to jars by not setting the parent to the JBoss CL. I can't remember if the classpath cl is always parent to a classpath, does anyone remember? marcf __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=6733 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JNDI View
JNDIView should not depend on anything other than the naming serivce. It needs a mechanism to query for the ObjectNames of the deployers from which it attempts to obtain the deployed application info from, or this needs to be available in a different manner. - Original Message - From: Adrian Brock [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, January 05, 2002 7:03 PM Subject: [JBoss-dev] JNDI View JNDI View is broken due to the JMX Domain changes. The container factory is now registered in domain jboss.j2ee but ContainerFactoryMBean has no domain so the default jboss is used. Two points: 1) Shouldn't it be possible to run jboss without j2ee, so why does it barf when it can't find this service? One line saying j2ee is not present would be better. The log can contain the full exception trace as a warning. 2) If it really does depend on this service, this could be configured with a depends optional-attribute-name=J2EEContainerFactoryjboss.j2ee:service=ContainerF actory/depends Regards, Adrian __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=6719 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jndi props in testsuite
If I add a jndi.properties file to a testsuite jar, will it use that file for InitialContext? InitialContext looks for jndi.properties in the CLASSPATH correct? Thanks, Bill
Re: [JBoss-dev] jndi props in testsuite
I'm not at all sure... I think that the testcase classes are not packaged into a jar at the moment, and there is one jndi.properties on the classpath that gets used for all of them by default. This is very handy for non-cluster tests, but obviously may not work for you. Could you create an initial context from an explicitly found jndi-cluster.properties on the classpath so as not to disturb the non cluster testcases? thanks david jencks On 2002.01.06 10:06:06 -0500 Bill Burke wrote: If I add a jndi.properties file to a testsuite jar, will it use that file for InitialContext? InitialContext looks for jndi.properties in the CLASSPATH correct? Thanks, Bill ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jndi props in testsuite
No, the unit tests run out of the build.classes directory and do not use the output jars. You would need to load the testcase specific jndi.properties and use an explicit env in the construction of the InitialContext. You could try setting the System.properties from the testcase jndi.properties and this should take precedence over the values found in the classpath, but I'm not sure of the load ordering. - Original Message - From: Bill Burke To: [EMAIL PROTECTED] Sent: Sunday, January 06, 2002 7:06 AM Subject: [JBoss-dev] jndi props in testsuite If I add a jndi.properties file to a testsuite jar, will it use that file for InitialContext? InitialContext looks for jndi.properties in the CLASSPATH correct? Thanks, Bill ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JNDI View
JNDI View is broken due to the JMX Domain changes. The container factory is now registered in domain jboss.j2ee but ContainerFactoryMBean has no domain so the default jboss is used. Two points: 1) Shouldn't it be possible to run jboss without j2ee, so why does it barf when it can't find this service? One line saying j2ee is not present would be better. The log can contain the full exception trace as a warning. 2) If it really does depend on this service, this could be configured with a depends optional-attribute-name=J2EEContainerFactoryjboss.j2ee:service=ContainerFactory/depends Regards, Adrian __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=6719 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JNDI view of java:comp context from Jetty broken
Sorry guys, Somehow the code that sets up the ENC stuff move places during a reshuffle. I've put it back now. Please let me know if you still have problems. Apologies for taking so long to sort this out - i haven't been at my machine for a couple of days. Jules P.S. Thanks also to those concerned for the fixURL() 'fix' - I should have called mine ' breakURL' ! Scott M Stark wrote: No, I don't see the java:comp context for this standalone war. The AbstractWebContainer.parseWebAppDescriptors is not being called as part of the deploy so the ENC is not getting created. There is some integration problem between Jetty and the AbstractWebContainer for a single war I'll look into. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Peter Levart [EMAIL PROTECTED] To: Scott M Stark [EMAIL PROTECTED]; Scott M Stark [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, November 30, 2001 8:42 AM Subject: Re: [JBoss-dev] JNDI view of java:comp context from Jetty broken On Friday 30 November 2001 12:38, Scott M Stark wrote: I just looked at the latest build with the jbosstest.ear from the testsuite module and the DebugServlet http://localhost:8080/jbosstest/DebugServlet is displaying the full java:comp context correctly: I tried that too and it is displaying it correctly for me too. I don't know why it is working for that particular test app and why not for my app. So I did a fresh checkout of jboss-all and I created a minimal jbosstest.war composed of only the: DebugServlet.java, Util.java web.xml. Attached to the message you will find it. Not displaying java:comp. Please, can you try it? Am I missing something? Can you make it display the java:comp/env/Strings/s1 ? Peter ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JNDI view of java:comp context from Jetty broken
I'm still not happy about this - there is still something broken in my build. If you guys can survive another 24 hours, i shall try to sort it out tomorrow. Apologies to anyone I am holding up - I know how frustrating it can be. Jules Julian Gosnell wrote: Sorry guys, Somehow the code that sets up the ENC stuff move places during a reshuffle. I've put it back now. Please let me know if you still have problems. Apologies for taking so long to sort this out - i haven't been at my machine for a couple of days. Jules P.S. Thanks also to those concerned for the fixURL() 'fix' - I should have called mine ' breakURL' ! Scott M Stark wrote: No, I don't see the java:comp context for this standalone war. The AbstractWebContainer.parseWebAppDescriptors is not being called as part of the deploy so the ENC is not getting created. There is some integration problem between Jetty and the AbstractWebContainer for a single war I'll look into. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Peter Levart [EMAIL PROTECTED] To: Scott M Stark [EMAIL PROTECTED]; Scott M Stark [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, November 30, 2001 8:42 AM Subject: Re: [JBoss-dev] JNDI view of java:comp context from Jetty broken On Friday 30 November 2001 12:38, Scott M Stark wrote: I just looked at the latest build with the jbosstest.ear from the testsuite module and the DebugServlet http://localhost:8080/jbosstest/DebugServlet is displaying the full java:comp context correctly: I tried that too and it is displaying it correctly for me too. I don't know why it is working for that particular test app and why not for my app. So I did a fresh checkout of jboss-all and I created a minimal jbosstest.war composed of only the: DebugServlet.java, Util.java web.xml. Attached to the message you will find it. Not displaying java:comp. Please, can you try it? Am I missing something? Can you make it display the java:comp/env/Strings/s1 ? Peter ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JNDI view of java:comp context from Jetty broken
I just took a look at this and it has been fixed by Jules. - Original Message - From: Peter Levart [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Jules Gosnell [EMAIL PROTECTED] Sent: Saturday, December 01, 2001 7:47 AM Subject: Re: [JBoss-dev] JNDI view of java:comp context from Jetty broken On Saturday 01 December 2001 04:20, Scott M Stark wrote: No, I don't see the java:comp context for this standalone war. The AbstractWebContainer.parseWebAppDescriptors is not being called as part of the deploy so the ENC is not getting created. There is some integration problem between Jetty and the AbstractWebContainer for a single war I'll look into. I dit some traceback and it appears that AbstractWebContainer subclass (org.jboss.jetty.JettyService) is not calling WebDescriptorParser.parseWebAppDescriptors(). The call to parseWebAppDescriptors() is being made from within org.jboss.jetty.JBossWebApplicationContext.JBossSXSecurityHandler.start() method, which is not called since no JBossSXSecurityHandler instance is ever created. The JBossWebApplicationContext.getSecurityHandler() is never called. It's true. I have not yet configured the security in my app. But it should work nevertheless. Why is parsing done in JBossSXSecurityHandler's start() method? Because the start() method is called with the correct thread's contextClassLoader? If it is different than thread's contextClassLoader when performDeploy is called then it should be the child of it as it is asserted in the sanity check being made in JBossSXSecurityHandler.start() method. So I made a test and moved the parseWebAppDescriptors() call from the JBossSXSecurityHandler.start() method to the org.jboss.jetty.Jetty.deploy() method, just before JBossWebApplicationContext.start() method is called. It works. Peter ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JNDI view of java:comp context from Jetty broken
On Saturday 01 December 2001 04:20, Scott M Stark wrote: No, I don't see the java:comp context for this standalone war. The AbstractWebContainer.parseWebAppDescriptors is not being called as part of the deploy so the ENC is not getting created. There is some integration problem between Jetty and the AbstractWebContainer for a single war I'll look into. I also have the same problem with my bigger app that is a complete ear with ejb-jar war. I'm only using standard J2EE deployment descriptors + jbosscmp-jdbc.xml (no jboss-web.xml or jboss.xml). This was working some couple of days ago, but stopped recently. Peter ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JNDI view of java:comp context from Jetty broken
On Saturday 01 December 2001 04:20, Scott M Stark wrote: No, I don't see the java:comp context for this standalone war. The AbstractWebContainer.parseWebAppDescriptors is not being called as part of the deploy so the ENC is not getting created. There is some integration problem between Jetty and the AbstractWebContainer for a single war I'll look into. I dit some traceback and it appears that AbstractWebContainer subclass (org.jboss.jetty.JettyService) is not calling WebDescriptorParser.parseWebAppDescriptors(). The call to parseWebAppDescriptors() is being made from within org.jboss.jetty.JBossWebApplicationContext.JBossSXSecurityHandler.start() method, which is not called since no JBossSXSecurityHandler instance is ever created. The JBossWebApplicationContext.getSecurityHandler() is never called. It's true. I have not yet configured the security in my app. But it should work nevertheless. Why is parsing done in JBossSXSecurityHandler's start() method? Because the start() method is called with the correct thread's contextClassLoader? If it is different than thread's contextClassLoader when performDeploy is called then it should be the child of it as it is asserted in the sanity check being made in JBossSXSecurityHandler.start() method. So I made a test and moved the parseWebAppDescriptors() call from the JBossSXSecurityHandler.start() method to the org.jboss.jetty.Jetty.deploy() method, just before JBossWebApplicationContext.start() method is called. It works. Peter Here are the diffs: Index: JBossWebApplicationContext.java === RCS file: /cvsroot/jboss/contrib/jetty/src/main/org/jboss/jetty/JBossWebApplicationContext.java,v retrieving revision 1.4 diff -c -r1.4 JBossWebApplicationContext.java *** JBossWebApplicationContext.java 2001/11/28 01:22:25 1.4 --- JBossWebApplicationContext.java 2001/12/01 15:46:02 *** *** 117,125 } // Parse descriptors and set up the JNDI environment ! Element webAppDD = _webApp.getWebApp(); ! Element jbossDD = _webApp.getJbossWeb(); ! _descriptorParser.parseWebAppDescriptors(loader, webAppDD, jbossDD); // Add the JBoss security realm String realmName = getRealm(); --- 117,125 } // Parse descriptors and set up the JNDI environment ! // Element webAppDD = _webApp.getWebApp(); ! // Element jbossDD = _webApp.getJbossWeb(); ! // _descriptorParser.parseWebAppDescriptors(loader, webAppDD, jbossDD); // Add the JBoss security realm String realmName = getRealm(); *** *** 246,248 --- 246,249 return path.substring(jar:file:.length(),path.length()-(resource.length()+2)); } } + Index: Jetty.java === RCS file: /cvsroot/jboss/contrib/jetty/src/main/org/jboss/jetty/Jetty.java,v retrieving revision 1.24 diff -c -r1.24 Jetty.java *** Jetty.java 2001/11/29 01:21:29 1.24 --- Jetty.java 2001/12/01 15:46:02 *** *** 204,209 --- 204,213 _log.info(no jboss-web.xml found); } + // + // delegate parsing of some elements to descriptorParser + descriptorParser.parseWebAppDescriptors(cl, wa.getWebApp(), wa.getJbossWeb()); + // finally start the app app.start(); *** *** 287,289 --- 291,294 url.substring(index, url.length()); } } + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JNDI view of java:comp context from Jetty broken
Hello! There seems to be something wrong with java:comp naming context as seen from within Jetty in the latest CVS sources. That's what a servlet sees when the app is run in a JBoss/Jetty from a couple of days ago: +- jaas +- TransactionPropagationContextImporter +- JmsXA +- MinervaSharedLocalCMFactory +- DefaultDS +- StdJMSPool +- MinervaXACMFactory +- TransactionManager +- TransactionPropagationContextExporter +- ConnectionFactory +- DefaultJMSProvider +- XAConnectionFactory +- Mail +- NoTransDS +- SecurityProxyFactory +- comp | +- UserTransaction[link - UserTransaction] | +- env | | +- ejb | | | +- CustomersSessionRemote[link - CustomersSessionBean] | | +- security | | | +- realmMapping | | | +- securityMgr +- MinervaNoTransCMFactory +- Sybase_J2EETEST And that's the same app run in todays build: +- jaas +- TransactionPropagationContextImporter +- JmsXA +- MinervaSharedLocalCMFactory +- DefaultDS +- StdJMSPool +- MinervaXACMFactory +- TransactionManager +- TransactionPropagationContextExporter +- ConnectionFactory +- DefaultJMSProvider +- XAConnectionFactory +- Mail +- NoTransDS +- SecurityProxyFactory +- comp +- MinervaNoTransCMFactory +- Sybase_J2EETEST Notice that java:comp context is empty. Has anybody else noticed that? Peter ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JNDI view of java:comp context from Jetty broken
I just looked at the latest build with the jbosstest.ear from the testsuite module and the DebugServlet http://localhost:8080/jbosstest/DebugServlet is displaying the full java:comp context correctly: java:comp +- UserTransaction[link - UserTransaction] +- env | +- mail | | +- DefaultMail[link - java:/Mail] | +- jdbc | | +- DefaultDS[link - java:/DefaultDS] | +- ejb | | +- OptimizedEJB[link - OptimizedEJB] | | +- bean2[link - ENCBean1] | | +- bean1[link - ENCBean1] | | +- catalog | | | +- CatalogDAOClass | | +- bean0[link - ENCBean0] | | +- CtsBmp[link - ejbcts/BMPBean] | | +- SecuredEJB[link - jbosstest/ejbs/SecuredEJB] | | +- UnsecuredEJB[link - jbosstest/ejbs/UnsecuredEJB] | +- Floats | | +- f1 | | +- f0 | +- Strings | | +- s1 | | +- s0 | +- Ints | | +- i1 | | +- i0 | +- security | | +- realmMapping[link - java:/jaas/other] | | +- securityMgr[link - java:/jaas/other] | +- jms | | +- QueFactory[link - ConnectionFactory] Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Peter Levart [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, November 30, 2001 1:18 AM Subject: [JBoss-dev] JNDI view of java:comp context from Jetty broken Hello! There seems to be something wrong with java:comp naming context as seen from within Jetty in the latest CVS sources. That's what a servlet sees when the app is run in a JBoss/Jetty from a couple of days ago: +- jaas +- TransactionPropagationContextImporter +- JmsXA +- MinervaSharedLocalCMFactory +- DefaultDS +- StdJMSPool +- MinervaXACMFactory +- TransactionManager +- TransactionPropagationContextExporter +- ConnectionFactory +- DefaultJMSProvider +- XAConnectionFactory +- Mail +- NoTransDS +- SecurityProxyFactory +- comp | +- UserTransaction[link - UserTransaction] | +- env | | +- ejb | | | +- CustomersSessionRemote[link - CustomersSessionBean] | | +- security | | | +- realmMapping | | | +- securityMgr +- MinervaNoTransCMFactory +- Sybase_J2EETEST And that's the same app run in todays build: +- jaas +- TransactionPropagationContextImporter +- JmsXA +- MinervaSharedLocalCMFactory +- DefaultDS +- StdJMSPool +- MinervaXACMFactory +- TransactionManager +- TransactionPropagationContextExporter +- ConnectionFactory +- DefaultJMSProvider +- XAConnectionFactory +- Mail +- NoTransDS +- SecurityProxyFactory +- comp +- MinervaNoTransCMFactory +- Sybase_J2EETEST Notice that java:comp context is empty. Has anybody else noticed that? Peter ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JNDI view of java:comp context from Jetty broken
On Friday 30 November 2001 12:38, Scott M Stark wrote: I just looked at the latest build with the jbosstest.ear from the testsuite module and the DebugServlet http://localhost:8080/jbosstest/DebugServlet is displaying the full java:comp context correctly: I tried that too and it is displaying it correctly for me too. I don't know why it is working for that particular test app and why not for my app. So I did a fresh checkout of jboss-all and I created a minimal jbosstest.war composed of only the: DebugServlet.java, Util.java web.xml. Attached to the message you will find it. Not displaying java:comp. Please, can you try it? Am I missing something? Can you make it display the java:comp/env/Strings/s1 ? Peter jbosstest.war Description: Zip archive
Re: [JBoss-dev] JNDI view of java:comp context from Jetty broken
Peter, Have a look at https://sourceforge.net/tracker/index.php?func=detailaid=482875group_id=22866atid=376685 I think this fix might have broken your app. The code in org.jboss.naming.ENCFactory does a synchronized(encs) when manipulating the cache, but I don't think the garbage collector will respect this? I suspect the WeakHashMap might be broken because of concurrent access. I'll do some more testing when I've had some sleep. Regards, Adrian From: Peter Levart [EMAIL PROTECTED] To: Scott M Stark [EMAIL PROTECTED], Scott M Stark [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JNDI view of java:comp context from Jetty broken Date: Fri, 30 Nov 2001 17:42:33 +0100 On Friday 30 November 2001 12:38, Scott M Stark wrote: I just looked at the latest build with the jbosstest.ear from the testsuite module and the DebugServlet http://localhost:8080/jbosstest/DebugServlet is displaying the full java:comp context correctly: I tried that too and it is displaying it correctly for me too. I don't know why it is working for that particular test app and why not for my app. So I did a fresh checkout of jboss-all and I created a minimal jbosstest.war composed of only the: DebugServlet.java, Util.java web.xml. Attached to the message you will find it. Not displaying java:comp. Please, can you try it? Am I missing something? Can you make it display the java:comp/env/Strings/s1 ? Peter jbosstest.war _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JNDI view of java:comp context from Jetty broken
That is not the issue. The problem exists with the standalone war env if ENCFactory is switched back to use HashMap instead of WeakHashMap. - Original Message - From: Adrian Brock [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, November 30, 2001 4:36 PM Subject: Re: [JBoss-dev] JNDI view of java:comp context from Jetty broken Peter, Have a look at https://sourceforge.net/tracker/index.php?func=detailaid=482875group_id=22 866atid=376685 I think this fix might have broken your app. The code in org.jboss.naming.ENCFactory does a synchronized(encs) when manipulating the cache, but I don't think the garbage collector will respect this? I suspect the WeakHashMap might be broken because of concurrent access. I'll do some more testing when I've had some sleep. Regards, Adrian From: Peter Levart [EMAIL PROTECTED] To: Scott M Stark [EMAIL PROTECTED], Scott M Stark [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JNDI view of java:comp context from Jetty broken Date: Fri, 30 Nov 2001 17:42:33 +0100 On Friday 30 November 2001 12:38, Scott M Stark wrote: I just looked at the latest build with the jbosstest.ear from the testsuite module and the DebugServlet http://localhost:8080/jbosstest/DebugServlet is displaying the full java:comp context correctly: I tried that too and it is displaying it correctly for me too. I don't know why it is working for that particular test app and why not for my app. So I did a fresh checkout of jboss-all and I created a minimal jbosstest.war composed of only the: DebugServlet.java, Util.java web.xml. Attached to the message you will find it. Not displaying java:comp. Please, can you try it? Am I missing something? Can you make it display the java:comp/env/Strings/s1 ? Peter jbosstest.war _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JNDI view of java:comp context from Jetty broken
No, I don't see the java:comp context for this standalone war. The AbstractWebContainer.parseWebAppDescriptors is not being called as part of the deploy so the ENC is not getting created. There is some integration problem between Jetty and the AbstractWebContainer for a single war I'll look into. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Peter Levart [EMAIL PROTECTED] To: Scott M Stark [EMAIL PROTECTED]; Scott M Stark [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, November 30, 2001 8:42 AM Subject: Re: [JBoss-dev] JNDI view of java:comp context from Jetty broken On Friday 30 November 2001 12:38, Scott M Stark wrote: I just looked at the latest build with the jbosstest.ear from the testsuite module and the DebugServlet http://localhost:8080/jbosstest/DebugServlet is displaying the full java:comp context correctly: I tried that too and it is displaying it correctly for me too. I don't know why it is working for that particular test app and why not for my app. So I did a fresh checkout of jboss-all and I created a minimal jbosstest.war composed of only the: DebugServlet.java, Util.java web.xml. Attached to the message you will find it. Not displaying java:comp. Please, can you try it? Am I missing something? Can you make it display the java:comp/env/Strings/s1 ? Peter ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JNDI Problem
Hi Geeks I tried to register the following EJB at the JNDI server ejb/jmx/ejb/adaptor and it caused an AlreadyBoundException; remaining name 'ejb' on J2eeDeployer.startModules. This works fine with JBoss 2.4 on the same box. Andy ideas ? Andy ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JNDI - Problem
What is trying to connect to 127.0.0.2 ? Why is any machine configured to
use 127.0.0.2 as its ip addr?
--jason
On Mon, 10 Sep 2001, Andreas Schaefer wrote:
Hi Geeks
Maybe it is just me but I have a problem to access
JBoss JNDI naming service from Windows to an
Linux box but vice versa is working fine.
Environment:
- SuSE Linux 7.1, Kernel 2.4, IBM Java 2, JNDI naming bound to 1099,
JBoss 2.4 with Jetty, EJB successfully deployed
-Windows 2000, Java Version 1.3.1 and 1.4, Java application trying to access
the deployed EJB on the remote server
Any ideas ? - Andy
That is the stack trace:
JNDI Context properties:
{java.naming.factory.initial=org.jnp.interfaces.NamingC
ontextFactory, java.naming.provider.url=mpg-dev-2:1099,
java.naming.factory.url.
pkgs=org.jboss.naming:org.jnp.interfaces}
javax.naming.CommunicationException. Root exception is
java.rmi.ConnectExceptio
n: Connection refused to host: 127.0.0.2; nested exception is:
java.net.ConnectException: Connection refused: connect
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(Unknown Source)
at sun.rmi.transport.tcp.TCPChannel.createConnection(Unknown Source)
at sun.rmi.transport.tcp.TCPChannel.newConnection(Unknown Source)
at sun.rmi.server.UnicastRef.invoke(Unknown Source)
at org.jnp.server.NamingServer_Stub.lookup(Unknown Source)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:349)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:333)
at javax.naming.InitialContext.lookup(Unknown Source)
at
org.jboss.connector.ejb.EJBConnector.getAdaptorBean(EJBConnector.java
:177)
at
org.jboss.connector.ejb.EJBConnector.init(EJBConnector.java:127)
at
org.jboss.connector.ejb.EJBConnector.init(EJBConnector.java:113)
at test.jboss.jmx.TestClient.init(TestClient.java:80)
at test.jboss.jmx.TestClient$1.run(TestClient.java:62)
at java.security.AccessController.doPrivileged(Native Method)
at test.jboss.jmx.TestClient.main(TestClient.java:59)
Caused by: java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(Unknown Source)
at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at java.net.Socket.init(Unknown Source)
at java.net.Socket.init(Unknown Source)
at
sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(Unknown S
ource)
at
sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(Unknown S
ource)
... 15 more
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JNDI - Problem
Good question, I have no idea. Strange is that local lookups from the Linux server are working fine, too. Only when W2K tries to make the lookup it fails this way. I will try to make the lookup from another Linux box. Andy - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, September 10, 2001 5:31 PM Subject: Re: [JBoss-dev] JNDI - Problem What is trying to connect to 127.0.0.2 ? Why is any machine configured to use 127.0.0.2 as its ip addr? --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jndi-name element example?
The snippet below is from jboss.dtd/jboss_2_4.dtd. Whats with the t3://? Isn't that from the BEA opposition :-) The jndi-name element gives the deployed name of the reference. The general form is jndi-namet3://otherserver/application/beanB/jndi-name Shouldn't it be something like --- ... jndi-namehostname:port//otherserver/application/beanB/jndi-name for example jndi-namelocalhost:1099//otherserver/application/beanB/jndi-name --- Mike S-R ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jndi-name element example?
That particular comment appears before a commented out declaration of the jndi-name element and both should be removed. There is no general form for the jndi-name as it depends on the JNDI naming provider. Examples of different forms of JNDI names could be added to the other jndi-element declaration. - Original Message - From: Mike Swainston-Rainford [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, June 24, 2001 3:14 PM Subject: [JBoss-dev] jndi-name element example? The snippet below is from jboss.dtd/jboss_2_4.dtd. Whats with the t3://? Isn't that from the BEA opposition :-) The jndi-name element gives the deployed name of the reference. The general form is jndi-namet3://otherserver/application/beanB/jndi-name Shouldn't it be something like --- ... jndi-namehostname:port//otherserver/application/beanB/jndi-name for example jndi-namelocalhost:1099//otherserver/application/beanB/jndi-name --- Mike S-R ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JNDI and Connection Pool, etc
I'm using JBoss 2.0FINAL with TomCat and WebLogic's jDriver for SQL Server, and would like to use JNDI to look up my database connection pool, and also a few environment variables set in the web.xml file (via env-entry elements). /lib/ext has: mssql.jar (the WebLogic SQLServer driver) jboss.properties has: jdbc.drivers=org.hsql.jdbcDriver,org.enhydra.instantdb.jdbc.idbDriver,weblog ic.jdbc20.mssqlserver4.Driver jboss.conf file has: ... MLET CODE="org.jboss.jdbc.XADataSourceLoader" ARCHIVE="jboss.jar" CODEBASE="../../lib/ext/" ARG TYPE="java.lang.String" VALUE="InstantDB" ARG TYPE="java.lang.String" VALUE="org.jboss.minerva.xa.XADataSourceImpl" /MLET MLET CODE="org.jboss.jdbc.XADataSourceLoader" ARCHIVE="jboss.jar" CODEBASE="../../lib/ext/" ARG TYPE="java.lang.String" VALUE="DefaultDS" ARG TYPE="java.lang.String" VALUE="org.jboss.minerva.xa.XADataSourceImpl" /MLET MLET CODE="org.jboss.jdbc.XADataSourceLoader" ARCHIVE="jboss.jar,mssql.jar" CODEBASE="../../lib/ext/" ARG TYPE="java.lang.String" VALUE="nylimPool" ARG TYPE="java.lang.String" VALUE="org.jboss.minerva.xa.XADataSourceImpl" /MLET ... jboss.jcml has: mbean name="DefaultDomain:service=XADataSource,name=InstantDB" attribute name="Properties"/attribute attribute name="URL"jdbc:idb:../conf/default/instantdb.properties/attribute attribute name="GCMinIdleTime"120/attribute attribute name="JDBCUser" / attribute name="MaxSize"10/attribute attribute name="Password" / attribute name="GCEnabled"false/attribute attribute name="InvalidateOnError"false/attribute attribute name="TimestampUsed"false/attribute attribute name="Blocking"true/attribute attribute name="GCInterval"12/attribute attribute name="IdleTimeout"180/attribute attribute name="IdleTimeoutEnabled"false/attribute attribute name="LoggingEnabled"false/attribute attribute name="MaxIdleTimeoutPercent"1.0/attribute attribute name="MinSize"0/attribute /mbean mbean name="DefaultDomain:service=XADataSource,name=DefaultDS" attribute name="Properties"/attribute attribute name="URL"jdbc:HypersonicSQL:hsql://localhost:1476/attribute attribute name="GCMinIdleTime"120/attribute attribute name="JDBCUser"sa/attribute attribute name="MaxSize"10/attribute attribute name="Password" / attribute name="GCEnabled"false/attribute attribute name="InvalidateOnError"false/attribute attribute name="TimestampUsed"false/attribute attribute name="Blocking"true/attribute attribute name="GCInterval"12/attribute attribute name="IdleTimeout"180/attribute attribute name="IdleTimeoutEnabled"false/attribute attribute name="LoggingEnabled"false/attribute attribute name="MaxIdleTimeoutPercent"1.0/attribute attribute name="MinSize"0/attribute /mbean mbean name="DefaultDomain:service=XADataSource,name=nylimPool" attribute name="Properties"/attribute attribute name="URL"jdbc20:weblogic:mssqlserver4:nylim@localhost:1433/attribute attribute name="GCMinIdleTime"120/attribute attribute name="JDBCUser"sa/attribute attribute name="MaxSize"0/attribute attribute name="Password" / attribute name="GCEnabled"false/attribute attribute name="InvalidateOnError"false/attribute attribute name="TimestampUsed"false/attribute attribute name="Blocking"true/attribute attribute name="GCInterval"12/attribute attribute name="IdleTimeout"180/attribute attribute name="IdleTimeoutEnabled"false/attribute attribute name="LoggingEnabled"false/attribute attribute name="MaxIdleTimeoutPercent"1.0/attribute attribute name="MinSize"0/attribute /mbean web.xml has: web-app ... env-entry env-entry-namejava.naming.factory.initial/env-entry-name env-entry-valueorg.jnp.interfaces.NamingContextFactory/env-entry-value env-entry-typejava.lang.String/env-entry-type /env-entry env-entry env-entry-namejava.naming.provider.url/env-entry-name env-entry-valuelocalhost:1099/env-entry-value env-entry-typejava.lang.String/env-entry-type /env-entry env-entry env-entry-namejndi.db.poolname/env-entry-name env-entry-valuejava:/nylimPool/env-entry-value env-entry-typejava.lang.String/env-entry-type /env-entry ... /web-app The JBoss console output the following during startup, which looks good: ... [JDBC] Loaded JDBC-driver:org.hsql.jdbcDriver [JDBC] Loaded JDBC-driver:org.enhydra.instantdb.jdbc.idbDriver [JDBC] Loaded JDBC-driver:weblogic.jdbc20.mssqlserver4.Driver ... [InstantDB] Starting [InstantDB] XA Connection pool InstantDB bound to java:/InstantDB ... [nylimPool] XA Connection pool nylimPool bound to java:/nylimPool [nylimPool] Started [DefaultDS] Starting [DefaultDS] XA Connection pool DefaultDS bound to
