InitialContext finds localhost on bound jboss [SOLVED]

[Ole Hornischer]

Hi!
I am using a JBoss server that is bound to my network IP adress (run.bat -b 11.22.33.44)

Now my application (ear file in the deploy folder, deploys fine, everything else works good) wants to look up a Topic to broadcast some messages to possible clients. However, when i create the InitialContext it is referring to localhost:1099 and not to 11.22.33.44:1099

Do I need to provied a jndi.properties file in my ear file, or can a server app not broadcast to topics at all? How do I make the app to find the topic?

The Topic is properly set up in the according project-service.xml and is listed in the JNDIViewer.

Any ideas?

Cheers Thelonius
[ November 19, 2008: Message edited by: Ole Hornischer ]

[Jaikiran Pai]

By default, the server uses localhost for lookup. Provide a jndi.properties file in your EAR, with the IP address for the PROVIDER_URL.

[Ole Hornischer]

Hi!
Thanks for your fast reply. I thought i did try that, but it turned out, i accidentally deployed the jndi.properties to my jar. Now I changed it so that the file goes to the .ear file directly, but no change. My application seems to ignore the file.
--Thelonius

[Ole Hornischer]

Hi!
After a bit more research, I stumbled over the jndi.properties file in the JBoss conf-folder. It seems to override the file in my ear, since after I added the Provider URL to it my topic posting works.

In the jndi.properties in the conf-folder it says I should not alter the file unless I know what I am doing. What consequences can arise if i add the provider URL in it?

Or did it not override my own jndi.properties in the ear, but the server simply did not find the one in the .ear?

--Thelonius
[ November 17, 2008: Message edited by: Ole Hornischer ]

[Jaikiran Pai]

Originally posted by Ole Hornischer:

After a bit more research, I stumbled over the jndi.properties file in the JBoss conf-folder. It seems to override the file in my ear, since after I added the Provider URL to it my topic posting works.

In the jndi.properties in the conf-folder it says I should not alter the file unless I know what I am doing. What consequences can arise if i add the provider URL in it?

If you look at that the file in the conf folder, you will see that the PROVIDER_URL is not specified there. So editing that file is a bad idea

Originally posted by Ole Hornischer:
Or did it not override my own jndi.properties in the ear, but the server simply did not find the one in the .ear?

Looks like the server did not find the one in the .ear. Where exactly in the EAR did you place this file? Which version ofJBoss server do you use?

[Ole Hornischer]

Hi Jaikiran!
I use the JBoss 4.2.3 and I put the file in the "root" level of the ear file.
My final ear looks somewhat like this:

|..
|- project.jar
|- shared_project.jar
|- jndi.properties

[Jaikiran Pai]

From what i know, placing the jndi.properties at the root of the EAR should have worked. Can you post the contents of this file and also the console logs along with the exception that you see.

[Ole Hornischer]

jndi.properties:

 
java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
java.naming.factory.url.pkgs=org.jboss.naming.jnp.interfaces
java.naming.provider.url= 11.22.33.44:1099   

Exception (from server.log):

