4 Replies Latest reply on Aug 13, 2003 12:11 AM by detla

    Bean not bound in Tomcat 4.1. / JBoss 2.4 combination

    detla

      Hallo everyone,
      when I tried to redeploy an old piece of code (I was assured it once ran flawlessly), I got a NameNotBoundException with the above mentioned combination of JBoss 2.4 and Tomcat 4.1.

      I tried to write a small Javaapplication to access the Bean directly - it worked. So, is there a general problem with those two servers or was I too stupid to set up Tomcat correctly?

      Some code for those interested:
      This one works fine (java-app)

      Properties props = new Properties();
      props.setProperty("java.naming.factory.initial",
      "org.jnp.interfaces.NamingContextFactory");
      props.setProperty("java.naming.provider.url",
      "localhost:1099");
      props.setProperty("java.naming.factory.url.pkgs",
      "org.jboss.naming");
      Context ctx = new InitialContext(props);
      Object o = ctx.lookup("LogInEJB");
      (+exceptionhandling)





      This one doesn't (jsp called java class):

      ctx = new InitialContext(System.getProperties());
      ...
      LogInEJBHome loginHome =(LogInEJBServerHome)
      lookup("LogInEJB");

      where lookup is defined as:
      Object oLookup = ctx.lookup(sName);
      return oLookup
      (+ exceptionhandling)

      where tomcat uses
      java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
      java.naming.provider.url=127.0.0.1:1099
      java.naming.factory.url.pkgs=org.jboss.naming

      ind jndi.properties.

      Interesting enough, the Exception is thrown with contextfactory
      org.apache.naming.java.javaurlcontextfactory.

      Anyone any idea?
      Thank You,
      js

        • 1. Re: Bean not bound in Tomcat 4.1. / JBoss 2.4 combination
          jonlee

          Did you put the following in the Tomcat 4.1.x shared/lib directory:
          jboss-client.jar
          jboss-j2ee.jar
          jbosssx-client.jar
          jnp-client.jar

          We've always done this and it works. Some people have reported that placing these jars (or the jbossall-client.jar in later JBoss distributions) in any other place does not work - such as in the WAR.

          Normally your JNDI properties should be:
          java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
          java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces
          java.naming.provider.url=jnp://localhost:1099

          I haven't tried Tomcat with a jndi.properties configuration for JBoss. Normally, we would explicitly define properties in the InitialContext and that does work.

          • 2. Re: Bean not bound in Tomcat 4.1. / JBoss 2.4 combination
            detla

            I managed to get around the problem by not using System.getProperties but defining the properties manually, the question remaining is, are those namingfactories incompatible or did I something wrong configuring Tomcat/Jboss?
            js

            • 3. Re: Bean not bound in Tomcat 4.1. / JBoss 2.4 combination
              jonlee

              Obviously nothing wrong in JBoss since you haven't changed anything on the JBoss system.

              The jndi.properties could be a problem. Certainly the definitions aren't completely standard but you'd need to experiment with it to see the effect. It works in your other example so probabilities would say that this isn't exactly the problem either.

              Possibly Tomcat isn't picking up your JNDI properties. You would need to have picked up and printed the values the System was using to determine if this was the cause. By way of your anecdotal evidence, this is the most likely issue.

              • 4. Re: Bean not bound in Tomcat 4.1. / JBoss 2.4 combination
                detla

                Interesting enough, changing the URI from 127.0.0.1:1099 to localhost:1099 actually is noted by Tomcat, so it reads the jndi properties but seems to ignore the namingfactory settings.
                Anyway, I got working code and am therefore curious but satisfied. Thanks for Your help,
                js