2 Replies Latest reply on May 14, 2002 10:51 AM by Kevin Klein

    JBoss-Jetty, naming, and exceptions

    Kevin Klein Newbie

      I'm running the integrated JBoss2.4.4-Jetty and I have a servlet that is talking to a Session bean.

      Inside the servlet, I'm using the standard JNDI client-side procedure to look up a reference to the session bean.

      When my session bean throws a NullPointerException, I receive a java.rmi.ServerException. The "detail" attribute of this exception has my original NullPointerException, but if I do a printStackTrace() on this I get "no stack trace available".

      Two questions:
      1. If my servlet is calling a bean in the same VM, why am I getting RMI exceptions?

      2. Is there a way for me to get the full stack trace of the original NullPointerException? Will this problem be solved if I answer question #1?

        • 1. Re: JBoss-Jetty, naming, and exceptions
          Kevin Klein Newbie

          Looks like I need some kind of EJB reference. I added the following to my web.xml file:

          <ejb-ref>
          <ejb-ref-name>ejb/Environment</ejb-ref-name>
          <ejb-ref-type>Session</ejb-ref-type>
          myapp.IEnvironmentHome
          myapp.IEnvironnmentRemote
          </ejb-ref>

          And then I created a jboss-web.xml file with the following:

          <jboss-web>
          <ejb-ref>
          <ejb-ref-name>ejb/Environment</ejb-ref-name>
          <jndi-name>Environment</jndi-name>
          </ejb-ref>
          </jboss-web>

          However, attempting a JNDI lookup in the servlet on "java:comp/env/ejb/Environment" gives me the following exception:

          javax.naming.NameNotFoundException: env not bound

          Any ideas?

          • 2. Re: JBoss-Jetty, naming, and exceptions
            Kevin Klein Newbie

            Switching to JBoss-Tomcat solved my JNDI problems.

            As for the "<< no stack trace available >>", this was a misdiagnosis on my part. The problem seems to be related to the JVM itself and not RMI. Upgrading to the 1.4 JVM produced a correct stack trace.