java.net.MalformedURLException when trying to access Initial

[ottoberg]

I am using JBoss 3.2.0RC1 and try to access its JndiContext from Eclipse via the JNDI Browser plugin. Each time I do so I get a java.net.MalformedURLException: no protocol: Berg/jboss-3.2.0RC1_tomcat-4.1.18/server/default/lib/javax.servlet.jar.
The complete path should read C:/Programme/Otto Berg/jboss-3.2.0RC1_tomcat-4.1.18/server/default/lib/javax.servlet.jar which obviously contains a space between Otto and Berg. So the problems seems to be caused by JBoss' inability to digest such a path. Is there any around this problem?

Any help would be appreciated.

Thanks
Olaf

[juhalindfors]

what JVM version are you using? The solution is not to use spaces in your path names -- that has always been a bad idea.

[ottoberg]

I am using the j2se 1.4.0 under Windows 2000. Well, next time I reinstall my box I will most certainly avoid any spaces but right now I cannot afford to do so.

Thanks,
Olaf

[juhalindfors]

Some of the space handling issues were due to bugs in JDK classes but I would have thought that they were fixed in 1.4 -- I remember testing it and it worked for me with 3.x release (installing under spaced dir).

The currrent JBoss code should use URLs for all file access so that class is responsible for escaping spaces. There might be some issues with the provided scripts though (such as run.bat).

[juhalindfors]

Hmm, I read your original post again and you said you're using a JNDI browser in Eclipse -- are you sure it is not eclipse that is not able to handle spaces?

[ottoberg]

I am not entirely sure that it's not Eclipse that is causing this trouble. In fact, I thought about it for a while and decided on installing the Orion server, choosing an install path that also contains spaces. Accessing said Orion server via the JNDI Browser from Eclipse works like a charm, so I am inclined to trace this problem to somewhere inside JBoss. Yet I am by no means an expert in these issues and might be mistaken. But the fact that the MalformedURLException is wrapped into a RemoteException seems to indicate that the problem originates somewhere in the JBoss code.