[Bug 57129] Regression. Load WEB-INF/lib jarfiles in alphabetical order

[bu...@apache.org]

https://bz.apache.org/bugzilla/show_bug.cgi?id=57129

--- Comment #5 from Guillaume Smet <gu...@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 on adding this unncessary bloat to the new resources implementation
> in Tomcat 8.

Any chance this could be revisited? I see 2 reasons why having a predictible
order is necessary:
- you might consider an application which depends on the order of the jars
broken but the issue here is that, if the order is inconsistent depending on
the OS/filesystem, you have a good chance to have your application failing when
you deploy it on another OS/FS or even from a deploy to another.
- I'm pretty sure a lot of people used this feature to override classes of
other jars in a easily maintanable way (eg having
000-hibernate-override-1.0.0.jar for instance).

> Broken web applications that need a JAR to be searched for classes before
> all other JARs can force this via configuration in the context.xml file.
> Something along the lines of the following should work:
> 
> <Resources>
>   <!-- Trick to force this JAR to be searched for classes before all others
>        to work around a Jira bug -->
>   <PreResources className="org.apache.catalina.webresources.FileResourceSet"
>                
> base="${catalina.base}/webapps/jira/WEB-INF/lib/jira-api-6.2.jar"
>                 webAppMount="/WEB-INF/lib/jira-api-6.2.jar" />
> </Resources>

It's not something maintanable in a continuous deployment/Maven/gradle world.
We update the jar versions very often and it's really not something we can do.

I really think guaranteeing a predictible order is following the POLA and
adding a sort is really worth it.

Thanks for your feedback!

-- 
Guillaume

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org