https://bz.apache.org/bugzilla/show_bug.cgi?id=59001
Mark Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bz.apache.org/bugzilla/show_bug.cgi?id=59001
--- Comment #11 from Mark Thomas ---
Having looked at where we construct Jar URLs (and URLs that may be used to
later build Jar URLs) there were a handful of places where we needed to add
appropriate escaping. I've implemented the escaping for
https://bz.apache.org/bugzilla/show_bug.cgi?id=59001
--- Comment #10 from Jayashankar Karnam ---
Either it get's fixed in the next releases or not, I strongly feel there has to
be some exception handling which doesn't trick developers to invest more energy
on debugging possible root cause within
https://bz.apache.org/bugzilla/show_bug.cgi?id=59001
--- Comment #9 from Mark Thomas ---
(In reply to Christopher Schultz from comment #8)
> (In reply to Mark Thomas from comment #6)
> > I'm not concerned about startup. That is a one-off cost. What concerns me is
> > the performance impact of ad
https://bz.apache.org/bugzilla/show_bug.cgi?id=59001
--- Comment #8 from Christopher Schultz ---
(In reply to Mark Thomas from comment #6)
> I really wanted to fix this but I'm not sure that supporting this use case
> is worth the cost.
>
> There are two places I have found (so far) where change
https://bz.apache.org/bugzilla/show_bug.cgi?id=59001
--- Comment #7 from Martti ---
I'm having similar problem but with + sign. Our build system (gradle) creates
executable war with Mercurial revision hash. Sometimes this hash can contain
"+" as a last character ala "kalkulaator-f83780e3571e+.war
https://bz.apache.org/bugzilla/show_bug.cgi?id=59001
--- Comment #6 from Mark Thomas ---
I really wanted to fix this but I'm not sure that supporting this use case is
worth the cost.
There are two places I have found (so far) where changes would be required. The
first is during start-up to ensur
https://bz.apache.org/bugzilla/show_bug.cgi?id=59001
--- Comment #5 from Christopher Schultz ---
No problem. The only question is whether or not Tomcat knows at the time that
the URL it's building is a physical on-disk resource. If Tomcat does know this,
it can escape special characters like "!".
https://bz.apache.org/bugzilla/show_bug.cgi?id=59001
--- Comment #4 from Jayashankar Karnam ---
JarURLConnection is responsible for the mishap. As per java doc "!/" is a
terminator for the jar file. That's the reason why it is failing at
G:/TEST!Maven not G:/TEST
And whatever comes after the "!/
https://bz.apache.org/bugzilla/show_bug.cgi?id=59001
--- Comment #3 from Christopher Schultz ---
Honestly, I'm surprised that it's failing where it is: I would have expected it
to fail saying that "G:\TEST" didn't exist.
This isn't Tomcat doing this; it's the combination of a large number of
com
https://bz.apache.org/bugzilla/show_bug.cgi?id=59001
--- Comment #2 from Jayashankar Karnam ---
My disk path is "G:\TEST!Maven!\..."
Indeed, it is a corner use case.
Is there any reason why tomcat is solely relying on "!" to identify end of the
string? When we know that is the path to find spec
https://bz.apache.org/bugzilla/show_bug.cgi?id=59001
Christopher Schultz changed:
What|Removed |Added
OS||All
--- Comment #1 from Christop
12 matches
Mail list logo
