https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #53 from Martin bestandig ---
Dellet
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail:
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #52 from Christopher Schultz ---
(In reply to Philippe Cloutier from comment #50)
> Typically, with Maven, if a project depends on 3 libraries and pom.xml lists
> B before A and finally C, the WAR file can contain b.jar before
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #51 from Philippe Cloutier ---
(In reply to Mateusz Matela from comment #28)
> (In reply to Mark Thomas from comment #27)
> > The patch would have to be very minimal and the behaviour
> > optional to be considered for inclusion in
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #50 from Philippe Cloutier ---
Thank you very much for reporting Jörgen and all those who commented
constructively
My employer is one of those organizations which lost hours due to variability
in loading order. For those who are
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
Remy Maucherat changed:
What|Removed |Added
Severity|normal |enhancement
--
You are receiving
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
Philippe Cloutier changed:
What|Removed |Added
Status|RESOLVED|REOPENED
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #48 from Christopher Schultz ---
This bug report has been RESOLVED WONTFIX.
Please don't use Bugzilla to conduct a flame war. If you want to discuss this
(again), please raise the issue on the users' or developers' mailing list.
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #47 from Y. Savanier ---
Nice try but no, I've always run my webapps on linux machines and the Tomcat
handling of jars at loading was always alphabeticaly ordered as far as I can
remember which is what I'm talking about here (if
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #46 from Konstantin Kolinko ---
(In reply to Y. Savanier from comment #45)
>
> For god sake, why was it so important to break a behaviour that was
> consistent for at least 10 years
You are wrong. The behavour was not consistent,
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #45 from Y. Savanier ---
Oh my god this is just a gem that I got unnoticed until now...
It explain so much of the random behaviour we started to have on our legacy
webapps since 2 years now when we ingenuously upgraded from Tomcat
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
JHack changed:
What|Removed |Added
CC||gbocc...@gmail.com
--
You are receiving this
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
davide.vec...@enghouse.com changed:
What|Removed |Added
CC||davide.vec...@enghouse.com
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #44 from Mateusz Matela ---
(In reply to mgrigorov from comment #42)
> As Mark mentioned since recently Tomcat added functionality to scan the jars
> in parallel. No matter whether the jars are sorted or not the results from
> the
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #43 from Bernhard Seebass ---
(In reply to mgrigorov from comment #42)
>
> As Mark mentioned since recently Tomcat added functionality to scan the jars
> in parallel. No matter whether the jars are sorted or not the results from
>
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #42 from mgrigorov ---
(In reply to Mateusz Matela from comment #41)
> This will still force people who already are in this trap to potentially
> spend lots of time to investigate what's wrong, learn about this feature and
> turn
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #41 from Mateusz Matela ---
(In reply to mgrigorov from comment #38)
> Since there are some users (to be precise: 13 in 6 years!) who depend on
> this behavior
That's only the number of people motivated enough to create/have an
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #40 from Mateusz Matela ---
(In reply to Mark Thomas from comment #39)
So maybe this is the root of the misunderstanding here: nobody's asking for
this to be a fully fledged officially supported feature with guarantees that it
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #39 from Mark Thomas ---
The more I think about this, the more convinced I am that the proposed patch,
even with the ordering behaviour made optional via configuration, is not the
right way to address this issue.
The proposed
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #38 from mgrigorov ---
We still believe that depending on the order of the jars (or on the moon phase)
is wrong!
Since there are some users (to be precise: 13 in 6 years!) who depend on this
behavior then we are fine to add the
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #37 from Martin Knoblauch ---
Hi Remy,
so I do not see any of them explain why it is not a regression compared to the
past (reliable) behavior.
#3 blames "broken applications" for a relying on a behavior that worked for
years.
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #36 from Remy Maucherat ---
This is of course not a regression. Please read comments 3, 26 and 27 again.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #35 from Martin Knoblauch ---
Exactly. A patch was submitted long time ago, but ignored due to the refusal to
see this as a regression (not on technical merit as far as I can see. Except
the "bloat" comment). No need to ask for a
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #34 from Mateusz Matela ---
(In reply to mgrigorov from comment #33)
There's already a patch provided that adds two lines of code.
The unresolved issue is why this is not enough (i.e. there should be a new
option for this).
--
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #33 from mgrigorov ---
At https://bz.apache.org/bugzilla/show_bug.cgi?id=57129#c27 (July 2019) Mark
Thomas said that a patch/PR would be welcome for review!
No one cared to send such for more than an year! If you really need this
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #32 from Martin Knoblauch ---
Found this gem by accident. Now I understand some of our problems going from
7.0 to 9.0.
This is clearly a regression. With an easy fix. Not even "bloat".
I really fail the resistance of the -
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #31 from Mateusz Matela ---
(In reply to Christopher Schultz from comment #29)
> > Can you explain why this has to be optional?
>
> Because it's very nearly a spec violation.
That's a big stretch. If the spec doesn't specify some
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
Mateusz Matela changed:
What|Removed |Added
CC||mateusz.mat...@gmail.com
--
You are
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #30 from quaff ---
It's absolute regression. I used to create second party library to overlay
resources(template or config) in third party library, now I need to modify
third party library or extract files from second party library
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #29 from Christopher Schultz ---
(In reply to Mateusz Matela from comment #28)
> (In reply to Mark Thomas from comment #27)
> > The patch would have to be very minimal and the behaviour
> > optional to be considered for inclusion
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #28 from Mateusz Matela ---
(In reply to Mark Thomas from comment #27)
> The patch would have to be very minimal and the behaviour
> optional to be considered for inclusion in Tomcat.
Can you explain why this has to be optional?
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #27 from Mark Thomas ---
Something to keep in mind is the possible impact of the Java module system in
future versions of the Servlet spec. My understanding is that Java modules do
not allow packages to exist in more than one JAR.
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #26 from Remy Maucherat ---
It doesn't look like this will be integrated based on previous comments, but
the move to git is supposed to make fork and customization like this easier.
--
You are receiving this mail because:
You are
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
Kuba changed:
What|Removed |Added
CC||jsamc...@gmail.com
--
You are receiving this
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #25 from Kuba ---
Well,
after spending hundreds of man days to migrate our applications (including
legacy) to new java and tomcat 9 I encoutered this... When installing
application on production environment after all tests on test
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #24 from Christopher Schultz ---
(In reply to Sebastien Tardif from comment #23)
> It seems this issue is about fundamentalist versus pragmatism. Even if the
> order is deterministic, some application
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #23 from Sebastien Tardif ---
It seems this issue is about fundamentalist versus pragmatism. Even if the
order is deterministic, some application will still fail because not the order
they are used to, but at
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
Sebastien Tardif changed:
What|Removed |Added
CC||sebtar...@ncf.ca
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
Mark Thomas changed:
What|Removed |Added
Resolution|--- |WONTFIX
Hi Mark,
re: https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
This change seems significant enough that it merits mention in:
https://tomcat.apache.org/migration-8.html
I've inherited a number of tomcat7 servers which host quite a few
wars/exploded wars, and I'd love to move us forward to
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
fchris...@gmail.com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #20 from fchris...@gmail.com ---
(In reply to Mark Thomas from comment #8)
> You can easily detect if the potential for problems exists. Look for classes
> duplicated in multiple JARs.
Even if we can detect
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #19 from fchris...@gmail.com ---
Hi everybody,
We also have some problems due to random jar loading order after we moved from
Tomcat 7 to Tomcat 8. Application is not starting and displays error 'signer
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #18 from war...@gmail.com ---
Hello,
Give back a deterministic, reproducible classloader!!!
P.Busque ask at least an option to do that
I vote +100 on that!
I manage ~100 of web application on an old application server
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #17 from CBen ---
We have upgraded from Tomcat 6 / Java 6 to Tomcat 8 / Java 7.
Everything was deployed and working successfully in tests environments and 3
prod servers. However, the deployment was
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #16 from Philippe Busque ---
We just begun converting your tomcat 6 and tomcat 7 Webfarm to Tomcat 8, and
honestly, this is a show stopper for us.
We cannot, in a cluster setup, start Tomcat and have each
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #13 from Joachim Economou ---
I understand the argument that an application that depends on Tomcat reading
its jar files alphabetically is broken, however we are talking about a behavior
that has persisted since
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #14 from Guillaume Smet ---
Hi Joachim,
The issue with PreResources is that you need to use an absolute path which is
quite impractical.
Moreover, it doesn't solve the issue of having something
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #15 from Christopher Schultz ---
(In reply to Guillaume Smet from comment #14)
> The issue with PreResources is that you need to use an absolute path which
> is quite impractical.
While absolute paths
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #12 from quaff zhouyanm...@gmail.com ---
(In reply to Christopher Schultz from comment #11)
(In reply to quaff from comment #9)
I have the same problem, my application need to override resources of
third-party libs, for example
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
quaff zhouyanm...@gmail.com changed:
What|Removed |Added
CC||zhouyanm...@gmail.com
--
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
quaff zhouyanm...@gmail.com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
Remy Maucherat r...@apache.org changed:
What|Removed |Added
Resolution|--- |INVALID
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #11 from Christopher Schultz ch...@christopherschultz.net ---
(In reply to quaff from comment #9)
I have the same problem, my application need to override resources of
third-party libs, for example config files and templates even
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #8 from Mark Thomas ma...@apache.org ---
You can easily detect if the potential for problems exists. Look for classes
duplicated in multiple JARs.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #7 from David Corbin dcor...@ieee.org ---
Just one more comment about this. We've recently upgrade to Tomcat 8 and
encountered this. The net effect is that Tomcat is now non-deterministic. We
have the same war file running on the
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #5 from Guillaume Smet guillaume.s...@gmail.com ---
Hi Mark,
(In reply to Mark Thomas from comment #3)
Applications that depend on JARs being searched for classes in a particular
order are broken and should be fixed.
I am -1
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
Guillaume Smet guillaume.s...@gmail.com changed:
What|Removed |Added
CC|
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #6 from Mark Thomas ma...@apache.org ---
My position - and reasons for that position - remain unchanged.
--
You are receiving this mail because:
You are the assignee for the bug.
https://issues.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #1 from Jörgen Persson j...@jorgenpersson.se ---
Created attachment 32134
-- https://issues.apache.org/bugzilla/attachment.cgi?id=32134action=edit
Adds Arrays.sort(...) in the two identified methods
--
You are receiving this
https://issues.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #2 from Jörgen Persson j...@jorgenpersson.se ---
I found the problem running Linux Mint 17.
On Windows 7 64 bit, the files seems to be ordered alphabetically.
--
You are receiving this mail because:
You are the assignee for
https://issues.apache.org/bugzilla/show_bug.cgi?id=57129
Mark Thomas ma...@apache.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://issues.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #4 from Christopher Schultz ch...@christopherschultz.net ---
(In reply to Jörgen Persson from comment #2)
I found the problem running Linux Mint 17.
On Windows 7 64 bit, the files seems to be ordered alphabetically.
This has
62 matches
Mail list logo