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: dev-unsubscr...@tomcat.ap
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 a.jar
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 T
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 s
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
Remy Maucherat changed:
What|Removed |Added
Severity|normal |enhancement
--
You are receiving thi
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
Philippe Cloutier changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|WONTFI
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 you
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 i
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 acc
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
will
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 appro
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 sort
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. Bro
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 ne
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).
--
Yo
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
fu
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 - otherwi
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 a
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 in
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? Is
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 m
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 e
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 will still fail because not the
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 least always fail.
I
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
Sebastien Tardif changed:
What|Removed |Added
CC||sebtar...@ncf.ca
--
You are receiv
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
Mark Thomas changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|REOPENED
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 tom
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
fchris...@gmail.com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVA
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 duplicated classes, we h
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
information does not match
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 th
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 failing in the two prod servers.
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 instance have a
different
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 are required, they still can b
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 predictable for class
loading order.
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 at least Tomcat 5. I
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #12 from quaff ---
(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 config files and
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #11 from Christopher Schultz ---
(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 classes, It
> works fine wi
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
Remy Maucherat changed:
What|Removed |Added
Resolution|--- |INVALID
Status|REOPENED
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
quaff changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
quaff changed:
What|Removed |Added
CC||zhouyanm...@gmail.com
--
You are receiving th
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #8 from Mark Thomas ---
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 ---
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 version of Tomca
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #6 from Mark Thomas ---
My position - and reasons for that position - remain unchanged.
--
You are receiving this mail because:
You are the assignee for the bug.
---
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
Guillaume Smet changed:
What|Removed |Added
CC||guillaume.s...@gmail.com
--
You are
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #5 from Guillaume Smet ---
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 on adding this unncess
https://issues.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #4 from Christopher Schultz ---
(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 to do with the order in whi
https://issues.apache.org/bugzilla/show_bug.cgi?id=57129
Mark Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://issues.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #2 from Jörgen Persson ---
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 the bug.
---
https://issues.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #1 from Jörgen Persson ---
Created attachment 32134
--> https://issues.apache.org/bugzilla/attachment.cgi?id=32134&action=edit
Adds Arrays.sort(...) in the two identified methods
--
You are receiving this mail because:
You a
62 matches
Mail list logo