)]}'
{
  "commit": "882c71d3306cb6d43ab91b3a4c3d6091d48ab922",
  "tree": "cbbacb0265f3de5ff9b89e53f7eb054f4644d112",
  "parents": [
    "55ea1e0821db72bc66c2d555069f4338f224ea0b"
  ],
  "author": {
    "name": "abcpro1",
    "email": "abcpro11051@disroot.org",
    "time": "Sat Nov 12 20:56:43 2022 +0000"
  },
  "committer": {
    "name": "abcpro1",
    "email": "abcpro11051@disroot.org",
    "time": "Sat Nov 12 20:56:43 2022 +0000"
  },
  "message": "Jersey 2: Solve a memory leak\n\nThere was a memory leak in org.springframework.web.context.ContextLoader\nwhere objects were being inserted into a map but never removed from it.\nThe 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).\n\nThis map matches a WebApplicationContext to the current thread class loader\nThe insertion to the map happens during a web application deployment\n[here](https://github.com/spring-projects/spring-framework/blob/v5.3.23/spring-web/src/main/java/org/springframework/web/context/ContextLoader.java#L302).\nThe thread class loader is set prior to this operation by\norg.glassfish.grizzly.servlet.WebappContext\n[here](https://github.com/eclipse-ee4j/grizzly/blob/2.4.4/modules/http-servlet/src/main/java/org/glassfish/grizzly/servlet/WebappContext.java#L2080)\nFinally, when the web application is being destroyed; The WebApplicationContext\ninserted earlier is supposed to be removed from the map\n[here](https://github.com/spring-projects/spring-framework/blob/v5.3.23/spring-web/src/main/java/org/springframework/web/context/ContextLoader.java#L526).\nBut, the thread class loader this time is different from when the insertion\noccurred.\nThis is a bug in Grizzly, as you can see\n[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)\nthe thread class loader is not set unlike during initialization.\nThis is the cause of the discrepancy of the thread class loader\nbetween initialization and destruction.\n\nA straightforward solution was implemented in this commit, which is to set\nthe thread class loader before destruction to the class loader that was\nactive during initialization.\n\nIn the future, this issue needs be solved in the Grizzly project.\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "578c94e25e2983711d590f6ebb54cf5e9c767be8",
      "old_mode": 33188,
      "old_path": "full/src/test/java/de/ids_mannheim/korap/config/StaticContextLoaderListener.java",
      "new_id": "5dd00a0e0359b6c6f104c5f6b8d46aea228c53c9",
      "new_mode": 33188,
      "new_path": "full/src/test/java/de/ids_mannheim/korap/config/StaticContextLoaderListener.java"
    }
  ]
}