Re: [jetty-users] Jetty 9.4.44 Classloader visibility issue

[Joakim Erdfelt <joakim@xxxxxxxxxxx>]

Sharing 1 WebAppClassLoader across multiple contexts is not a supported configuration.

The lifecycle alone would undo/change behaviors in nasty ways across your contexts.

I'm frankly surprised you didn't hit issues already, merely starting multiple contexts sharing a single WebAppClassLoader means you have to have the timing to be perfect and exact to not have 1 context undo changes applied to the WebAppClassLoader from a different context.

I would strongly encourage you to not do this.

Look into sharing classes via JNDI or even WebAppContext.setExtraClasspath() instead.

And even then, there's really no benefit in terms of memory or speed over just using separate WebAppClassLoaders.

BTW, this setup is 100% incompatible with certain FileSystem types (the classloader filesystem locks along with the classloader lifecycle would prevent this type of configuration, first attempt to start would work, second onwards would fail).

Joakim Erdfelt / joakim@xxxxxxxxxxx

On Mon, Feb 14, 2022 at 9:28 AM Michael Klenk <mk-klenk@xxxxxx> wrote:

Hi Community,


I've been experiencing weird classloading issues due to redeployment of
a single WAR Application containing latest Jersey Framework.

In the current setup I'm using Jetty 9.4.44 as Application Container to
host webapplications on a Linux host. In the past I've restarted the
Jetty process on Linux when I've deployed new applications. Recently
I've tried to just redeploy the WAR file to the server and was getting
ClassNotFound Exceptions from the Classloader.  A deeper analysis
showed, that the Jersey class was still loaded from the former
classloader instance of WebAppClassloader from a different context,
which I expected to be deleted with the webapplication on unloading the
context and redeploying the software without restarting the Jetty
Process. It happened even if the former application was removed and the
deployment of the WAR file happened minutes later in  a second step.

Is this a known issue with Jetty, reusing unused classloader instances?
Or is it a Bug with Jersey framework or Jetty Classloader isolation? How
could an application force Jetty to share multiple WebAppClassLoader
instances inside of one single context.

Thank you in advance


Michael

_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users