Should distro jndi.properties work w/non-clustering ?

[ftg314159]

I'm upgrading to 3.2.3 from 3.2.1, and I'm seeing a change in behavior using a single non-clustering server whose clients are on the same machine.

Previously, my clients would successfully create an InitialContext by referencing server/default/conf/jndi.properties, and that worked in 3.2.1.

In 3.2.3, I get a timeout trying to look anything up.

I finally fixed this by adding:
jnp.disableDiscovery=true
java.naming.provider.url=jnp://localhost:1099

In running the client code under a debugger, the general problem seemed to be that org.jnp.interfaces.NamingContext didn't find anything it liked for a local server, and decided to use the discovery code.

My question is: should this have happened ? Should I have to modify jndi.properties in this way for this configuration, or do I have something outside of JBoss misconfigured that prevented it from working out-of-the-box ?

I'm a little concerned because the 3.2.1 jndi.properties had a comment saying not to use a provider.url of localhost since it forced in-VM calls to go through RMI.

Thanks for any assistance.

[darranl]

You should never have edited the file in the first place.

That file is for the server not the clients.

It has never been for the clients and it has allways (At least since 3.0.6) had a message in it saying not to change it.

The message was changed because way too many people were ignoring the comment and editing it anyway.

The server should be left with the file it was distributed with.

The client should be given their own file on their own classpath.

[ftg314159]

Thanks for the reply. That, of course, makes sense.

However, I think it would be a lot more intuitive if a sample client jndi.properties were distributed in the client subdirectory. With the server one being the only one there, it's kind of natural to assume that everyone's supposed to use it.