Re: Plan to release Pax Web 8 + some information

2021-09-13 Thread 'Achim Nierbeck' via OPS4J
Big Kudos to Grzegorz for not giving up on this in the last two years!

best regards, Achim


Am Mo., 13. Sept. 2021 um 12:27 Uhr schrieb Grzegorz Grzybek <
gr.grzy...@gmail.com>:

> Hello!
>
> After almost 2 years of refactoring and development, I think Pax Web 8 is
> ready for release.
> Manual updates are still on my list and some exhaustive documentation (and
> maybe a blog post) is being prepared...
>
> TL;DR:
>
>  - `mvn clean install -DskipTests` in `main` branch of
>> https://github.com/ops4j/org.ops4j.pax.web
>>  - start with clean Karaf 4.3.3
>>
>> karaf@root()> repo-remove org.ops4j.pax.web-7.3.19
>> karaf@root()> repo-add
>> mvn:org.ops4j.pax.web/pax-web-features/8.0.0-SNAPSHOT/xml/features
>> karaf@root()> feature:install pax-web-http-tomcat
>> karaf@root()> feature:install pax-web-war
>> karaf@root()> bundle:install -s
>> 'webbundle:mvn:io.hawt/hawtio-war/2.13.6/war?Web-ContextPath=/hawtio'
>>
>>  - browse to http://localhost:8181/hawtio
>>
>
> However I think it'd be good to describe the rationale behind the rewrite
> and some key points of the new release.
>
> *Background information:*
>
> My single, initial reason to start the refactoring was
> https://github.com/ops4j/org.ops4j.pax.web/issues/1413 issue (migrated
> from https://ops4j1.jira.com/browse/PAXWEB-1123): "HTTP Whiteboard and
> selection of the ServletContextHelper".
>
> Whiteboard specification says, that every web element may reference a
> target ServletContextHelper using "osgi.http.whiteboard.context.select"
> service registration property and its value is an LDAP filter, which may
> also be:
>
> osgi.http.whiteboard.context.select=(osgi.http.whiteboard.context.name=*)
>
> which means "register the servlet into ALL available
> ServletContextHelpers".
> Pax Web 7 was taking the osgi.http.whiteboard.context.select property
> value and was doing split("=") on it to get the name/id of the target
> context... Effectively 1:1 relation was assumed, while Whiteboard
> specification assumes 1:N relationship.
>
> So I started to rewrite the internal Pax Web model... And somehow much
> much more was refactored.
>
> *Pax Web 8 goals:*
>
>- I've carefully read chapters 102 (Http Service specification), 128
>(Web Applications specification) and 140 (Whiteboard specification) of OSGi
>CMPN R7 and tried to implement everything in best possible way
>- I always appreciated how well and cleverly Pax Web was written by
>others from this list:
>
> 11:41 $ git shortlog -snc origin/pax-web-7.2.x
>>894  adreghi...@gmail.com
>>747  anierbeck
>>284  Achim Nierbeck
>>182  ANierbeck
>>123  Guillaume Nodet
>>114  Jean-Baptiste Onofré
>>103  Marc Schlegel
>> 77  jbonofre
>> 53  lostiniceland
>> 44  Stephan Siano
>> 37  Harald Wellmann
>> 21  Marc Klinger
>> 20  Freeman Fang
>> ...
>>
>
>- I wanted to keep the "spirit" of Pax Web - emphasizing target
>runtime (Jetty, Tomcat, Undertow) over "specification first" approach
>- I wanted to ensure that everything in Pax Web works as similar as
>possible in all 3 supported runtimes
>- I wanted to keep the possibility to use native container
>configuration (jetty.xml, tomcat-server.xml, undertow.xml) in addition to
>what we can pass through org.ops4j.pax.web PID
>- I wanted to make Pax Web 8 more reliable (no more flaky tests, no
>more random Thread.sleep() in tests, ...)
>
> *Pax Web 8 highlights:*
>
>- Latest versions of Jetty 9.4.x, Tomcat 9.0.x (without TIPI!) and
>Undertow 2.2.x are used
>- Web "elements" mentioned in Http Service and Whiteboard
>specifications are handled: servlets, filters, listeners, error pages
>- additionally, Pax Web 8 supports everything that can be configured
>in web.xml besides: , , ,
>, , ,
>, , , ,
>, , , ,
>, , ,
>, , ,
>, 
>- "above" what we can find in web.xml, Pax Web 8 supports:
>   - ServletContainerInitializers (SCI) - proved by working
>   JSF/Primefaces/Vaadin examples
>   - web-fragment.xmls
>   - annotated web elements (@WebServlet, @WebFilter, @WebListener)
>   - META-INF/resources locations
>   - websockets via HttpService and Whiteboard
>   - web fragment scanning using tomcat-util-scanner
>- without any mention in any CMPN specification, JSPs, welcome-pages,
>security configurations are supported
>- no more xbean used to scan the "class space"
>- no more dependency to ASM
>- single configuration thread that operates on global model and
>synchronizes the model changes with the state of target runtime (Jetty,
>Tomcat, Undertow)
>- consistent structure of pax-web-jetty, pax-web-tomcat and
>pax-web-undertow:
>   - there's single
>   org.ops4j.pax.web.service..internal.ServerController
>   class (per runtime) implementing
>   org.ops4j.pax.web.service.spi.ServerController#sendBatch() method
>   - 

