Hello I'm progressing well with simplification/stabilization of WAB support in Pax Web 8.
Here's a draft schema of how it works now with Pax Web 7 1) Bundles with Web-ContextPath manifest header are "tracked" as "web apps" 2) web.xml parsing (if such descriptor is available) is performed in the thread that activates the bundle - so it's usually FelixStartLevel thread ( *bad!*) 3) a WebApp with web.xml started is returned as "extension", which is "started" in one of 3 (*hardcoded number!*) threads, but before it is started, it is associated with a ServiceTracker for HttpService services and when such tracker is notified, WebAppDependencyHolder service is registered 4) when "starting", it is determined whether the bundle's "context name" and "virtual hosts list" are non-conflicting to prevent tracking two WARs with same context (that's fine). *But this doesn't involve verification with contexts created using Whiteboard or HttpService!* 5) non-conflicting bundle is "published", but this only means registration of service listener for WebAppDependencyHolder services for given bundle - such service becomes available when HttpService is available 6) so when WebAppDependencyHolder is passed to a service listener, we finally have a) parsed WebApp, b) HttpService (WebContainer) instance, we can now "register" such WebApp 7) "registration" is performed in various threads - depending on what was first - HttpService or the WebApp 8) "registration" involves passing a registration visitor to WebApp.accept() method and consists of interaction with HttpService/WebContainer to register servlets, filters, etc. in WebContainer As you can see this is a pattern where entities are synchronized using service trackers/listeners and OSGi services being registered with no reason - for example IMO there should be no need to register WebAppDependencyHolder OSGi service, as it contains only a reference to bundle-scoped HttpService and one (one!) ServletContainerInitializer - no idea who could use such OSGi service. The bigger problem is VHost → contextName → List<WebApp> mapping: 1) it's not consistent with conflict-prevention where Whiteboard and HttpService contexts are involved 2) there's a way to "alter" a web context created by WAR extender using Whiteboard registration of additional elements (like filters) to the same context - but there's no implementation of the scenario, where WAR is uninstalled - what should be done with the additional filters? 3) virtual host handling is totally inconsistent between runtimes. in Tomcat, a virtual host is separate entity - "above the context", while in Jetty it's a "property of the context" that allows/rejects a request for given context when VHost (Host: header) doesn't match. In Undertow it's just yet another handler that accepts/rejects a request (similar behavior to Jetty). So please give me some more time ;) regards Grzregorz Grzybek
