spaces in client install path

[kcochrane]

Hello everyone,

We are currently adopting JBoss in our organisation and have encountered an issue.

Some of our applications are swing clients, which we hope to configure to use an instance of the business interface (the business interface is exposed as an ejb running in Jboss). The client therefore does a JNDI lookup to obtain an instance of the remote object to work with. The client application is distributed over many jar files and the URL class loader object is used at application start up to allow access to the classes from the jar files in the install directory (including those contained in jbossall-client.jar). The client is able to obtain a valid remote object if it is installed in a directory with no white space characters in it but when the install location contains white space characters it fails, complaining with a java.net.MalformedURLException: no protocol.

I have traced through the code for a bit and can see the point where the org.jnp.interfaces.NamingContext is attempting the lookup of the remote object, however I do not understand where the client install location URL is required in this. It seems to me (obviously missing something) that the only name that should be looked up is the name bound to JNDI for the ejb.

I appreciate this problem may be due to the fact we are using the URL class loader and would like to better understand the link between this and what the org.jnp objects are doing. Has anyone else encountered this problem, or perhaps someone could even just take the time to aid my understanding of where in the JNDI implementation code the local client code URL comes in to the equation.

[kcochrane]

I have figured out what is happening, thought I would add it here just in case anyone else encounters the problem.

When we build our URL class loader on the client, the URL for the local files is simply a string built in the code (eg file://documents and settings...) from the known install location of the client. The sun code in the JVM requires this to be a correctly formatted URL (ie %20 in it) which it would obviously not be in our case. The problem is actually coming from the sun code, not the JBoss naming code. Instead of building the string ourselves, we now get the URL from a file object which will be correctly formed as required by the sun code.

(In my experience it`s usually something daft like this!)