Plan to release Pax Web 8 + some information

2021-09-13 Thread Grzegorz Grzybek
Hello!

After almost 2 years of refactoring and development, I think Pax Web 8 is
ready for release.
Manual updates are still on my list and some exhaustive documentation (and
maybe a blog post) is being prepared...

TL;DR:

 - `mvn clean install -DskipTests` in `main` branch of
> https://github.com/ops4j/org.ops4j.pax.web
>  - start with clean Karaf 4.3.3
>
> karaf@root()> repo-remove org.ops4j.pax.web-7.3.19
> karaf@root()> repo-add
> mvn:org.ops4j.pax.web/pax-web-features/8.0.0-SNAPSHOT/xml/features
> karaf@root()> feature:install pax-web-http-tomcat
> karaf@root()> feature:install pax-web-war
> karaf@root()> bundle:install -s
> 'webbundle:mvn:io.hawt/hawtio-war/2.13.6/war?Web-ContextPath=/hawtio'
>
>  - browse to http://localhost:8181/hawtio
>

However I think it'd be good to describe the rationale behind the rewrite
and some key points of the new release.

*Background information:*

My single, initial reason to start the refactoring was
https://github.com/ops4j/org.ops4j.pax.web/issues/1413 issue (migrated from
https://ops4j1.jira.com/browse/PAXWEB-1123): "HTTP Whiteboard and selection
of the ServletContextHelper".

Whiteboard specification says, that every web element may reference a
target ServletContextHelper using "osgi.http.whiteboard.context.select"
service registration property and its value is an LDAP filter, which may
also be:

osgi.http.whiteboard.context.select=(osgi.http.whiteboard.context.name=*)

which means "register the servlet into ALL available ServletContextHelpers".
Pax Web 7 was taking the osgi.http.whiteboard.context.select property value
and was doing split("=") on it to get the name/id of the target context...
Effectively 1:1 relation was assumed, while Whiteboard specification
assumes 1:N relationship.

So I started to rewrite the internal Pax Web model... And somehow much much
more was refactored.

*Pax Web 8 goals:*

   - I've carefully read chapters 102 (Http Service specification), 128
   (Web Applications specification) and 140 (Whiteboard specification) of OSGi
   CMPN R7 and tried to implement everything in best possible way
   - I always appreciated how well and cleverly Pax Web was written by
   others from this list:

11:41 $ git shortlog -snc origin/pax-web-7.2.x
>894  adreghi...@gmail.com
>747  anierbeck
>284  Achim Nierbeck
>182  ANierbeck
>123  Guillaume Nodet
>114  Jean-Baptiste Onofré
>103  Marc Schlegel
> 77  jbonofre
> 53  lostiniceland
> 44  Stephan Siano
> 37  Harald Wellmann
> 21  Marc Klinger
> 20  Freeman Fang
> ...
>

   - I wanted to keep the "spirit" of Pax Web - emphasizing target runtime
   (Jetty, Tomcat, Undertow) over "specification first" approach
   - I wanted to ensure that everything in Pax Web works as similar as
   possible in all 3 supported runtimes
   - I wanted to keep the possibility to use native container configuration
   (jetty.xml, tomcat-server.xml, undertow.xml) in addition to what we can
   pass through org.ops4j.pax.web PID
   - I wanted to make Pax Web 8 more reliable (no more flaky tests, no more
   random Thread.sleep() in tests, ...)

*Pax Web 8 highlights:*

   - Latest versions of Jetty 9.4.x, Tomcat 9.0.x (without TIPI!) and
   Undertow 2.2.x are used
   - Web "elements" mentioned in Http Service and Whiteboard specifications
   are handled: servlets, filters, listeners, error pages
   - additionally, Pax Web 8 supports everything that can be configured in
   web.xml besides: , , ,
   , , ,
   , , , ,
   , , , ,
   , , ,
   , , ,
   , 
   - "above" what we can find in web.xml, Pax Web 8 supports:
  - ServletContainerInitializers (SCI) - proved by working
  JSF/Primefaces/Vaadin examples
  - web-fragment.xmls
  - annotated web elements (@WebServlet, @WebFilter, @WebListener)
  - META-INF/resources locations
  - websockets via HttpService and Whiteboard
  - web fragment scanning using tomcat-util-scanner
   - without any mention in any CMPN specification, JSPs, welcome-pages,
   security configurations are supported
   - no more xbean used to scan the "class space"
   - no more dependency to ASM
   - single configuration thread that operates on global model and
   synchronizes the model changes with the state of target runtime (Jetty,
   Tomcat, Undertow)
   - consistent structure of pax-web-jetty, pax-web-tomcat and
   pax-web-undertow:
  - there's single
  org.ops4j.pax.web.service..internal.ServerController
  class (per runtime) implementing
  org.ops4j.pax.web.service.spi.ServerController#sendBatch() method
  - org.ops4j.pax.web.service.spi.task.Batch is a sequence of
  "operations" that change the model or affect the runtime
  - there's single
  org.ops4j.pax.web.service..internal.ServerWrapper class
  (per runtime) that:
 - keeps an instance of the "server"
 (org.eclipse.jetty.server.Server,
org.apache.catalina.core.StandardServer
 or io.undertow.server.HttpHandler + collection