[Pax Web] Model change in R7

[Grzegorz Grzybek]

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

[Jean-Baptiste Onofré]

Hi Grzegorz

Thanks a lot for your detailed email ! That's a great update and you are faster than I (I'm sorry I'm late on Pax Web :/ ).

I will ping you on Slack asap to see how I can help.

Regards

JB

--
--
------------------
OPS4J - http://www.ops4j.org - op...@googlegroups.com

---
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 ops4j+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ops4j/CAAdXmhpd%2BR%2BZoM5Jqm7dF0V2jogOVxyJ4%2BxfFwX7WGWUPEV1uQ%40mail.gmail.com.