008-11-17 12:18:35,435 DEBUG [org.jnp.interfaces.NamingContext] Failed to connect to localhost:1099
javax.naming.CommunicationException: Failed to connect to server localhost:1099 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server localhost:1099 [Root exception is java.net.ConnectException: Connection refused: connect]]
at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:274)
at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1533)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:634)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:627)
at javax.naming.InitialContext.lookup(Unknown Source)
at com.tza.connectivity.client.Broadcaster.<init>(Unknown Source)
at com.tza.connectivity.client.Broadcaster.broadcastUpdate(Unknown Source)
at com.tza.server.ServerMain.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: javax.naming.ServiceUnavailableException: Failed to connect to server localhost:1099 [Root exception is java.net.ConnectException: Connection refused: connect]
at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:248)
... 8 more
Caused by: java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(Unknown Source)
at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.SocksSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at java.net.Socket.<init>(Unknown Source)
at java.net.Socket.<init>(Unknown Source)
at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:84)
at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:77)
at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:244)
... 8 more
2008-11-17 12:18:40,435 ERROR [STDERR] javax.naming.CommunicationException: Could not obtain connection to any of these urls: localhost:1099 
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:1099 
[Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server localhost:1099 [Root exception is java.net.ConnectException: Connection refused: connect]]]
2008-11-17 12:18:40,435 ERROR [STDERR] at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1562)
2008-11-17 12:18:40,435 ERROR [STDERR] at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:634)
2008-11-17 12:18:40,435 ERROR [STDERR] at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:627)
2008-11-17 12:18:40,435 ERROR [STDERR] at javax.naming.InitialContext.lookup(Unknown Source)
2008-11-17 12:18:40,435 ERROR [STDERR] at com.tza.connectivity.client.Broadcaster.<init>(Unknown Source)
2008-11-17 12:18:40,435 ERROR [STDERR] at com.tza.connectivity.client.Broadcaster.broadcastUpdate(Unknown Source)
2008-11-17 12:18:40,435 ERROR [STDERR] at com.tza.server.ServerMain.run(Unknown Source)
2008-11-17 12:18:40,435 ERROR [STDERR] at java.lang.Thread.run(Unknown Source)
2008-11-17 12:18:40,435 ERROR [STDERR] Caused by: javax.naming.CommunicationException: Failed to connect to server localhost:1099 
[Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server localhost:1099 
[Root exception is java.net.ConnectException: Connection refused: connect]]
2008-11-17 12:18:40,435 ERROR [STDERR] at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:274)
2008-11-17 12:18:40,435 ERROR [STDERR] at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1533)
2008-11-17 12:18:40,435 ERROR [STDERR] ... 7 more
2008-11-17 12:18:40,435 ERROR [STDERR] Caused by: javax.naming.ServiceUnavailableException: Failed to connect to server localhost:1099 [Root exception is java.net.ConnectException: Connection refused: connect]
2008-11-17 12:18:40,435 ERROR [STDERR] at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:248)
2008-11-17 12:18:40,435 ERROR [STDERR] ... 8 more
2008-11-17 12:18:40,435 ERROR [STDERR] Caused by: java.net.ConnectException: Connection refused: connect
2008-11-17 12:18:40,435 ERROR [STDERR] at java.net.PlainSocketImpl.socketConnect(Native Method)
2008-11-17 12:18:40,435 ERROR [STDERR] at java.net.PlainSocketImpl.doConnect(Unknown Source)
2008-11-17 12:18:40,435 ERROR [STDERR] at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
2008-11-17 12:18:40,435 ERROR [STDERR] at java.net.PlainSocketImpl.connect(Unknown Source)
2008-11-17 12:18:40,435 ERROR [STDERR] at java.net.SocksSocketImpl.connect(Unknown Source)
2008-11-17 12:18:40,435 ERROR [STDERR] at java.net.Socket.connect(Unknown Source)
2008-11-17 12:18:40,435 ERROR [STDERR] at java.net.Socket.connect(Unknown Source)
2008-11-17 12:18:40,435 ERROR [STDERR] at java.net.Socket.<init>(Unknown Source)
2008-11-17 12:18:40,435 ERROR [STDERR] at java.net.Socket.<init>(Unknown Source)
2008-11-17 12:18:40,435 ERROR [STDERR] at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:84)
2008-11-17 12:18:40,435 ERROR [STDERR] at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:77)
2008-11-17 12:18:40,435 ERROR [STDERR] at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:244)
2008-11-17 12:18:40,435 ERROR [STDERR] ... 8 more
2008-11-17 12:18:40,435 ERROR [STDERR] Exception in thread "Thread-10" 
2008-11-17 12:18:40,435 ERROR [STDERR] java.lang.NullPointerException
2008-11-17 12:18:40,435 ERROR [STDERR] at com.tza.connectivity.client.Broadcaster.<init>(Unknown Source)
2008-11-17 12:18:40,435 ERROR [STDERR] at com.tza.connectivity.client.Broadcaster.broadcastUpdate(Unknown Source)
2008-11-17 12:18:40,435 ERROR [STDERR] at com.tza.server.ServerMain.run(Unknown Source)
2008-11-17 12:18:40,435 ERROR [STDERR] at java.lang.Thread.run(Unknown Source)

[Edited by Jaikiran for better formatting]
[ November 19, 2008: Message edited by: Jaikiran Pai ]

[Ole Hornischer]

No more ideas what could be wrong?

[Andrea Gazzarini]

java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
java.naming.factory.url.pkgs=org.jboss.naming.jnp.interfaces
java.naming.provider.url= 11.22.33.44:1099

Hi, one problem I'm seeing is that you forgot the protocol on the provider url. I don't know if it's working also without that. So, according to JBoss Wiki :

    
You'll need a jndi.properties on the remote client which looks like this:
 
#jboss JNDI properties
java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
java.naming.provider.url=jnp\://localhost\:1099
java.naming.factory.url.pkgs=org.jnp.interfaces

Anyway, I'm not understanding why don't you edit the conf/jndi.properties under the jboss installation? It's more flexible of inserting that directly inside the ear...

Regards,

Regards,

[Jaikiran Pai]

Originally posted by a.gazzarini:
Anyway, I'm not understanding why don't you edit the conf/jndi.properties under the jboss installation? It's more flexible of inserting that directly inside the ear...

Andrea,

Though changing the conf/jndi.properties in the jboss installation is going to work, its not the correct place to do this

Originally posted by Ole Hornischer:
No more ideas what could be wrong?

Ole, i could not give this a try on my local setup. Let me spend some time today on this and see how it behaves.

[Jaikiran Pai]

Ole,

