tree cbbacb0265f3de5ff9b89e53f7eb054f4644d112
parent 55ea1e0821db72bc66c2d555069f4338f224ea0b
author abcpro1 <abcpro11051@disroot.org> 1668286603 +0000
committer abcpro1 <abcpro11051@disroot.org> 1668286603 +0000
gpgsig -----BEGIN PGP SIGNATURE-----
 
 iHUEABYKAB0WIQQSQVc4fwEiTkR4o0LP8sylYYU0oAUCY3ATKAAKCRDP8sylYYU0
 oNEgAP9KiWKprpg4TAzoI0fQqvN9DkyYv8WfajP7fmd+7P1dhwD/UUF1R6IGwjfT
 s8PJWZSedyVMHXKlUYsZWxyHZZyg9wY=
 =SEwv
 -----END PGP SIGNATURE-----

Jersey 2: Solve a memory leak

There was a memory leak in org.springframework.web.context.ContextLoader
where objects were being inserted into a map but never removed from it.
The map is [this](https://github.com/spring-projects/spring-framework/blob/v5.3.23/spring-web/src/main/java/org/springframework/web/context/ContextLoader.java#L152-L156).

This map matches a WebApplicationContext to the current thread class loader
The insertion to the map happens during a web application deployment
[here](https://github.com/spring-projects/spring-framework/blob/v5.3.23/spring-web/src/main/java/org/springframework/web/context/ContextLoader.java#L302).
The thread class loader is set prior to this operation by
org.glassfish.grizzly.servlet.WebappContext
[here](https://github.com/eclipse-ee4j/grizzly/blob/2.4.4/modules/http-servlet/src/main/java/org/glassfish/grizzly/servlet/WebappContext.java#L2080)
Finally, when the web application is being destroyed; The WebApplicationContext
inserted earlier is supposed to be removed from the map
[here](https://github.com/spring-projects/spring-framework/blob/v5.3.23/spring-web/src/main/java/org/springframework/web/context/ContextLoader.java#L526).
But, the thread class loader this time is different from when the insertion
occurred.
This is a bug in Grizzly, as you can see
[here](https://github.com/eclipse-ee4j/grizzly/blob/2.4.4/modules/http-servlet/src/main/java/org/glassfish/grizzly/servlet/WebappContext.java#L2106-L2127)
the thread class loader is not set unlike during initialization.
This is the cause of the discrepancy of the thread class loader
between initialization and destruction.

A straightforward solution was implemented in this commit, which is to set
the thread class loader before destruction to the class loader that was
active during initialization.

In the future, this issue needs be solved in the Grizzly project.