Closed TurekBot closed 5 years ago
Some testing is proving insightful:
URI uri = URI.create("file:////atlas/Sundance_Apps/MyApp/");
results in a URI
that looks like this on the inside
uri = {URI@2693} "file:////atlas/Sundance_Apps/MyApp/"
scheme = "file"
fragment = null
authority = null
userInfo = null
host = null
port = -1
path = "//atlas/Sundance_Apps/MyApp/"
query = null
schemeSpecificPart = "////atlas/Sundance_Apps/MyApp/"
hash = 0
decodedUserInfo = null
decodedAuthority = null
decodedPath = null
decodedQuery = null
decodedFragment = null
decodedSchemeSpecificPart = null
string = "file:////atlas/Sundance_Apps/MyApp/"
But when you try to use uri.resolve(String)
—like is done in various parts of FXLauncher—it breaks UNC paths.
URI resolvedURI = uri.resolve("app.xml");
results in a broken UNC URI
resolvedURI = {URI@2714} "file:/atlas/Sundance_Apps/MyApp/app.xml"
scheme = "file"
fragment = null
authority = null
userInfo = null
host = null
port = -1
path = "/atlas/Sundance_Apps/MyApp/app.xml"
query = null
schemeSpecificPart = null
hash = 0
decodedUserInfo = null
decodedAuthority = null
decodedPath = null
decodedQuery = null
decodedFragment = null
decodedSchemeSpecificPart = null
string = "file:/atlas/Sundance_Apps/MyApp/app.xml"
Digging into java.net.URI#resolve(java.net.URI)
we're told that
this method constructs a new hierarchical URI in a manner consistent with RFC 2396, section 5.2 the new URI's path is computed by resolving the path of the given URI against the path of this URI. This is done by concatenating all but the last segment of this URI's path, if any, with the given URI's path and then normalizing the result as if by invoking the normalize method.
That's when I found the bug: JDK-4723726: URI.normalize() ruins URI built from UNC File
and in the discussion it's mentioned that
They're not going to fix the normalize
method; it would break too much existing code. So what I propose is, when it comes to the App URI, we avoid using the resolve
method (and hence the normalize
method).
Instead, can we not just change the path of the URI to include what we would otherwise resolve
?
Sounds good. Will you make a PR for the change?
Thanks for all your time in reviewing and merging.
When can we expect the new artifact and what version will it be?
Version 1.0.21 was just released now :)
I'm still having issues getting UNC to work and noticed that the fxlauncher-gradle-plugin is still on version 1.0.20, would this affect things?
https://search.maven.org/artifact/no.tornado/fxlauncher-gradle-plugin/1.0.20/jar
Any help appreciated.
I'm having such a hard time. I have a build file that looks like it matches all the requirements. I seem to be running fxlauncher version 1.0.21, and yet I get the same exact error as is listed above.
I think I found it and made a pull request in the fxlauncher-gradle-plugin project.
Thanks! I will do a new release tonight.
Hi! Thanks so much for creating this lovely way to deploy an application.
I've successfully gotten FXLauncher to pull from a regular old
file://C:/some/lovely/path
.What I want to do is get FXLauncher to pull from a Windows UNC path (ex.
//server/share/
).Java seems to handle UNC paths a little differently than I expected.
First I tried configuring the
applicationUrl
with\\myServer\myShare\
, butURI.create()
doesn't like that one bit and says that the\
character is not allowed.I did a little searching and found that you can use the forward slash in combination with the file protocol when working with UNC paths; something like
file:////myServer/myShare/
.So I tried that and it got further, but still no cigar. At some point along the way the
path
of theURI
is losing a slash going from//myServer/myShare/
to/myServer/myShare
. I'm betting this is happening duringgetFXAppURI()
or sometime before whenuri.resolve()
is called.Here's the output when I try to run the natively installed app from the command line:
and here's my
fxlauncher.log
:I'm using the gradle plugin, version 1.0.20.
Here's the relevant configuration: