https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
--- Comment #31 from Mateusz Matela <mateusz.mat...@gmail.com> --- (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 aspect of behavior, is it really the best approach to derive this behavior from some unrelated circumstances like the underlying file system? > Assuming that users never switch > application servers, it's probably harmless. But if you use a sorting-Tomcat > and move to JBoss and your stuff stops working, So you consider it a harm when some apps stop working on migration from Tomcat to JBoss, but it's good if they stop working on migration between versions of Tomcat? I see no logic here. > JBoss will tell you the same > thing: you were relying on some wacky behavior those crazy kids at Apache > Tomcat were willing to do, and now you have to grow up and adhere to > published specifications. You can call it wacky, I call it practical. What is your point here? Do you think that after this change people will get angry at Tomcat (more than in this bug) and demand that their apps stop working too? Going further this way, maybe there should be a config for more randomization in jar loading so that "incorrect" apps fail more often? > Why do you have JAR files that rely on specific ordering to > maintain determinism? I can't understand why someone would build an > application like that. Oh well, so I don't live in a perfect world and my apps are not perfect. But I lived with these imperfections for many years and everything was fine. Until someone in their ivory tower decided that these imperfections are actually more important than anything else I might want to work on... Or that I'm not worthy to use newer versions of Tomcat. Oh, thank you, Master! -- 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
