3 Replies Latest reply on Feb 25, 2010 11:34 AM by Brian Stansberry

    jndi.properties vs bindings-jboss-beans.xml

    jsingh jsingh Newbie

      Hi All,


      I am porting an application which uses RMI into JBoss 5.1.0.


      I have code in the application which uses the "org.jnp.interfaces.NamingContextFactory"  implementation of the Context for RMI connection.

      Since I am using a port different than :1099, I edit the "bindings-jboss-beans.xml" file's Naming Service port to my custom port, and the communication works fine.


      I was wondering if it's possible to *not* edit the bindings-jboss-beans.xml but edit the jndi.properties file as follows (assuming localhost as my url for now):

      java.naming.provider.url=jnp://localhost:<my port number>


      When I try this, JBoss throws the following exception (below).


      My questions were:
      1) Am I doing something wrong in the jndi.props file? Do I need to make it part of the class path?

      2) Does JBoss look at bindings-jboss-beans.xml before it looks at jndi.properties?


      I have made sure :<my port number>  is not in use.


      2010-02-24 17:18:23,228 WARN  [org.jnp.server.NamingBeanImpl] (main) Context.PROVIDER_URL in server jndi.properties, url=localhost:<my port number>


      2010-02-24 17:19:09,400 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (main) Error installing to Start: name=jboss.jmx:alias=jmx/rmi/RMIAdaptor state=Create mode=Manual requiredState=Installed
      javax.naming.CommunicationException: Could not obtain connection to any of these urls: localhost:<my port number> and discovery failed with error: javax.naming.CommunicationException: Receive timed out [Root exception is java.net.SocketTimeoutException: Receive timed out] [Root exception is javax.naming.CommunicationException: Failed to connect to server localhost/<my port number> [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server localhost/<my port number> [Root exception is java.net.ConnectException: Connection refused: connect]]]
      at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1763)
      at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:693)
      at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:686)
      at javax.naming.InitialContext.lookup(InitialContext.java:392)
      at org.jboss.util.naming.Util.createLinkRef(Util.java:275)
      at org.jboss.util.naming.Util.createLinkRef(Util.java:253)
      at org.jboss.naming.NamingAlias.createLinkRef(NamingAlias.java:133)
      at org.jboss.naming.NamingAlias.startService(NamingAlias.java:122)
      at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:376)
      at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:322)
      at sun.reflect.GeneratedMethodAccessor80.invoke(Unknown Source)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

        • 1. Re: jndi.properties vs bindings-jboss-beans.xml
          Brian Stansberry Master

          The conf/jndi.properties file is used by naming clients running inside the AS. It has no impact at all on what socket the Naming server listens on. The Naming server has no idea that file even exists.

          Don't include a java.naming.provider.url in conf/jndi.properties; you'll just break things or at best force any naming Context created inside the server to use an inefficient code path in doing naming operations.

          • 2. Re: jndi.properties vs bindings-jboss-beans.xml
            jsingh jsingh Newbie

            Thanks Brian. So it looks to me that changes in bindings-jboss-beans.xml is the way to go.


            What I was trying to achieve by editing jndi.properties was to avoid having to define a JBoss specific context/url in my code base, and keep the code base common (to work for any other App Server), and have JBoss pick the required context, url from the jndi.properties.

            • 3. Re: jndi.properties vs bindings-jboss-beans.xml
              Brian Stansberry Master
              You shouldn't need to provide any URL at all for a client running inside the AS to find the Naming server running inside the AS. The Context implementation class has a static reference to the in-VM naming server and uses that if no java.naming.provider.url is provided. That's why specifying a java.naming.provider.url breaks things or at best slows them down if what you're trying to do is access the local server.