Multiple versions of logback in my classpath

[Brent Putman]

On 8/17/16 2:48 PM, Cantor, Scott wrote:
>
> But I don't know why it wouldn't just load it from the Jetty global
> class loader. I've done that frequently with database drivers and things
> like that.

I don't know for sure either.  I'm not familiar enough with Jetty's
classloader(s) hierarchy and how that would interact with the SLF4J
static binding mechanism.

But ultimately I think this is a classloader issue, and it's because
the Jetty server classloader is by default exposing those classes to
the web application.  I think the "clean" solution to the problem would
be to put the slf4j and logback jars for Jetty into a classloader that
is visible only to the Jetty container and is *not* visible to web apps.

Don't know if or how that's possible in Jetty.  By contrast, in Tomcat
they have a pre-existing classloader in the hierarchy called 'server'
for that very purpose (although it's empty and unused by default in
modern versions. If you want to use you configure in
catalina.properties.  There's also an unused 'shared' one, which is
visible to all web apps but not the container.  The default 'common'
one defined as the stuff in catalina.base and catalina.home /lib is
visible to both the container and all webapps).

I was looking to see if something similar is possible in Jetty, but I
just don't know it well enough to make sense of the docs.  The thing I
was looking at is here, if someone else wants to have a go:

http://www.eclipse.org/jetty/documentation/current/jetty-classloading.html

Or maybe some Googling would produce a sample config for a
container-only classloader.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160817/8f29c68f/attachment-0001.html>