according to the JDK docs, yes:
Extract from http://java.sun.com/j2se/1.4.2/docs/api/java/io/File.html
For Microsoft Windows platforms, the prefix of a pathname that contains a drive specifier consists of the drive letter followed by ":" and possibly followed by "\" if the pathname is absolute. The prefix of a UNC pathname is "\\"; the hostname and the share name are the first two names in the name sequence. A relative pathname that does not specify a drive has no prefix.
Maybe I didn't formulate the question correctly. I know that Java can handle UNC paths corrrectly. What I was looking for is the syntax to use in the URLDeploymentScanner's "URLs" attribute in the jboss-service.xml file. I've tried the following:
None of the above seem to work. I'm thinking that I need to use a variant of the file: syntax, but I'm not sure what will work.
Thanks for the help in advance.
should doit according to
Maybe a bug in around makeURL ?
But you may enable debugging - see docs - and should see:
"Adding URL from spec:"
use the source, luke
But anyway: As fas as I can see, the deployment URL should be relative to the server home.
I did go to Google.
I did look at the source.
All before I posted.
What I found after trial and error was that the following does work
Seems odd to me that it would be like this, but I suspect that JBoss is passing anything after file:// directly to the File class to find the correct location. Maybe this is a feature, maybe this is a bug, I can't tell.
But I did find a solution.
The one other caveat about using UNC paths, in case anyone else runs into this problem, is that the user that jboss runs as (either specified via a service descriptor in Windows or as run from a command line) must be resolvable to the server whose UNC path is being used. In other words if you are running JBoss on a server using a local user then, no matter how the share's permissions are set up, jboss will not be able to see the UNC path. Both servers must have access to the same user information provided by a common domain controller.
Thanks for the help.
There should a replacement of the System.PathSeperator taken place in the during URL parsing ...