JNDI not working on JBoss 4 as expected

261 views Asked by At

I need to deploy an .ear to a legacy JBoss application which has a stateless session bean called GateKepper. I am testing this on a local copy of that application, which I am hoping is nearly identical to the production version. I perform a lookup with:

   protected  GateKeeper lookupGateKeeper() {
        String gateKeeperBeanName = null;
        try {
            Properties p = getClasspathProperties();
            InitialContext ctx = new InitialContext(p);
            gateKeeperBeanName = p.getProperty("gatekeeper.name");
            return (GateKeeper) ctx.lookup( gateKeeperBeanName );
        }
        catch (IOException e) {
            throw new GateKeeperLookupException("Gatekeeper [" + gateKeeperBeanName + "] not found.", e);
        } catch (NamingException e) {
            throw new GateKeeperLookupException("Gatekeeper [" + gateKeeperBeanName + "] not found.", e);
        }
    }

where the gatekeeperBeanName is "com.xxxxx.mercury.GateKeeper", which is the fully qualified class name of the remote and local interface, which I present below, and where the properties I insert are the standard from java.naming being:

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

The annotations on the GateKeeper interface (com.xxxxx.mercury.GateKeeper) are

@Remote
@Local
public interface GateKeeper {
    public String processRequest(String request);
}

and during startup of the applicaiton, the following is logged:

2014-12-08 15:30:53,648 DEBUG [org.jboss.naming.NamingService] (main) !Starting jboss:service=Naming
2014-12-08 15:30:53,648 DEBUG [org.jboss.naming.NamingService] (main) !System.setProperty, key=java.naming.factory.initial, value=org.jnp.interfaces.NamingContextFactory
2014-12-08 15:30:53,648 DEBUG [org.jboss.naming.NamingService] (main) !System.setProperty, key=java.naming.factory.url.pkgs, value=org.jboss.naming:org.jnp.interfaces
2014-12-08 15:30:53,655 DEBUG [org.jboss.naming.NamingService] (main) !Creating NamingServer stub, theServer=org.jnp.server.NamingServer@5f7f84e5,rmiPort=1098,clientSocketFactory=null,serverSocketFactory=org.jboss.net.sockets.DefaultSocketFactory@ad093076
2014-12-08 15:30:53,711 DEBUG [org.jboss.naming.NamingService] (main) !NamingServer stub: NamingServer_Stub[UnicastRef2 [liveRef: [endpoint:[192.168.1.109:1098,org.jboss.net.sockets.DefaultSocketFactory@ad093076](local),objID:[36e9dd2d:14a282a12d7:-7fff, 5578168918392374819]]]]
2014-12-08 15:30:53,716 DEBUG [org.jboss.naming.NamingService] (main) !Started jndi bootstrap jnpPort=1099, rmiPort=1098, backlog=50, bindAddress=/0.0.0.0, Client SocketFactory=null, Server SocketFactory=org.jboss.net.sockets.DefaultSocketFactory@ad093076
2014-12-08 15:30:53,720 DEBUG [org.jboss.naming.NamingService] (main) !InitialContext Environment:
2014-12-08 15:30:53,720 DEBUG [org.jboss.naming.NamingService] (main) !key=java.naming.factory.initial, value=org.jnp.interfaces.NamingContextFactory
2014-12-08 15:30:53,720 DEBUG [org.jboss.naming.NamingService] (main) !key=java.naming.factory.url.pkgs, value=org.jboss.naming:org.jnp.interfaces:org.jboss.naming:org.jnp.interfaces
2014-12-08 15:30:53,722 DEBUG [org.jboss.naming.NamingService] (main) !Listening on port 1099
2014-12-08 15:30:53,724 DEBUG [org.jboss.naming.NamingService] (main) !Started jboss:service=Naming

So it really looks like the naming service is started up so why is it when I try to lookup the GateKeeper

I get:

com.xxxxxcorp.vas.txws.web.GateKeeperLookupException: Gatekeeper [com.xxxxx.mercury.GateKeeper] not found.

com.xxxxxcorp.vas.txws.web.TxnServlet.lookupGateKeeper(TxnServlet.java:134)
com.xxxxxcorp.vas.txws.web.TxnServlet.getGateKeeper(TxnServlet.java:119)
com.xxxxxcorp.vas.txws.web.TxnServlet.get(TxnServlet.java:66)
com.xxxxxcorp.vas.txws.web.TxnServlet.doGet(TxnServlet.java:58)
javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:75)

Clearly, either the IOException or the NamingException happened. Has anyone had trouble getting naming resolution up and running, can anyone spot what I'm doing wrong?

EDIT In case this is in any way important jboss-service.xml has this to say about the NamingService:

   <mbean code="org.jboss.naming.NamingService"
      name="jboss:service=Naming"
      xmbean-dd="resource:xmdesc/NamingService-xmbean.xml">
      <!-- The call by value mode. true if all lookups are unmarshalled using
      the caller's TCL, false if in VM lookups return the value by reference.
      -->
      <attribute name="CallByValue">false</attribute>
      <!-- The listening port for the bootstrap JNP service. Set this to -1
        to run the NamingService without the JNP invoker listening port.
      -->
      <attribute name="Port">1099</attribute>
      <!-- The bootstrap JNP server bind address. This also sets the default
      RMI service bind address. Empty == all addresses
       -->
      <attribute name="BindAddress">${jboss.bind.address}</attribute>
      <!-- The port of the RMI naming service, 0 == anonymous -->
      <attribute name="RmiPort">1098</attribute>
      <!-- The RMI service bind address. Empty == all addresses
       -->
      <attribute name="RmiBindAddress">${jboss.bind.address}</attribute>
      <!-- The thread pool service used to control the bootstrap lookups -->
      <depends optional-attribute-name="LookupPool"
         proxy-type="attribute">jboss.system:service=ThreadPool</depends>
   </mbean>

   <mbean code="org.jboss.naming.JNDIView"
        name="jboss:service=JNDIView"
        xmbean-dd="resource:xmdesc/JNDIView-xmbean.xml">
   </mbean>
1

There are 1 answers

0
mendieta On

I don't think using the fully qualified interface name works as a jndi string.. In your case, it should be something like earName/GateKeeperImpl/local or GateKeeperImpl/local

Also, I wouldn't annotate the same interface with @Local and @Remote, I believe it can cause trouble

hope it helps!