Where are you doing this lookup from? Is it a standalone client or from some servlet/jsp on the same server?

[Andrea Gazzarini]

Though changing the conf/jndi.properties in the jboss installation is going to work, its not the correct place to do this

I'm not agree...why is it the wrong place? If the naming service is located on 11.22.33.44:1099 JBoss is supposed to run with that naming service and therefore it doesn't make sense to have an implicit "default" value of localhost:1099.

Putting the file on the ear has moreless the same meaning of hard-coding that. If you want to change the address(run for example this application on another machine) you must rebuild the archive.
Simply I think that the information related to the external environment shoudln't be inside your archive (if it is a file or you hard-coded that there's a little difference IMO)

[Jaikiran Pai]

Originally posted by Andrea Gazzarini:

If the naming service is located on 11.22.33.44:1099 JBoss is supposed to run with that naming service and therefore it doesn't make sense to have an implicit "default" value of localhost:1099.

That's correct. And that's what i am trying to figure out as to why its falling back to the (default) localhost instead of using the IP provided by the -b option. In my opinion, you need not change the conf/jndi.properties nor provide a jndi.properties in your application EAR.

[Jaikiran Pai]

I just tried this on my local setup of 4.2.3 GA. I started the server with -b <IP Address> and then did not change any jndi.properties file nor did i include any jndi.properties in my application deployed on JBoss. Then from a servlet within the application deployed on the same server, i did a simple JNDI lookup

Context ctx = new InitialContext();
ctx.lookup("queue/A");

Worked without any issues.

[Jaikiran Pai]

2008-11-17 12:18:40,435 ERROR [STDERR] at com.tza.server.ServerMain.run(Unknown Source)
2008-11-17 12:18:40,435 ERROR [STDERR] at java.lang.Thread.run(Unknown Source)

How is this thread started/created and by whom?

[Ole Hornischer]

Thank you for all your answers.
Interestingly now I solved the problem.

I just tried this on my local setup of 4.2.3 GA. I started the server with -b <IP Address> and then did not change any jndi.properties file nor did i include any jndi.properties in my application deployed on JBoss. Then from a servlet within the application deployed on the same server, i did a simple JNDI lookup

After this hint I redeployed my ear making sure there is no jndi.properties anywhere in the file and took out the provider url entry in the properties file in the JBoss conf directory. And it does work. I suppose I used to have a runaway jndi.properties somewhere in my ear which i was not aware of and it screwed up the settings. Now after updating my ant deploy script I get a proper ear file.

As for the other questions asked (maybe for future references):

Where are you doing this lookup from? Is it a standalone client or from some servlet/jsp on the same server?

The application runs from an ear file in the server. This application looks up the topics. The stand alone client that is listening to the topics does fnd the topic without an issue, since it has an jndi.properties file in its class path.

Putting the file on the ear has moreless the same meaning of hard-coding that. If you want to change the address(run for example this application on another machine) you must rebuild the archive.
Simply I think that the information related to the external environment shoudln't be inside your archive (if it is a file or you hard-coded that there's a little difference IMO)

I agree on this, "hard coding" the IP would be bad practice. But like this (providing no IP at all in any jndi.properties) we are independent again, so this issue is solved too.

quote:2008-11-17 12:18:40,435 ERROR [STDERR] at com.tza.server.ServerMain.run(Unknown Source)
2008-11-17 12:18:40,435 ERROR [STDERR] at java.lang.Thread.run(Unknown Source)



How is this thread started/created and by whom?

The Thread is being started by a remote service call and runs on the server, broadcasting data updates to all clients.
Concerning this another question has been on my mind for a while now: Is it possible to start a "main" class or call a method in the server app after booting the JBoss? I have a few backgroubd processes I need to have running continously as soon as the server started. Right now I still need to trigger the start of these processes via EJB service from a client. But I'd rather have them started after JBoss boot, if possible.

[Jaikiran Pai]

Originally posted by Ole Hornischer:
Concerning this another question has been on my mind for a while now: Is it possible to start a "main" class or call a method in the server app after booting the JBoss? I have a few backgroubd processes I need to have running continously as soon as the server started. Right now I still need to trigger the start of these processes via EJB service from a client. But I'd rather have them started after JBoss boot, if possible.

How about @Service which will be called at the start of your application deployment?

[Ole Hornischer]

Thank you Jaikiran for pointing me in that direction. But I cannot quite figure out how to define the Bean in order to have my background process started on deployment.

If I simply add the @Service annotation to a bean calling my background processes nothing happens until I call that bean from a client. I also declared the bean to be @Management and added the lifecycle methods, but still nothing.

[Ole Hornischer]

I figured it out. I had the Annotation on the wrong class. Now the bean is started at deployment and my processes are triggered.
Thanks a lot!

[Jaikiran Pai]

Originally posted by Ole Hornischer:
Now the bean is started at deployment and my processes are triggered.

Cool!