5 Replies Latest reply on Aug 13, 2009 9:17 AM by jaikiran pai

    JNDI names with a leading /

    jaikiran pai Master

      I have a fix for https://jira.jboss.org/jira/browse/EJBTHREE-1884 in which, i now bind the remote ProxyFactory to the JNDI. A local testsuite run after this fix, has exposed a couple of other issues, one of which is in the testcases. The other one is related to clustered stateful beans loadbalancing which is have to investigate a bit more (to understand why it was expected to work the way its currently configured).

      The testsuite issue i am talking about is in the org.jboss.ejb3.test.jms.managed.unit.ManagedTestCase which deploys a JMSTestBean with a remote jndi binding for the session bean:


      Notice the leading / in the JNDI name. This results in our proxy-impl generating the jndi name for the default business interface as:

      /jms-test-ejbs/JMSTest - EJB3.x Default Remote Business Interface

      And the remote proxyfactory being bound in JNDI and registered in MC with the following key:


      Notice the double // in the name. This binds fine in JNDI:

      +- ProxyFactory (class: org.jnp.interfaces.NamingContext)
       +- jms-managed (class: org.jnp.interfaces.NamingContext)
       | | +- JMSTest (class: org.jnp.interfaces.NamingContext)
       | | | +- jms-test-ejbs (class: org.jnp.interfaces.NamingContext)
       | | | | +- JMSTest (proxy: $Proxy257 implements interface

      But when the ProxyFactory is looked up in the JNDI, it fails with NameNotFoundException:

      10:10:31,701 ERROR [STDERR] javax.naming.NameNotFoundException: not bound
      10:10:31,701 ERROR [STDERR] at org.jnp.server.NamingServer.getBinding(NamingServer.java:771)
      10:10:31,701 ERROR [STDERR] at org.jnp.server.NamingServer.getBinding(NamingServer.java:779)

      While doing the lookup, it internally splits the names on the / and obviously runs into this exception because of the double //.

      IMO, we should fix this by our jndi binding logic (JNDISessionRegistrarBase) to strip any leading /. But what do others think? Possible options are:

      1) Change the testcase to not use the leading / in the jndi-name. (Not an ideal fix, since end users too might end up with this exception if they do something similar).

      2) Fix our jndi binding code. I think this is the ideal solution

      3) Change the name lookup code (in jboss-naming) to parse this differently. I guess, this should not even be an option, since its not the responsibility of that piece of code to do the cleaning :)