Re: Plan to release Pax Web 8 + some information
+1
Re: Plan to release Pax Web 8 + some information
+1
Erwin
> On Sep 13, 2021, at 09:42, Achim Nierbeck
> wrote:
>
> 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.ServerControll
Re: Plan to release Pax Web 8 + some information
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
> - org.ops4j.pax.web.service.spi.task.B
Plan to release Pax Web 8 + some information
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 o
