This test now fails because of the fix for the Resources, that made the WAR test run again.
The main issue of this one is, that we do have two http-contextes, one forbidden is registered first, the second default one is registered second.
The first one is always taken from the Container because it's the one registered to it ...
... Ohh ... sorry for sending you down that Rabbit Hole ... I should have payed more attention to this Issue
Yeah this is a general problem of the way Pax Web works in combination with Tomcat. While this isn't a problem at all for Jetty and undertow it's a Tomcat only issue :/
There seems to be a general issue in pax-web-tomcat that multiple HttpContexts from the OSGi HTTP service do not work.
An idea might be do map the HttpContext to a ServletContext, modify the HttpServiceContext (pax-web-tomcats catalina Context implementation) in a way that multiple HttpServiceContexts can reference the same ServletContext and then register one HttpServiceContext per Servlet registered by the HttpService.
Nevertheless I wonder whether we should close this issue and create a new one for the context mapping thing.
After a look into the Tomcat implemnetation my idea does not work. catalina context and ServletContext have a hard 1:1 relationship.
What if we would register the servlets in several (Catalina) contexts? In the end it would mean that we break the 1:1 relationship between HttpContext and ServletContext, but I re-read the OSGi enterprise spec and this does not seem to be a hard requirement.
Multiple contexts also don't work, there is no reasonable way to assign filters and listeners appropriately if we register one context per servlet.
Therefore I kept the HttpContext - catalina Context relationship as it is. Instead I changed the basic valve for the host to try to find the correct context before executing the pipeline.
FYI - I'm reviewing entire Pax Web model for Pax Web 8. There are many different "contexts" now:
a "context" per physical server-specific context (1:1 with single, unique context path)
a "context" per HttpContext/ServletContextHelper where several such contexts can point to the above
a "context" per request, because if you have single servlet associated to two different above contexts, getClassLoader() method of such context has to return classloader of the bundle registering the servlet, not the classloader of the bundle registering ServletContextHelper...
Also, ServletContextHelper instance should be obtained from reference if such helper is service factory...