https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #45 from Y. Savanier <yannick.savan...@gmail.com> --- 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 7 to 9 ! Now we were so freaked that a new deployment would break everything that we didn't released even security fixes for those webapps unless it is an absolute case of force majeure ! We even had to put multiple test cases at server startup to ensure the behaviour of the webapps was consistent with what it was on our test platforms, that was so a sick thing to do ! And now we can finaly put a word onto this mess ! For god sake, why was it so important to break a behaviour that was consistent for at least 10 years and was known to many even if not mentioned anywhere in the specs, only by pure rigorism or even "fundamentalist" as the term was rightly pinned in a previous comment ? How can a 17 characters sort instruction, that was there for as long I can recall using tomcat, be considered as a threat to be removed while it was providing consistency whatever operating and file system was used ? I can still remember having to cope with those classloading madness on JBoss in 2006 and the relief it was when our organisation decided to migrate to Tomcat whith which I was absolutly sure (too much as it seems) there would be no mess caused by third party libraries holding old classes that would override the right ones on the server environment while working like a charm on our development and test platforms. As those times are apparently gone and ramdomness seems a more enjoyable behaviour to a lot of person here, we will have to do the only reasonable thing for the overriden classes that are used in those legacy webapps (as we can't possibly adapt the context.xml on our virtual environments each time we make a new release nor copying those jars to the bootstrap folder and coding a custom ClassLoader is clearly not an option here) : We will have to extract every overriding class from the concerned jars into the classes path by adding those to the resources folder of each component in order to be sure that they will be picked first in our tests and on the server side. Every module, for every war artefact, for every project. Yuck ! 🤢 So thank you for this dreadfull decision that took us so much time to figure and that will take some more to adapt to. And don't try invoking java jigsaw (that every sane minded people disable by default) or paralell laoding to justify that, it is just non sense. Regards. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
