More on the error:
It seems like the problem is with getting the initialContext . I use MBeans, which make db calls at start up - this is where it's throwing the Communication Exception. I have added an entry in hosts.allow for the IP being used, was wondering if a java.policy would be required during Jboss startup.
Could you provide the stack trace for the error, including the actual error message so that we can see what is actually being reported. (It is easier to see the error reported by JBoss rather than a description of someones interpretation of the error).
Also what happens if you start JBoss without your application being deployed? Are there any errors?
Which version of JBoss are you using and which JDK version?
Either way , with or without deploying my application jboss starts up fine when I run it on localhost... the problem occurs when I bind Jboss to a static IP (192.168.0.3) .
The JCA conf for mySQL doesn't give a problem but the MBeans, which use an initialcontext, fails. I am using jdk1.4.2_05 under RH9 and mySQL mysql-standard-4.0.20-pc-linux-i686
The stacktrace is : (can't copy all of it, just putting the problem area)
11:17:48,424 INFO [STDOUT] KPI MBean Started
11:17:48,425 INFO [STDOUT] Rules MBean Started
11:17:48,475 INFO [STDOUT] Actions MBean Started
11:17:48,478 INFO [STDOUT] ###################### MBean Servers >>>1
11:17:48,581 INFO [STDOUT] ###################### MBean Domain >>>jboss
11:17:48,586 INFO [STDOUT] Added the Listeners to NotificationHandler
11:17:55,750 INFO [STDOUT] ...........................Startup Started ...........................
11:17:55,755 INFO [STDOUT] KPIDefinition Updater >>>>>
11:17:55,861 INFO [STDOUT] Initial Context.................Till Here
11:17:55,862 INFO [STDOUT] providerURL jnp://192.168.0.3:1099
11:17:56,165 INFO [STDOUT] javax.naming.CommunicationException [Root exception
is java.rmi.ConnectException: Connection refused to host: 127.0.0.1; nested exception is:
java.net.ConnectException: Connection refused]
11:17:56,167 INFO [STDOUT] at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:649)
11:17:56,262 INFO [STDOUT] at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:509)
11:17:56,262 INFO [STDOUT] at javax.naming.InitialContext.lookup(InitialContext.java:347)
11:17:56,262 INFO [STDOUT] at com.gourangi.mbeans.UpdateKPIDefinitions.update(UpdateKPIDefinitions.java:27)
11:17:56,263 INFO [STDOUT] at com.gourangi.mbeans.AppStartup.start(AppStartup.java:30)
11:17:56,263 INFO [STDOUT] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
11:17:56,305 INFO [STDOUT] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
11:17:56,306 INFO [STDOUT] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
I am using JBoss 3.2.5 ...
Which constructor are you using when obtaining an initial context?
If you are running code inside MBeans within the JBoss JVM you shouldn't need to pass in any parameters which will stop the calls going over the network.
Thanks a lot for your input... Indeed it was a problem with getting the InitialContext. We have a utility class which provides the initialContext (reads env props) for clients, the Mbean was using one of the static methods of this class which client apps use for remote lookups.
FYI: One more observation :
Another reason why one could get a connection refused to host 127.0.0.1 :
Problem: In /etc/hosts if the binding IP is not there: so when there is a remote call, the server grabs the first entry which is usually the loopback, 127.0.0.1
Resolution: put an entry in the /etc/hosts file as follows:
-don't forget to bounce the box, then from a remote machine telnet <whatever IP that you are using> 1099 : if you get get the ip that you set at the end of the output then you are home free!!