Hello A quick summary of my pending review of Pax Web 8.
I'm reviewing the code from the perspective of: - R7 Whiteboard implementation (allowing e.g., `osgi.http.whiteboard.context.select=(osgi.http.whiteboard.context.name=*)`) - Virtual Hosts (Pax Web supports them in Jetty only it seems) - "shared contexts" with special handling of shared HttpContext (old HttpService spec), while new ServletContextHelper is "shared" by default Current "model" is roughly: - ServerModel - ensures uniqueness of element registration - ServiceModel - organizes web elements registered through given, bundle-scoped HttpService (which is not that useful in Whiteboard) - ContextModel - which roughly relates to single WAR (web.xml) and conflicts with concepts kept at ServiceModel level - ServletModel, FilterModel - that's ok The problems are: - "virtual host" is only additional layer of mapping inside ServerModel and requires tricks when a context is part of multiple virtual hosts (which is possible and natural in all 3 runtimes) - ContextModel is tied to bundle (and classloader!) though it should model a "context" potentially populated with web elements coming from different bundles (if needed) Specification allows some exotic scenarios: - non default (non "/") context path is allowed ONLY if you register ServletContextHelper with a property/annotation - this can potentially switch "default" (OSGi) context to non "/" context path - Pax Web allowed to do the same with "old" HttpContext (specify a path) - if two ServletContextHelpers with different name and the same path are specified, servlets using two different ServletContextHelpers can be registered to the same physical (server specific) context handler - Pax Web doesn't handle it well My current findings: - I've introduced VirtualHostModel to allow namespace clash detection at VHost level (not specified by OSGi CMPN) - the goal is to unify Virtual Host handling for 3 runtimes - I've split ContextModel into ServletContextModel and OsgiContextModel to match specification (where two+ different ServletContextHelpers may actually refer to single server-specific context) - I think about removing ServiceModel, because it was HttpService (non Whiteboard) centric - I progressed with unification of HttpContext and ServletContextHelper - I'm implementing "transactional" behavior for web element registration - I'm reviewing the layers of interfaces (http service → service controller → server state → server abstraction → actual server), where each layer contain interfaces with methods like start() or registerXXX(). Anyway - it became bigger mess than I expected, but I still see the light in the tunnel :) best regards Grzegorz Grzybek -- -- ------------------ OPS4J - http://www.ops4j.org - [email protected] --- You received this message because you are subscribed to the Google Groups "OPS4J" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ops4j/CAAdXmhpd%2BR%2BZoM5Jqm7dF0V2jogOVxyJ4%2BxfFwX7WGWUPEV1uQ%40mail.gmail.com.
