[PAX-WEB 8] Another obstacle - WABs and virtual hosts

[Grzegorz Grzybek <gr...@gmail.com>]

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