I have registered a shared HttpContextMapping with context.id=test and now register a servlet with context.id=test. The HttpContextMapping specifies to which Jetty connectors the servlet should be bound. Everything works perfectly, the servlet is published and accessible.
Now, the servlet gets unregistered, but the HttpContextMapping keeps registered. The servlet gets unpublished by Pax Web and its WebApplication removed. Now, the servlet gets registered again. It is tracked, but not being published.
The problem is that a new WebApplication is created for this servlet, but its HttpContext is unset. That's the reason why the code in WebApplication.class (line 296) is not being executed:
We should find a solution that does not remove the WebApplication instance from the map webApplications. This peace of code is the reason why the WebApplication gets removed (AbstractTracker.class, line: 207)
The webApplication gets removed from the webApplications table, but keeps registered in the map sharedWebApplicationCounter with a not reduced counter > 0 (PAXWEB-967). When the servlet is readded, the associated webApplication cannot be found because the instance is no longer listed. This results in a new object creation.
When the HttpContextMapping itself is removed, we get a java.lang.NullPointerException in the ExtenderContext (line: 90) caused by a webApplication key that is null. It was looked up in the AbstractHttpContextTracker (line: 175) for the HttpContextMapping.
The special case handling in case of a servlet removal should not result in a removal of the webApplication from the table webApplications. This behaviour would solve the NullPointerException and would trigger a republication of a servlet that gets associated with an existing HttpContextMapping even when a servlet has been unregistered before.
could be a regression of PAXWEB-946.