You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@karaf.apache.org by Jean-Baptiste Onofre <jb...@nanthrax.net> on 2020/07/07 09:18:23 UTC

[DISCUSSION] Apache Karaf 4.3.0 and Pax Web

Hi everyone,

It’s more than a year now that we started Apache Karaf 4.3.0 release process, fully supporting OSGi R7.

If the 4.3.0 distribution is ready, we are blocked by Pax Web. I’m concerned about that as R8 will be there and we will have issue in Pax Web again.

Greg started a huge effort heading to Pax Web 8.0.0 with a large refactoring.
However, the process is long and painful.
So, I think it’s fair to have a discussion about the HTTP service in Karaf and "relationship" with Pax Web.

I see three options for Karaf 4.3.0:

1. We are able to release Pax Web 8.0.0 (with R7 support) and so, no brainer, we can move forward.
2. Instead of using Pax Web by default, we "switch" to Felix HTTP by default. For the "pure" HTTP service, it will be transparent but it would have two impacts:
  * the configuration changes (as obviously etc/org.ops4j.pax.web.cfg doesn’t exist anymore)
  * users using WebContainer PaxWeb API instead of HTTP service won’t work
3. We consider that Pax Web as it is today is not flexible enough and too painful, and we start an even larger refactoring on Pax Web.

The reason why I’m bringing this discussion on the mailing list: we really need a clear plan and release 4.3.0 (I would really love to release 4.3.0 mid July max, so we need a plan).

Thoughts ?

Regards
JB

Re: [DISCUSSION] Apache Karaf 4.3.0 and Pax Web

Posted by Robert Varga <ni...@hq.sk>.

On 07/07/2020 11:18, Jean-Baptiste Onofre wrote:
> Hi everyone,
> 
> It’s more than a year now that we started Apache Karaf 4.3.0 release process, fully supporting OSGi R7.
> 
> If the 4.3.0 distribution is ready, we are blocked by Pax Web. I’m concerned about that as R8 will be there and we will have issue in Pax Web again.
> 
> Greg started a huge effort heading to Pax Web 8.0.0 with a large refactoring.
> However, the process is long and painful.
> So, I think it’s fair to have a discussion about the HTTP service in Karaf and "relationship" with Pax Web.

Hello,

from OpenDaylight perspective, there are four main factors that would
drive karaf-4.3.0 adoption:

1) OSGi DS 1.4, for constructor injection
This is just nice-to-have to clean up some (small) amount of duplication.

2) Java 14+ support
This is for testing, we certainly can do a fair amount of that without
Karaf anyway.

3) HTTP Whiteboard 1.1
This is of real interest, as we could ditch our home-grown 'solution' to
servlets.

4) JAX-RS Whiteboard 1.0
Just as HTTP, this would allow us to have a clean solution to JAX-RS
integration, which we cudgeled to work, but has been a constant source
of pain.

Based on this, karaf-4.3.0 without R7-compliant HTTP/JAX-RS has very
little going for it from our perspective.

Also, we do use Equinox as the framework implementation -- perhaps for
historical reasons, but it works well and we do not have the cycles to
spend on qualifying Felix.

Regards,
Robert

Re: [DISCUSSION] Apache Karaf 4.3.0 and Pax Web

Posted by Romain Manni-Bucau <rm...@gmail.com>.

A few comments to previous answer - hoping it is not too "off track":

1. Advantage of tomcat (or more generally selecting the servlet container)
is generally you share the tooling in the company. If you are a one
software company then you don't care but if you industrialize and build a
shared stack it is important to be able to select a particular impl to
instrument this one particularly.
2. I didn't see anything in httpservice which can't be implemented on top
of servlet - whatever impl - and always wondered why pax didn't pick to
just integrate with the servlet layer. I know today it integrates lower
level to be dynamic but it is trivial - and required in r7 - to be dynamic
at whiteboard level and not container level (regex pattern out of my head)
so can be a later refacto which can simplify pax web a lot since there is
only one impl to maintain. Then it is just a matter of making servlet
containers OSGi friendly (think tomcat is, jetty too, not sure for
undertow).

Hope I'm not too "off".

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mar. 7 juil. 2020 à 13:43, Francois Papon <fr...@openobject.fr>
a écrit :

> Hi,
>
> I think the most important thing is to be more flexible for the releases
> roadmap of Karaf.
>
> If it's possible, we need to avoid blockers from other projects and in
> this case, it's not directly related to Karaf / R7.
>
> May be we could propose multiple alternative to the users to choose
> their implementation of the http service and just provide a lightweight
> impl by default.
>
> regards,
>
> François
> fpapon@apache.org
>
> Le 07/07/2020 à 11:27, Jean-Baptiste Onofre a écrit :
> > Hi,
> >
> > See my comment inline
> >
> >> Le 7 juil. 2020 à 11:22, Romain Manni-Bucau <rm...@gmail.com> a
> écrit :
> >>
> >> Hi JB,
> >>
> >> I see more issues using felix http:
> >>
> >> 1. it only supports felix today AFAIK which directly impacts the
> production
> >> since then your monitoring/observability/instrumentation can be to redo
> so
> >> for me it is way more impacting than the dev side - and more vicious
> > Good point, we can have impact with Equinox, true.
> >
> >> 2. felix is a fatjar so you can't upgrade jetty when needed which is
> also a
> >> big loss compared to not having R7 IMHO
> > That’s a discussion standpoint. Having a fat jar can be seen as a good
> point as upgrading Jetty (or Tomcat, or undertow) is not always (never ;))
> "smooth" at Pax Web.
> >
> >> How far is paxweb from R7? Not being 100% compliant is fine IMO while:
> >> a. it can be manually switched to a compliant impl if required
> >> b. there is no regression from previous version
> >>
> > I think we are pretty close just for R7, but we also started a large
> refactoring (maybe it was too "ambitious").
> > So, another approach would by to start from Pax Web 7.2.x and just
> update the minimal set to R7 (new HTTP service).
> >
> > Regards
> > JB
> >
> >> Indeed just my 2cts,
> >> Romain Manni-Bucau
> >> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >> <https://rmannibucau.metawerx.net/> | Old Blog
> >> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> >> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> >> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >>
> >>
> >> Le mar. 7 juil. 2020 à 11:18, Jean-Baptiste Onofre <jb...@nanthrax.net> a
> >> écrit :
> >>
> >>> Hi everyone,
> >>>
> >>> It’s more than a year now that we started Apache Karaf 4.3.0 release
> >>> process, fully supporting OSGi R7.
> >>>
> >>> If the 4.3.0 distribution is ready, we are blocked by Pax Web. I’m
> >>> concerned about that as R8 will be there and we will have issue in Pax
> Web
> >>> again.
> >>>
> >>> Greg started a huge effort heading to Pax Web 8.0.0 with a large
> >>> refactoring.
> >>> However, the process is long and painful.
> >>> So, I think it’s fair to have a discussion about the HTTP service in
> Karaf
> >>> and "relationship" with Pax Web.
> >>>
> >>> I see three options for Karaf 4.3.0:
> >>>
> >>> 1. We are able to release Pax Web 8.0.0 (with R7 support) and so, no
> >>> brainer, we can move forward.
> >>> 2. Instead of using Pax Web by default, we "switch" to Felix HTTP by
> >>> default. For the "pure" HTTP service, it will be transparent but it
> would
> >>> have two impacts:
> >>>  * the configuration changes (as obviously etc/org.ops4j.pax.web.cfg
> >>> doesn’t exist anymore)
> >>>  * users using WebContainer PaxWeb API instead of HTTP service won’t
> work
> >>> 3. We consider that Pax Web as it is today is not flexible enough and
> too
> >>> painful, and we start an even larger refactoring on Pax Web.
> >>>
> >>> The reason why I’m bringing this discussion on the mailing list: we
> really
> >>> need a clear plan and release 4.3.0 (I would really love to release
> 4.3.0
> >>> mid July max, so we need a plan).
> >>>
> >>> Thoughts ?
> >>>
> >>> Regards
> >>> JB
>
>

Re: [DISCUSSION] Apache Karaf 4.3.0 and Pax Web

Posted by Francois Papon <fr...@openobject.fr>.

Hi,

I think the most important thing is to be more flexible for the releases
roadmap of Karaf.

If it's possible, we need to avoid blockers from other projects and in
this case, it's not directly related to Karaf / R7.

May be we could propose multiple alternative to the users to choose
their implementation of the http service and just provide a lightweight
impl by default.

regards,

François
fpapon@apache.org

Le 07/07/2020 à 11:27, Jean-Baptiste Onofre a écrit :
> Hi,
>
> See my comment inline
>
>> Le 7 juil. 2020 à 11:22, Romain Manni-Bucau <rm...@gmail.com> a écrit :
>>
>> Hi JB,
>>
>> I see more issues using felix http:
>>
>> 1. it only supports felix today AFAIK which directly impacts the production
>> since then your monitoring/observability/instrumentation can be to redo so
>> for me it is way more impacting than the dev side - and more vicious
> Good point, we can have impact with Equinox, true.
>
>> 2. felix is a fatjar so you can't upgrade jetty when needed which is also a
>> big loss compared to not having R7 IMHO
> That’s a discussion standpoint. Having a fat jar can be seen as a good point as upgrading Jetty (or Tomcat, or undertow) is not always (never ;)) "smooth" at Pax Web.
>
>> How far is paxweb from R7? Not being 100% compliant is fine IMO while:
>> a. it can be manually switched to a compliant impl if required
>> b. there is no regression from previous version
>>
> I think we are pretty close just for R7, but we also started a large refactoring (maybe it was too "ambitious").
> So, another approach would by to start from Pax Web 7.2.x and just update the minimal set to R7 (new HTTP service).
>
> Regards
> JB
>
>> Indeed just my 2cts,
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <https://rmannibucau.metawerx.net/> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>>
>>
>> Le mar. 7 juil. 2020 à 11:18, Jean-Baptiste Onofre <jb...@nanthrax.net> a
>> écrit :
>>
>>> Hi everyone,
>>>
>>> It’s more than a year now that we started Apache Karaf 4.3.0 release
>>> process, fully supporting OSGi R7.
>>>
>>> If the 4.3.0 distribution is ready, we are blocked by Pax Web. I’m
>>> concerned about that as R8 will be there and we will have issue in Pax Web
>>> again.
>>>
>>> Greg started a huge effort heading to Pax Web 8.0.0 with a large
>>> refactoring.
>>> However, the process is long and painful.
>>> So, I think it’s fair to have a discussion about the HTTP service in Karaf
>>> and "relationship" with Pax Web.
>>>
>>> I see three options for Karaf 4.3.0:
>>>
>>> 1. We are able to release Pax Web 8.0.0 (with R7 support) and so, no
>>> brainer, we can move forward.
>>> 2. Instead of using Pax Web by default, we "switch" to Felix HTTP by
>>> default. For the "pure" HTTP service, it will be transparent but it would
>>> have two impacts:
>>>  * the configuration changes (as obviously etc/org.ops4j.pax.web.cfg
>>> doesn’t exist anymore)
>>>  * users using WebContainer PaxWeb API instead of HTTP service won’t work
>>> 3. We consider that Pax Web as it is today is not flexible enough and too
>>> painful, and we start an even larger refactoring on Pax Web.
>>>
>>> The reason why I’m bringing this discussion on the mailing list: we really
>>> need a clear plan and release 4.3.0 (I would really love to release 4.3.0
>>> mid July max, so we need a plan).
>>>
>>> Thoughts ?
>>>
>>> Regards
>>> JB

Re: [DISCUSSION] Apache Karaf 4.3.0 and Pax Web

Posted by Grzegorz Grzybek <gr...@gmail.com>.

Hello

wt., 7 lip 2020 o 13:30 Serge Huber <sh...@jahia.com> napisał(a):

> Hi guys,
>
> Interesting discussion. I'd love to see Karaf 4.3 asap.
>
> As (mostly) a user of Pax Web, I'm wondering if just focusing on Jetty
> instead of supporting both Jetty & Tomcat could make things faster and
> maybe easier to integration test? I'm sure there are use cases for Tomcat
> that I'm not aware of but I'm wondering what they are?
>

To be honest - supporting 3 instead of 1 container was always an advantage
of Pax Web. Fortunately the maintenance cost doesn't rise by 200% :) And
for example I personally use Karaf with Undertow.


>
> As a Karaf user, my biggest need is for a "global" interception mechanism
> on the HTTP service to be able to build filters for security, CSRF, etc...
> which are things that Pax Web doesn't support right now.
>

Global interception mechanism are supposed to be supported by
"preprocessors" from Whiteboard R7 (per context), for Pax Web I've
implemented a mechanism that allows this - see:
https://ops4j1.jira.com/wiki/spaces/paxweb/pages/354025473/HTTP+Context+processing

regards
Grzegorz Grzybek


>
> Regards,
>   Serge...
>
> Serge Huber
> CTO & Co-Founder
> T +41 22 361 3424
> 9 route des Jeunes | 1227 Acacias | Switzerland
> jahia.com <http://www.jahia.com/>
> SKYPE | LINKEDIN <https://www.linkedin.com/in/sergehuber> | TWITTER
> <https://twitter.com/sergehuber> | VCARD
> <http://www.jahia.com/vcard/HuberSerge.vcf>
>
>
> > JOIN OUR COMMUNITY <http://www.jahia.com/> to evaluate, get trained and
> to discover why Jahia is a leading User Experience Platform (UXP) for
> Digital Transformation.
>
>
> On Tue, Jul 7, 2020 at 12:23 PM Grzegorz Grzybek <gr...@gmail.com>
> wrote:
>
> > Hello
> >
> > The problem with Pax-Web 8 and R7 compatibility is mostly related to ...
> > Pax-Web 7 (and 6) not being R6 compatible at all...
> >
> > Indeed - the refactoring was very ambitious - 1st, I didn't want to get
> rid
> > of all the huge work and design of Pax Web, 2nd, I though it'll be
> > comparable to my previous Pax Logging refactoring (where among others
> I've
> > increased number of real integration tests from 0 to 100+).
> >
> > I'm working now on "resource and welcome file handling" - and while
> > "welcome files" are not covered at all in Whiteboard/HttpService specs,
> Pax
> > Web is known to support them - so not having them would be a regression.
> >
> > I hope to have working resources/welcome files implementation this week -
> > just check the related test size to see what I'm talking about:
> >
> >
> https://github.com/ops4j/org.ops4j.pax.web/blob/master-improvements/pax-web-jetty/src/test/java/org/ops4j/pax/web/service/jetty/internal/UnifiedJettyTest.java#L360-L663
> > (with similar tests for Tomcat and Undertow).
> >
> > After resources/welcome-files, the big remaining thing is
> > pax-web-extender-war, however the refactoring will be minimal, because
> the
> > biggest changes were related to model (pax-web-spi), pax-web-runtime and
> > whiteboard trackers.
> >
> > For now, master-improvements branch is in a state where chance for merge
> > conflict is minimal (for some time initially I did really huge changes,
> > removals and moves of the files/packages).
> >
> > Also, the most important integration tests are now in the process of
> moving
> > (in other words - those that are moved, work).
> >
> > During my work I have also created some serious issues like:
> >  - https://github.com/eclipse-ee4j/servlet-api/issues/300
> >  - https://github.com/eclipse/jetty.project/pull/5025
> >
> > I'm aware that R8 is coming, but when we have working R7 implementation
> (or
> > rather R6 implementation in the first place), it'd be a matter of ~2
> weeks
> > to implement R8 on top of working R7.
> >
> > So, thanks for patience, sorry for delay and please help if you like ;)
> >
> > regards
> > Grzegorz Grzybek
> >
> > wt., 7 lip 2020 o 11:27 Jean-Baptiste Onofre <jb...@nanthrax.net>
> napisał(a):
> >
> > > Hi,
> > >
> > > See my comment inline
> > >
> > > > Le 7 juil. 2020 à 11:22, Romain Manni-Bucau <rm...@gmail.com>
> a
> > > écrit :
> > > >
> > > > Hi JB,
> > > >
> > > > I see more issues using felix http:
> > > >
> > > > 1. it only supports felix today AFAIK which directly impacts the
> > > production
> > > > since then your monitoring/observability/instrumentation can be to
> redo
> > > so
> > > > for me it is way more impacting than the dev side - and more vicious
> > >
> > > Good point, we can have impact with Equinox, true.
> > >
> > > > 2. felix is a fatjar so you can't upgrade jetty when needed which is
> > > also a
> > > > big loss compared to not having R7 IMHO
> > >
> > > That’s a discussion standpoint. Having a fat jar can be seen as a good
> > > point as upgrading Jetty (or Tomcat, or undertow) is not always (never
> > ;))
> > > "smooth" at Pax Web.
> > >
> > > >
> > > > How far is paxweb from R7? Not being 100% compliant is fine IMO
> while:
> > > > a. it can be manually switched to a compliant impl if required
> > > > b. there is no regression from previous version
> > > >
> > >
> > > I think we are pretty close just for R7, but we also started a large
> > > refactoring (maybe it was too "ambitious").
> > > So, another approach would by to start from Pax Web 7.2.x and just
> update
> > > the minimal set to R7 (new HTTP service).
> > >
> > > Regards
> > > JB
> > >
> > > > Indeed just my 2cts,
> > > > Romain Manni-Bucau
> > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > > >
> > > >
> > > > Le mar. 7 juil. 2020 à 11:18, Jean-Baptiste Onofre <jb...@nanthrax.net>
> a
> > > > écrit :
> > > >
> > > >> Hi everyone,
> > > >>
> > > >> It’s more than a year now that we started Apache Karaf 4.3.0 release
> > > >> process, fully supporting OSGi R7.
> > > >>
> > > >> If the 4.3.0 distribution is ready, we are blocked by Pax Web. I’m
> > > >> concerned about that as R8 will be there and we will have issue in
> Pax
> > > Web
> > > >> again.
> > > >>
> > > >> Greg started a huge effort heading to Pax Web 8.0.0 with a large
> > > >> refactoring.
> > > >> However, the process is long and painful.
> > > >> So, I think it’s fair to have a discussion about the HTTP service in
> > > Karaf
> > > >> and "relationship" with Pax Web.
> > > >>
> > > >> I see three options for Karaf 4.3.0:
> > > >>
> > > >> 1. We are able to release Pax Web 8.0.0 (with R7 support) and so, no
> > > >> brainer, we can move forward.
> > > >> 2. Instead of using Pax Web by default, we "switch" to Felix HTTP by
> > > >> default. For the "pure" HTTP service, it will be transparent but it
> > > would
> > > >> have two impacts:
> > > >>  * the configuration changes (as obviously etc/org.ops4j.pax.web.cfg
> > > >> doesn’t exist anymore)
> > > >>  * users using WebContainer PaxWeb API instead of HTTP service won’t
> > > work
> > > >> 3. We consider that Pax Web as it is today is not flexible enough
> and
> > > too
> > > >> painful, and we start an even larger refactoring on Pax Web.
> > > >>
> > > >> The reason why I’m bringing this discussion on the mailing list: we
> > > really
> > > >> need a clear plan and release 4.3.0 (I would really love to release
> > > 4.3.0
> > > >> mid July max, so we need a plan).
> > > >>
> > > >> Thoughts ?
> > > >>
> > > >> Regards
> > > >> JB
> > >
> > >
> >
>

Re: [DISCUSSION] Apache Karaf 4.3.0 and Pax Web

Posted by Serge Huber <sh...@jahia.com>.

Hi guys,

Interesting discussion. I'd love to see Karaf 4.3 asap.

As (mostly) a user of Pax Web, I'm wondering if just focusing on Jetty
instead of supporting both Jetty & Tomcat could make things faster and
maybe easier to integration test? I'm sure there are use cases for Tomcat
that I'm not aware of but I'm wondering what they are?

As a Karaf user, my biggest need is for a "global" interception mechanism
on the HTTP service to be able to build filters for security, CSRF, etc...
which are things that Pax Web doesn't support right now.

Regards,
  Serge...

Serge Huber
CTO & Co-Founder
T +41 22 361 3424
9 route des Jeunes | 1227 Acacias | Switzerland
jahia.com <http://www.jahia.com/>
SKYPE | LINKEDIN <https://www.linkedin.com/in/sergehuber> | TWITTER
<https://twitter.com/sergehuber> | VCARD
<http://www.jahia.com/vcard/HuberSerge.vcf>


> JOIN OUR COMMUNITY <http://www.jahia.com/> to evaluate, get trained and
to discover why Jahia is a leading User Experience Platform (UXP) for
Digital Transformation.


On Tue, Jul 7, 2020 at 12:23 PM Grzegorz Grzybek <gr...@gmail.com>
wrote:

> Hello
>
> The problem with Pax-Web 8 and R7 compatibility is mostly related to ...
> Pax-Web 7 (and 6) not being R6 compatible at all...
>
> Indeed - the refactoring was very ambitious - 1st, I didn't want to get rid
> of all the huge work and design of Pax Web, 2nd, I though it'll be
> comparable to my previous Pax Logging refactoring (where among others I've
> increased number of real integration tests from 0 to 100+).
>
> I'm working now on "resource and welcome file handling" - and while
> "welcome files" are not covered at all in Whiteboard/HttpService specs, Pax
> Web is known to support them - so not having them would be a regression.
>
> I hope to have working resources/welcome files implementation this week -
> just check the related test size to see what I'm talking about:
>
> https://github.com/ops4j/org.ops4j.pax.web/blob/master-improvements/pax-web-jetty/src/test/java/org/ops4j/pax/web/service/jetty/internal/UnifiedJettyTest.java#L360-L663
> (with similar tests for Tomcat and Undertow).
>
> After resources/welcome-files, the big remaining thing is
> pax-web-extender-war, however the refactoring will be minimal, because the
> biggest changes were related to model (pax-web-spi), pax-web-runtime and
> whiteboard trackers.
>
> For now, master-improvements branch is in a state where chance for merge
> conflict is minimal (for some time initially I did really huge changes,
> removals and moves of the files/packages).
>
> Also, the most important integration tests are now in the process of moving
> (in other words - those that are moved, work).
>
> During my work I have also created some serious issues like:
>  - https://github.com/eclipse-ee4j/servlet-api/issues/300
>  - https://github.com/eclipse/jetty.project/pull/5025
>
> I'm aware that R8 is coming, but when we have working R7 implementation (or
> rather R6 implementation in the first place), it'd be a matter of ~2 weeks
> to implement R8 on top of working R7.
>
> So, thanks for patience, sorry for delay and please help if you like ;)
>
> regards
> Grzegorz Grzybek
>
> wt., 7 lip 2020 o 11:27 Jean-Baptiste Onofre <jb...@nanthrax.net> napisał(a):
>
> > Hi,
> >
> > See my comment inline
> >
> > > Le 7 juil. 2020 à 11:22, Romain Manni-Bucau <rm...@gmail.com> a
> > écrit :
> > >
> > > Hi JB,
> > >
> > > I see more issues using felix http:
> > >
> > > 1. it only supports felix today AFAIK which directly impacts the
> > production
> > > since then your monitoring/observability/instrumentation can be to redo
> > so
> > > for me it is way more impacting than the dev side - and more vicious
> >
> > Good point, we can have impact with Equinox, true.
> >
> > > 2. felix is a fatjar so you can't upgrade jetty when needed which is
> > also a
> > > big loss compared to not having R7 IMHO
> >
> > That’s a discussion standpoint. Having a fat jar can be seen as a good
> > point as upgrading Jetty (or Tomcat, or undertow) is not always (never
> ;))
> > "smooth" at Pax Web.
> >
> > >
> > > How far is paxweb from R7? Not being 100% compliant is fine IMO while:
> > > a. it can be manually switched to a compliant impl if required
> > > b. there is no regression from previous version
> > >
> >
> > I think we are pretty close just for R7, but we also started a large
> > refactoring (maybe it was too "ambitious").
> > So, another approach would by to start from Pax Web 7.2.x and just update
> > the minimal set to R7 (new HTTP service).
> >
> > Regards
> > JB
> >
> > > Indeed just my 2cts,
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> > >
> > >
> > > Le mar. 7 juil. 2020 à 11:18, Jean-Baptiste Onofre <jb...@nanthrax.net> a
> > > écrit :
> > >
> > >> Hi everyone,
> > >>
> > >> It’s more than a year now that we started Apache Karaf 4.3.0 release
> > >> process, fully supporting OSGi R7.
> > >>
> > >> If the 4.3.0 distribution is ready, we are blocked by Pax Web. I’m
> > >> concerned about that as R8 will be there and we will have issue in Pax
> > Web
> > >> again.
> > >>
> > >> Greg started a huge effort heading to Pax Web 8.0.0 with a large
> > >> refactoring.
> > >> However, the process is long and painful.
> > >> So, I think it’s fair to have a discussion about the HTTP service in
> > Karaf
> > >> and "relationship" with Pax Web.
> > >>
> > >> I see three options for Karaf 4.3.0:
> > >>
> > >> 1. We are able to release Pax Web 8.0.0 (with R7 support) and so, no
> > >> brainer, we can move forward.
> > >> 2. Instead of using Pax Web by default, we "switch" to Felix HTTP by
> > >> default. For the "pure" HTTP service, it will be transparent but it
> > would
> > >> have two impacts:
> > >>  * the configuration changes (as obviously etc/org.ops4j.pax.web.cfg
> > >> doesn’t exist anymore)
> > >>  * users using WebContainer PaxWeb API instead of HTTP service won’t
> > work
> > >> 3. We consider that Pax Web as it is today is not flexible enough and
> > too
> > >> painful, and we start an even larger refactoring on Pax Web.
> > >>
> > >> The reason why I’m bringing this discussion on the mailing list: we
> > really
> > >> need a clear plan and release 4.3.0 (I would really love to release
> > 4.3.0
> > >> mid July max, so we need a plan).
> > >>
> > >> Thoughts ?
> > >>
> > >> Regards
> > >> JB
> >
> >
>

Re: [DISCUSSION] Apache Karaf 4.3.0 and Pax Web

Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.

Thanks a lot Greg for this great improvement !

I’m updating my local copy to test deeper.

I can take some points you mentioned, heading to a release next week ;)

Thanks again,
Regards
JB

> Le 7 juil. 2020 à 16:33, Grzegorz Grzybek <gr...@gmail.com> a écrit :
> 
> Hello
> 
> I'm proud to announce that I've pushed master-improvement changes where you
> can simply call `mvn clean install` AND `mvn clean install -Pequinox`.
> 
> Check for example pax-web-itest-undertow tests (see the times!)
> 
> [INFO] -------------------------------------------------------
> [INFO]  T E S T S
> [INFO] -------------------------------------------------------
> [INFO] Running
> org.ops4j.pax.web.itest.undertow.httpservice.AsyncServletIntegrationTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 3.458 s - in
> org.ops4j.pax.web.itest.undertow.httpservice.AsyncServletIntegrationTest
> [INFO] Running
> org.ops4j.pax.web.itest.undertow.httpservice.AuthenticationIntegrationTest
> [INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 2.524 s - in
> org.ops4j.pax.web.itest.undertow.httpservice.AuthenticationIntegrationTest
> [INFO] Running
> org.ops4j.pax.web.itest.undertow.httpservice.HttpCustomContextIntegrationTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 2.747 s - in
> org.ops4j.pax.web.itest.undertow.httpservice.HttpCustomContextIntegrationTest
> [INFO] Running
> org.ops4j.pax.web.itest.undertow.httpservice.HttpServiceBundleIntegrationTest
> [INFO] Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 2.956 s - in
> org.ops4j.pax.web.itest.undertow.httpservice.HttpServiceBundleIntegrationTest
> [INFO] Running
> org.ops4j.pax.web.itest.undertow.httpservice.HttpServiceIntegrationTest
> [INFO] Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 2.891 s - in
> org.ops4j.pax.web.itest.undertow.httpservice.HttpServiceIntegrationTest
> [INFO] Running
> org.ops4j.pax.web.itest.undertow.httpservice.HttpServiceWithConfigAdminIntegrationTest
> [INFO] Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 3.346 s - in
> org.ops4j.pax.web.itest.undertow.httpservice.HttpServiceWithConfigAdminIntegrationTest
> [INFO] Running
> org.ops4j.pax.web.itest.undertow.httpservice.HttpServiceWithoutCMIntegrationTest
> [INFO] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 2.832 s - in
> org.ops4j.pax.web.itest.undertow.httpservice.HttpServiceWithoutCMIntegrationTest
> 
> These are not all previous tests, but I'm moving them one at a time from
> pax-web-itest-container-xxx to pax-web-itest-xxx (so I know what works and
> what doesn't).
> 
> With this push, I think I've covered a huge amount of missing unification
> related to welcome file handling. Please feel free to play with the current
> state of the branch. In the coming days, I'm going to add a cherry on top
> of welcome file handling by adding a whiteboard layer to it.
> 
> Whiteboard layer is all about tracking "incoming" services and turning them
> into "models" (customization) - I've removed the intermediary layer of "web
> elements" present in Pax Web 7.
> 
> Kudoz to Achim and other Pax Web developers who created Pax Web Extender
> Whiteboard before CMPN Whiteboard was crafted (and IT was inspired by Pax
> Web, not vice versa!)
> 
> The biggest problem I was thinking of when saying "Pax Web 7 was not R6
> Whiteboard compliant) is this OSGi filter:
> 
> (osgi.http.whiteboard.servlet.name=*)
> 
> stored in "osgi.http.whiteboard.context.select" service registration
> property. Supporting it required deep refactoring, but I think it's already
> done.
> 
> Welcome file (and resource) handling in Pax Web 8 is changed, so it also
> leverages as much as possible from:
> - org.apache.catalina.servlets.DefaultServlet
> - io.undertow.servlet.handlers.DefaultServlet
> - org.eclipse.jetty.servlet.DefaultServlet
> 
> So we have now (for free!) caching, etags and Accept-Ranges support.
> 
> Handling URLs from HttpContext/ServletContextHelper.getResource() like
> "bundle://22.0:1/" (Felix), bypassing
> https://issues.apache.org/jira/browse/FELIX-6294, handling "bundle
> directories", welcome files from file:/bundle:/bundleresource: URIs now
> works consistently across runtimes.
> 
> Here's rough plan for coming weeks:
> - whiteboard layer for implemented resources/welcome files (2 days max)
> - error page handling for implemented servlet registration (1 day max)
> - pax-web-extender-war - I wanted to implement transactional web.xml
> registration (begin() + end()) and it requires little design, but the "one
> configuration thread" is created with this transactional approach in mind
> - JSF resource lookup - I've spend lot of time to check all possible
> resource fetching methods (bundle resources/entries, classloaders,
> fragments, wirings, ...), so it's a matter of test migration and checking
> where do we want "BundleResourceClassLoader"
> - per-context session handling (felix.http has this), but I don't think we
> need it for GA (per context attribute storage works already!)
> - registration of ServletContainerInitializers and login configs - I
> didn't look into it yet, but that fits perfectly into what we already have
> - JSPs - lot of initial work (last year!) was done to handle JSPs better
> (without duplicating/shading/private-packaging Jasper classes) - I already
> have pax-web-itest-jsp project with exotic things like custom tag files
> tests. pax-web-tomcat-common bundle was created to support pax-web-jsp with
> better OSGi manifest. Also, JSP servlet with current servlet
> (un)registration handling should not be a problem
> 
> I really devote much of my daily job (and free time ;) for this, but I'm
> 100% sure, that we're almost there - at least I don't expect bigger issues
> (which wasn't true when I started the refactoring)
> 
> kind regards
> Grzegorz Grzybek
> 
> wt., 7 lip 2020 o 16:11 Achim Nierbeck <bc...@googlemail.com.invalid>
> napisał(a):
> 
>> Hi,
>> 
>> as being responsible for supporting more then one container for Pax-Web
>> it's been unclear at the time if Jetty would always be the best idea.
>> (which you now can see regarding the latest Servlet spec)
>> That's why I added Tomcat and Guillaume added Undertow later on.
>> So much for the Why multiple underlying containers.
>> 
>> Now regarding R6 compatibility:
>> Pax Web does support a Whiteboard Approach since it's earliest stages: 0.6.
>> It's been improved all those years from 1.0 till 4.x to match what was
>> capable with the web-container approach.
>> Then the Felix HTTP project created a "new" reference for the Whiteboard
>> Specification (aka R6).
>> When trying to adapt to it, it's always been a trade off between sticking
>> to the already known implementation to the community and aligning with R6.
>> That's why it's never been really R6 compliant, only close to.
>> 
>> I know what a tremendous workload it is to refactor the whole stack to be
>> R6 compliant.
>> So big Kudos to Greg for taking this :)
>> 
>> Unfortunately my dayjob has been consuming too much of my time to be of any
>> help, and when I tried to help out a bit I realised the refactored version
>> isn't what I was remembering.
>> So I have to admit ... I won't be much of a help on the project anymore :(
>> 
>> If you would ask me where to take a shortcut, I'd say, sorry no way.
>> If we want it to be R6/7/8 compliant we'll need to go through that valley
>> of tears to get to it.
>> I just hope there are more people able to help Greg to get there.
>> 
>> regards, Achim
>> 
>> P.S. it really saddens me of not being able to help on this, anymore :(
>> 
>> Am Di., 7. Juli 2020 um 14:17 Uhr schrieb Jean-Baptiste Onofre <
>> jb@nanthrax.net>:
>> 
>>> Hi,
>>> 
>>> I will help you. The purpose is to have a viable ETA for Pax Web 8.0 (for
>>> Karaf 4.3).
>>> 
>>> Do you think reasonable to target end of next week fo Pax Web 8.0.0 (even
>>> if all is not completed/fixed) if we work together ?
>>> 
>>> That would be great.
>>> 
>>> Regards
>>> JB
>>> 
>>>> Le 7 juil. 2020 à 12:23, Grzegorz Grzybek <gr...@gmail.com> a
>>> écrit :
>>>> 
>>>> Hello
>>>> 
>>>> The problem with Pax-Web 8 and R7 compatibility is mostly related to
>> ...
>>>> Pax-Web 7 (and 6) not being R6 compatible at all...
>>>> 
>>>> Indeed - the refactoring was very ambitious - 1st, I didn't want to get
>>> rid
>>>> of all the huge work and design of Pax Web, 2nd, I though it'll be
>>>> comparable to my previous Pax Logging refactoring (where among others
>>> I've
>>>> increased number of real integration tests from 0 to 100+).
>>>> 
>>>> I'm working now on "resource and welcome file handling" - and while
>>>> "welcome files" are not covered at all in Whiteboard/HttpService specs,
>>> Pax
>>>> Web is known to support them - so not having them would be a
>> regression.
>>>> 
>>>> I hope to have working resources/welcome files implementation this
>> week -
>>>> just check the related test size to see what I'm talking about:
>>>> 
>>> 
>> https://github.com/ops4j/org.ops4j.pax.web/blob/master-improvements/pax-web-jetty/src/test/java/org/ops4j/pax/web/service/jetty/internal/UnifiedJettyTest.java#L360-L663
>>>> (with similar tests for Tomcat and Undertow).
>>>> 
>>>> After resources/welcome-files, the big remaining thing is
>>>> pax-web-extender-war, however the refactoring will be minimal, because
>>> the
>>>> biggest changes were related to model (pax-web-spi), pax-web-runtime
>> and
>>>> whiteboard trackers.
>>>> 
>>>> For now, master-improvements branch is in a state where chance for
>> merge
>>>> conflict is minimal (for some time initially I did really huge changes,
>>>> removals and moves of the files/packages).
>>>> 
>>>> Also, the most important integration tests are now in the process of
>>> moving
>>>> (in other words - those that are moved, work).
>>>> 
>>>> During my work I have also created some serious issues like:
>>>> - https://github.com/eclipse-ee4j/servlet-api/issues/300
>>>> - https://github.com/eclipse/jetty.project/pull/5025
>>>> 
>>>> I'm aware that R8 is coming, but when we have working R7 implementation
>>> (or
>>>> rather R6 implementation in the first place), it'd be a matter of ~2
>>> weeks
>>>> to implement R8 on top of working R7.
>>>> 
>>>> So, thanks for patience, sorry for delay and please help if you like ;)
>>>> 
>>>> regards
>>>> Grzegorz Grzybek
>>>> 
>>>> wt., 7 lip 2020 o 11:27 Jean-Baptiste Onofre <jb...@nanthrax.net>
>>> napisał(a):
>>>> 
>>>>> Hi,
>>>>> 
>>>>> See my comment inline
>>>>> 
>>>>>> Le 7 juil. 2020 à 11:22, Romain Manni-Bucau <rm...@gmail.com>
>> a
>>>>> écrit :
>>>>>> 
>>>>>> Hi JB,
>>>>>> 
>>>>>> I see more issues using felix http:
>>>>>> 
>>>>>> 1. it only supports felix today AFAIK which directly impacts the
>>>>> production
>>>>>> since then your monitoring/observability/instrumentation can be to
>> redo
>>>>> so
>>>>>> for me it is way more impacting than the dev side - and more vicious
>>>>> 
>>>>> Good point, we can have impact with Equinox, true.
>>>>> 
>>>>>> 2. felix is a fatjar so you can't upgrade jetty when needed which is
>>>>> also a
>>>>>> big loss compared to not having R7 IMHO
>>>>> 
>>>>> That’s a discussion standpoint. Having a fat jar can be seen as a good
>>>>> point as upgrading Jetty (or Tomcat, or undertow) is not always (never
>>> ;))
>>>>> "smooth" at Pax Web.
>>>>> 
>>>>>> 
>>>>>> How far is paxweb from R7? Not being 100% compliant is fine IMO
>> while:
>>>>>> a. it can be manually switched to a compliant impl if required
>>>>>> b. there is no regression from previous version
>>>>>> 
>>>>> 
>>>>> I think we are pretty close just for R7, but we also started a large
>>>>> refactoring (maybe it was too "ambitious").
>>>>> So, another approach would by to start from Pax Web 7.2.x and just
>>> update
>>>>> the minimal set to R7 (new HTTP service).
>>>>> 
>>>>> Regards
>>>>> JB
>>>>> 
>>>>>> Indeed just my 2cts,
>>>>>> Romain Manni-Bucau
>>>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>>>>> <https://rmannibucau.metawerx.net/> | Old Blog
>>>>>> <http://rmannibucau.wordpress.com> | Github <
>>>>> https://github.com/rmannibucau> |
>>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>>>>>> <
>>>>> 
>>> 
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Le mar. 7 juil. 2020 à 11:18, Jean-Baptiste Onofre <jb...@nanthrax.net>
>> a
>>>>>> écrit :
>>>>>> 
>>>>>>> Hi everyone,
>>>>>>> 
>>>>>>> It’s more than a year now that we started Apache Karaf 4.3.0 release
>>>>>>> process, fully supporting OSGi R7.
>>>>>>> 
>>>>>>> If the 4.3.0 distribution is ready, we are blocked by Pax Web. I’m
>>>>>>> concerned about that as R8 will be there and we will have issue in
>> Pax
>>>>> Web
>>>>>>> again.
>>>>>>> 
>>>>>>> Greg started a huge effort heading to Pax Web 8.0.0 with a large
>>>>>>> refactoring.
>>>>>>> However, the process is long and painful.
>>>>>>> So, I think it’s fair to have a discussion about the HTTP service in
>>>>> Karaf
>>>>>>> and "relationship" with Pax Web.
>>>>>>> 
>>>>>>> I see three options for Karaf 4.3.0:
>>>>>>> 
>>>>>>> 1. We are able to release Pax Web 8.0.0 (with R7 support) and so, no
>>>>>>> brainer, we can move forward.
>>>>>>> 2. Instead of using Pax Web by default, we "switch" to Felix HTTP by
>>>>>>> default. For the "pure" HTTP service, it will be transparent but it
>>>>> would
>>>>>>> have two impacts:
>>>>>>> * the configuration changes (as obviously etc/org.ops4j.pax.web.cfg
>>>>>>> doesn’t exist anymore)
>>>>>>> * users using WebContainer PaxWeb API instead of HTTP service won’t
>>>>> work
>>>>>>> 3. We consider that Pax Web as it is today is not flexible enough
>> and
>>>>> too
>>>>>>> painful, and we start an even larger refactoring on Pax Web.
>>>>>>> 
>>>>>>> The reason why I’m bringing this discussion on the mailing list: we
>>>>> really
>>>>>>> need a clear plan and release 4.3.0 (I would really love to release
>>>>> 4.3.0
>>>>>>> mid July max, so we need a plan).
>>>>>>> 
>>>>>>> Thoughts ?
>>>>>>> 
>>>>>>> Regards
>>>>>>> JB
>>>>> 
>>>>> 
>>> 
>>> 
>> 
>> --
>> 
>> Apache Member
>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
>> Project Lead
>> blog <http://notizblog.nierbeck.de/>
>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>

Re: [DISCUSSION] Apache Karaf 4.3.0 and Pax Web

Posted by Francois Papon <fr...@openobject.fr>.

Thanks very much Grzegorz for all the great work on pax-web!

regards,

François
fpapon@apache.org

Le 07/07/2020 à 16:33, Grzegorz Grzybek a écrit :
> Hello
>
> I'm proud to announce that I've pushed master-improvement changes where you
> can simply call `mvn clean install` AND `mvn clean install -Pequinox`.
>
> Check for example pax-web-itest-undertow tests (see the times!)
>
> [INFO] -------------------------------------------------------
> [INFO]  T E S T S
> [INFO] -------------------------------------------------------
> [INFO] Running
> org.ops4j.pax.web.itest.undertow.httpservice.AsyncServletIntegrationTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 3.458 s - in
> org.ops4j.pax.web.itest.undertow.httpservice.AsyncServletIntegrationTest
> [INFO] Running
> org.ops4j.pax.web.itest.undertow.httpservice.AuthenticationIntegrationTest
> [INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 2.524 s - in
> org.ops4j.pax.web.itest.undertow.httpservice.AuthenticationIntegrationTest
> [INFO] Running
> org.ops4j.pax.web.itest.undertow.httpservice.HttpCustomContextIntegrationTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 2.747 s - in
> org.ops4j.pax.web.itest.undertow.httpservice.HttpCustomContextIntegrationTest
> [INFO] Running
> org.ops4j.pax.web.itest.undertow.httpservice.HttpServiceBundleIntegrationTest
> [INFO] Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 2.956 s - in
> org.ops4j.pax.web.itest.undertow.httpservice.HttpServiceBundleIntegrationTest
> [INFO] Running
> org.ops4j.pax.web.itest.undertow.httpservice.HttpServiceIntegrationTest
> [INFO] Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 2.891 s - in
> org.ops4j.pax.web.itest.undertow.httpservice.HttpServiceIntegrationTest
> [INFO] Running
> org.ops4j.pax.web.itest.undertow.httpservice.HttpServiceWithConfigAdminIntegrationTest
> [INFO] Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 3.346 s - in
> org.ops4j.pax.web.itest.undertow.httpservice.HttpServiceWithConfigAdminIntegrationTest
> [INFO] Running
> org.ops4j.pax.web.itest.undertow.httpservice.HttpServiceWithoutCMIntegrationTest
> [INFO] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 2.832 s - in
> org.ops4j.pax.web.itest.undertow.httpservice.HttpServiceWithoutCMIntegrationTest
>
> These are not all previous tests, but I'm moving them one at a time from
> pax-web-itest-container-xxx to pax-web-itest-xxx (so I know what works and
> what doesn't).
>
> With this push, I think I've covered a huge amount of missing unification
> related to welcome file handling. Please feel free to play with the current
> state of the branch. In the coming days, I'm going to add a cherry on top
> of welcome file handling by adding a whiteboard layer to it.
>
> Whiteboard layer is all about tracking "incoming" services and turning them
> into "models" (customization) - I've removed the intermediary layer of "web
> elements" present in Pax Web 7.
>
> Kudoz to Achim and other Pax Web developers who created Pax Web Extender
> Whiteboard before CMPN Whiteboard was crafted (and IT was inspired by Pax
> Web, not vice versa!)
>
> The biggest problem I was thinking of when saying "Pax Web 7 was not R6
> Whiteboard compliant) is this OSGi filter:
>
> (osgi.http.whiteboard.servlet.name=*)
>
> stored in "osgi.http.whiteboard.context.select" service registration
> property. Supporting it required deep refactoring, but I think it's already
> done.
>
> Welcome file (and resource) handling in Pax Web 8 is changed, so it also
> leverages as much as possible from:
>  - org.apache.catalina.servlets.DefaultServlet
>  - io.undertow.servlet.handlers.DefaultServlet
>  - org.eclipse.jetty.servlet.DefaultServlet
>
> So we have now (for free!) caching, etags and Accept-Ranges support.
>
> Handling URLs from HttpContext/ServletContextHelper.getResource() like
> "bundle://22.0:1/" (Felix), bypassing
> https://issues.apache.org/jira/browse/FELIX-6294, handling "bundle
> directories", welcome files from file:/bundle:/bundleresource: URIs now
> works consistently across runtimes.
>
> Here's rough plan for coming weeks:
>  - whiteboard layer for implemented resources/welcome files (2 days max)
>  - error page handling for implemented servlet registration (1 day max)
>  - pax-web-extender-war - I wanted to implement transactional web.xml
> registration (begin() + end()) and it requires little design, but the "one
> configuration thread" is created with this transactional approach in mind
>  - JSF resource lookup - I've spend lot of time to check all possible
> resource fetching methods (bundle resources/entries, classloaders,
> fragments, wirings, ...), so it's a matter of test migration and checking
> where do we want "BundleResourceClassLoader"
>  - per-context session handling (felix.http has this), but I don't think we
> need it for GA (per context attribute storage works already!)
>  - registration of ServletContainerInitializers and login configs - I
> didn't look into it yet, but that fits perfectly into what we already have
>  - JSPs - lot of initial work (last year!) was done to handle JSPs better
> (without duplicating/shading/private-packaging Jasper classes) - I already
> have pax-web-itest-jsp project with exotic things like custom tag files
> tests. pax-web-tomcat-common bundle was created to support pax-web-jsp with
> better OSGi manifest. Also, JSP servlet with current servlet
> (un)registration handling should not be a problem
>
> I really devote much of my daily job (and free time ;) for this, but I'm
> 100% sure, that we're almost there - at least I don't expect bigger issues
> (which wasn't true when I started the refactoring)
>
> kind regards
> Grzegorz Grzybek
>
> wt., 7 lip 2020 o 16:11 Achim Nierbeck <bc...@googlemail.com.invalid>
> napisał(a):
>
>> Hi,
>>
>> as being responsible for supporting more then one container for Pax-Web
>> it's been unclear at the time if Jetty would always be the best idea.
>> (which you now can see regarding the latest Servlet spec)
>> That's why I added Tomcat and Guillaume added Undertow later on.
>> So much for the Why multiple underlying containers.
>>
>> Now regarding R6 compatibility:
>> Pax Web does support a Whiteboard Approach since it's earliest stages: 0.6.
>> It's been improved all those years from 1.0 till 4.x to match what was
>> capable with the web-container approach.
>> Then the Felix HTTP project created a "new" reference for the Whiteboard
>> Specification (aka R6).
>> When trying to adapt to it, it's always been a trade off between sticking
>> to the already known implementation to the community and aligning with R6.
>> That's why it's never been really R6 compliant, only close to.
>>
>> I know what a tremendous workload it is to refactor the whole stack to be
>> R6 compliant.
>> So big Kudos to Greg for taking this :)
>>
>> Unfortunately my dayjob has been consuming too much of my time to be of any
>> help, and when I tried to help out a bit I realised the refactored version
>> isn't what I was remembering.
>> So I have to admit ... I won't be much of a help on the project anymore :(
>>
>> If you would ask me where to take a shortcut, I'd say, sorry no way.
>> If we want it to be R6/7/8 compliant we'll need to go through that valley
>> of tears to get to it.
>> I just hope there are more people able to help Greg to get there.
>>
>> regards, Achim
>>
>> P.S. it really saddens me of not being able to help on this, anymore :(
>>
>> Am Di., 7. Juli 2020 um 14:17 Uhr schrieb Jean-Baptiste Onofre <
>> jb@nanthrax.net>:
>>
>>> Hi,
>>>
>>> I will help you. The purpose is to have a viable ETA for Pax Web 8.0 (for
>>> Karaf 4.3).
>>>
>>> Do you think reasonable to target end of next week fo Pax Web 8.0.0 (even
>>> if all is not completed/fixed) if we work together ?
>>>
>>> That would be great.
>>>
>>> Regards
>>> JB
>>>
>>>> Le 7 juil. 2020 à 12:23, Grzegorz Grzybek <gr...@gmail.com> a
>>> écrit :
>>>> Hello
>>>>
>>>> The problem with Pax-Web 8 and R7 compatibility is mostly related to
>> ...
>>>> Pax-Web 7 (and 6) not being R6 compatible at all...
>>>>
>>>> Indeed - the refactoring was very ambitious - 1st, I didn't want to get
>>> rid
>>>> of all the huge work and design of Pax Web, 2nd, I though it'll be
>>>> comparable to my previous Pax Logging refactoring (where among others
>>> I've
>>>> increased number of real integration tests from 0 to 100+).
>>>>
>>>> I'm working now on "resource and welcome file handling" - and while
>>>> "welcome files" are not covered at all in Whiteboard/HttpService specs,
>>> Pax
>>>> Web is known to support them - so not having them would be a
>> regression.
>>>> I hope to have working resources/welcome files implementation this
>> week -
>>>> just check the related test size to see what I'm talking about:
>>>>
>> https://github.com/ops4j/org.ops4j.pax.web/blob/master-improvements/pax-web-jetty/src/test/java/org/ops4j/pax/web/service/jetty/internal/UnifiedJettyTest.java#L360-L663
>>>> (with similar tests for Tomcat and Undertow).
>>>>
>>>> After resources/welcome-files, the big remaining thing is
>>>> pax-web-extender-war, however the refactoring will be minimal, because
>>> the
>>>> biggest changes were related to model (pax-web-spi), pax-web-runtime
>> and
>>>> whiteboard trackers.
>>>>
>>>> For now, master-improvements branch is in a state where chance for
>> merge
>>>> conflict is minimal (for some time initially I did really huge changes,
>>>> removals and moves of the files/packages).
>>>>
>>>> Also, the most important integration tests are now in the process of
>>> moving
>>>> (in other words - those that are moved, work).
>>>>
>>>> During my work I have also created some serious issues like:
>>>> - https://github.com/eclipse-ee4j/servlet-api/issues/300
>>>> - https://github.com/eclipse/jetty.project/pull/5025
>>>>
>>>> I'm aware that R8 is coming, but when we have working R7 implementation
>>> (or
>>>> rather R6 implementation in the first place), it'd be a matter of ~2
>>> weeks
>>>> to implement R8 on top of working R7.
>>>>
>>>> So, thanks for patience, sorry for delay and please help if you like ;)
>>>>
>>>> regards
>>>> Grzegorz Grzybek
>>>>
>>>> wt., 7 lip 2020 o 11:27 Jean-Baptiste Onofre <jb...@nanthrax.net>
>>> napisał(a):
>>>>> Hi,
>>>>>
>>>>> See my comment inline
>>>>>
>>>>>> Le 7 juil. 2020 à 11:22, Romain Manni-Bucau <rm...@gmail.com>
>> a
>>>>> écrit :
>>>>>> Hi JB,
>>>>>>
>>>>>> I see more issues using felix http:
>>>>>>
>>>>>> 1. it only supports felix today AFAIK which directly impacts the
>>>>> production
>>>>>> since then your monitoring/observability/instrumentation can be to
>> redo
>>>>> so
>>>>>> for me it is way more impacting than the dev side - and more vicious
>>>>> Good point, we can have impact with Equinox, true.
>>>>>
>>>>>> 2. felix is a fatjar so you can't upgrade jetty when needed which is
>>>>> also a
>>>>>> big loss compared to not having R7 IMHO
>>>>> That’s a discussion standpoint. Having a fat jar can be seen as a good
>>>>> point as upgrading Jetty (or Tomcat, or undertow) is not always (never
>>> ;))
>>>>> "smooth" at Pax Web.
>>>>>
>>>>>> How far is paxweb from R7? Not being 100% compliant is fine IMO
>> while:
>>>>>> a. it can be manually switched to a compliant impl if required
>>>>>> b. there is no regression from previous version
>>>>>>
>>>>> I think we are pretty close just for R7, but we also started a large
>>>>> refactoring (maybe it was too "ambitious").
>>>>> So, another approach would by to start from Pax Web 7.2.x and just
>>> update
>>>>> the minimal set to R7 (new HTTP service).
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>>> Indeed just my 2cts,
>>>>>> Romain Manni-Bucau
>>>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>>>>> <https://rmannibucau.metawerx.net/> | Old Blog
>>>>>> <http://rmannibucau.wordpress.com> | Github <
>>>>> https://github.com/rmannibucau> |
>>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>>>>>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>>>>>
>>>>>>
>>>>>> Le mar. 7 juil. 2020 à 11:18, Jean-Baptiste Onofre <jb...@nanthrax.net>
>> a
>>>>>> écrit :
>>>>>>
>>>>>>> Hi everyone,
>>>>>>>
>>>>>>> It’s more than a year now that we started Apache Karaf 4.3.0 release
>>>>>>> process, fully supporting OSGi R7.
>>>>>>>
>>>>>>> If the 4.3.0 distribution is ready, we are blocked by Pax Web. I’m
>>>>>>> concerned about that as R8 will be there and we will have issue in
>> Pax
>>>>> Web
>>>>>>> again.
>>>>>>>
>>>>>>> Greg started a huge effort heading to Pax Web 8.0.0 with a large
>>>>>>> refactoring.
>>>>>>> However, the process is long and painful.
>>>>>>> So, I think it’s fair to have a discussion about the HTTP service in
>>>>> Karaf
>>>>>>> and "relationship" with Pax Web.
>>>>>>>
>>>>>>> I see three options for Karaf 4.3.0:
>>>>>>>
>>>>>>> 1. We are able to release Pax Web 8.0.0 (with R7 support) and so, no
>>>>>>> brainer, we can move forward.
>>>>>>> 2. Instead of using Pax Web by default, we "switch" to Felix HTTP by
>>>>>>> default. For the "pure" HTTP service, it will be transparent but it
>>>>> would
>>>>>>> have two impacts:
>>>>>>> * the configuration changes (as obviously etc/org.ops4j.pax.web.cfg
>>>>>>> doesn’t exist anymore)
>>>>>>> * users using WebContainer PaxWeb API instead of HTTP service won’t
>>>>> work
>>>>>>> 3. We consider that Pax Web as it is today is not flexible enough
>> and
>>>>> too
>>>>>>> painful, and we start an even larger refactoring on Pax Web.
>>>>>>>
>>>>>>> The reason why I’m bringing this discussion on the mailing list: we
>>>>> really
>>>>>>> need a clear plan and release 4.3.0 (I would really love to release
>>>>> 4.3.0
>>>>>>> mid July max, so we need a plan).
>>>>>>>
>>>>>>> Thoughts ?
>>>>>>>
>>>>>>> Regards
>>>>>>> JB
>>>>>
>>>
>> --
>>
>> Apache Member
>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
>> Project Lead
>> blog <http://notizblog.nierbeck.de/>
>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>

Re: [DISCUSSION] Apache Karaf 4.3.0 and Pax Web

Posted by Grzegorz Grzybek <gr...@gmail.com>.

Hello

I'm proud to announce that I've pushed master-improvement changes where you
can simply call `mvn clean install` AND `mvn clean install -Pequinox`.

Check for example pax-web-itest-undertow tests (see the times!)

[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
[INFO] Running
org.ops4j.pax.web.itest.undertow.httpservice.AsyncServletIntegrationTest
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
3.458 s - in
org.ops4j.pax.web.itest.undertow.httpservice.AsyncServletIntegrationTest
[INFO] Running
org.ops4j.pax.web.itest.undertow.httpservice.AuthenticationIntegrationTest
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
2.524 s - in
org.ops4j.pax.web.itest.undertow.httpservice.AuthenticationIntegrationTest
[INFO] Running
org.ops4j.pax.web.itest.undertow.httpservice.HttpCustomContextIntegrationTest
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
2.747 s - in
org.ops4j.pax.web.itest.undertow.httpservice.HttpCustomContextIntegrationTest
[INFO] Running
org.ops4j.pax.web.itest.undertow.httpservice.HttpServiceBundleIntegrationTest
[INFO] Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
2.956 s - in
org.ops4j.pax.web.itest.undertow.httpservice.HttpServiceBundleIntegrationTest
[INFO] Running
org.ops4j.pax.web.itest.undertow.httpservice.HttpServiceIntegrationTest
[INFO] Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
2.891 s - in
org.ops4j.pax.web.itest.undertow.httpservice.HttpServiceIntegrationTest
[INFO] Running
org.ops4j.pax.web.itest.undertow.httpservice.HttpServiceWithConfigAdminIntegrationTest
[INFO] Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
3.346 s - in
org.ops4j.pax.web.itest.undertow.httpservice.HttpServiceWithConfigAdminIntegrationTest
[INFO] Running
org.ops4j.pax.web.itest.undertow.httpservice.HttpServiceWithoutCMIntegrationTest
[INFO] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
2.832 s - in
org.ops4j.pax.web.itest.undertow.httpservice.HttpServiceWithoutCMIntegrationTest

These are not all previous tests, but I'm moving them one at a time from
pax-web-itest-container-xxx to pax-web-itest-xxx (so I know what works and
what doesn't).

With this push, I think I've covered a huge amount of missing unification
related to welcome file handling. Please feel free to play with the current
state of the branch. In the coming days, I'm going to add a cherry on top
of welcome file handling by adding a whiteboard layer to it.

Whiteboard layer is all about tracking "incoming" services and turning them
into "models" (customization) - I've removed the intermediary layer of "web
elements" present in Pax Web 7.

Kudoz to Achim and other Pax Web developers who created Pax Web Extender
Whiteboard before CMPN Whiteboard was crafted (and IT was inspired by Pax
Web, not vice versa!)

The biggest problem I was thinking of when saying "Pax Web 7 was not R6
Whiteboard compliant) is this OSGi filter:

(osgi.http.whiteboard.servlet.name=*)

stored in "osgi.http.whiteboard.context.select" service registration
property. Supporting it required deep refactoring, but I think it's already
done.

Welcome file (and resource) handling in Pax Web 8 is changed, so it also
leverages as much as possible from:
 - org.apache.catalina.servlets.DefaultServlet
 - io.undertow.servlet.handlers.DefaultServlet
 - org.eclipse.jetty.servlet.DefaultServlet

So we have now (for free!) caching, etags and Accept-Ranges support.

Handling URLs from HttpContext/ServletContextHelper.getResource() like
"bundle://22.0:1/" (Felix), bypassing
https://issues.apache.org/jira/browse/FELIX-6294, handling "bundle
directories", welcome files from file:/bundle:/bundleresource: URIs now
works consistently across runtimes.

Here's rough plan for coming weeks:
 - whiteboard layer for implemented resources/welcome files (2 days max)
 - error page handling for implemented servlet registration (1 day max)
 - pax-web-extender-war - I wanted to implement transactional web.xml
registration (begin() + end()) and it requires little design, but the "one
configuration thread" is created with this transactional approach in mind
 - JSF resource lookup - I've spend lot of time to check all possible
resource fetching methods (bundle resources/entries, classloaders,
fragments, wirings, ...), so it's a matter of test migration and checking
where do we want "BundleResourceClassLoader"
 - per-context session handling (felix.http has this), but I don't think we
need it for GA (per context attribute storage works already!)
 - registration of ServletContainerInitializers and login configs - I
didn't look into it yet, but that fits perfectly into what we already have
 - JSPs - lot of initial work (last year!) was done to handle JSPs better
(without duplicating/shading/private-packaging Jasper classes) - I already
have pax-web-itest-jsp project with exotic things like custom tag files
tests. pax-web-tomcat-common bundle was created to support pax-web-jsp with
better OSGi manifest. Also, JSP servlet with current servlet
(un)registration handling should not be a problem

I really devote much of my daily job (and free time ;) for this, but I'm
100% sure, that we're almost there - at least I don't expect bigger issues
(which wasn't true when I started the refactoring)

kind regards
Grzegorz Grzybek

wt., 7 lip 2020 o 16:11 Achim Nierbeck <bc...@googlemail.com.invalid>
napisał(a):

> Hi,
>
> as being responsible for supporting more then one container for Pax-Web
> it's been unclear at the time if Jetty would always be the best idea.
> (which you now can see regarding the latest Servlet spec)
> That's why I added Tomcat and Guillaume added Undertow later on.
> So much for the Why multiple underlying containers.
>
> Now regarding R6 compatibility:
> Pax Web does support a Whiteboard Approach since it's earliest stages: 0.6.
> It's been improved all those years from 1.0 till 4.x to match what was
> capable with the web-container approach.
> Then the Felix HTTP project created a "new" reference for the Whiteboard
> Specification (aka R6).
> When trying to adapt to it, it's always been a trade off between sticking
> to the already known implementation to the community and aligning with R6.
> That's why it's never been really R6 compliant, only close to.
>
> I know what a tremendous workload it is to refactor the whole stack to be
> R6 compliant.
> So big Kudos to Greg for taking this :)
>
> Unfortunately my dayjob has been consuming too much of my time to be of any
> help, and when I tried to help out a bit I realised the refactored version
> isn't what I was remembering.
> So I have to admit ... I won't be much of a help on the project anymore :(
>
> If you would ask me where to take a shortcut, I'd say, sorry no way.
> If we want it to be R6/7/8 compliant we'll need to go through that valley
> of tears to get to it.
> I just hope there are more people able to help Greg to get there.
>
> regards, Achim
>
> P.S. it really saddens me of not being able to help on this, anymore :(
>
> Am Di., 7. Juli 2020 um 14:17 Uhr schrieb Jean-Baptiste Onofre <
> jb@nanthrax.net>:
>
> > Hi,
> >
> > I will help you. The purpose is to have a viable ETA for Pax Web 8.0 (for
> > Karaf 4.3).
> >
> > Do you think reasonable to target end of next week fo Pax Web 8.0.0 (even
> > if all is not completed/fixed) if we work together ?
> >
> > That would be great.
> >
> > Regards
> > JB
> >
> > > Le 7 juil. 2020 à 12:23, Grzegorz Grzybek <gr...@gmail.com> a
> > écrit :
> > >
> > > Hello
> > >
> > > The problem with Pax-Web 8 and R7 compatibility is mostly related to
> ...
> > > Pax-Web 7 (and 6) not being R6 compatible at all...
> > >
> > > Indeed - the refactoring was very ambitious - 1st, I didn't want to get
> > rid
> > > of all the huge work and design of Pax Web, 2nd, I though it'll be
> > > comparable to my previous Pax Logging refactoring (where among others
> > I've
> > > increased number of real integration tests from 0 to 100+).
> > >
> > > I'm working now on "resource and welcome file handling" - and while
> > > "welcome files" are not covered at all in Whiteboard/HttpService specs,
> > Pax
> > > Web is known to support them - so not having them would be a
> regression.
> > >
> > > I hope to have working resources/welcome files implementation this
> week -
> > > just check the related test size to see what I'm talking about:
> > >
> >
> https://github.com/ops4j/org.ops4j.pax.web/blob/master-improvements/pax-web-jetty/src/test/java/org/ops4j/pax/web/service/jetty/internal/UnifiedJettyTest.java#L360-L663
> > > (with similar tests for Tomcat and Undertow).
> > >
> > > After resources/welcome-files, the big remaining thing is
> > > pax-web-extender-war, however the refactoring will be minimal, because
> > the
> > > biggest changes were related to model (pax-web-spi), pax-web-runtime
> and
> > > whiteboard trackers.
> > >
> > > For now, master-improvements branch is in a state where chance for
> merge
> > > conflict is minimal (for some time initially I did really huge changes,
> > > removals and moves of the files/packages).
> > >
> > > Also, the most important integration tests are now in the process of
> > moving
> > > (in other words - those that are moved, work).
> > >
> > > During my work I have also created some serious issues like:
> > > - https://github.com/eclipse-ee4j/servlet-api/issues/300
> > > - https://github.com/eclipse/jetty.project/pull/5025
> > >
> > > I'm aware that R8 is coming, but when we have working R7 implementation
> > (or
> > > rather R6 implementation in the first place), it'd be a matter of ~2
> > weeks
> > > to implement R8 on top of working R7.
> > >
> > > So, thanks for patience, sorry for delay and please help if you like ;)
> > >
> > > regards
> > > Grzegorz Grzybek
> > >
> > > wt., 7 lip 2020 o 11:27 Jean-Baptiste Onofre <jb...@nanthrax.net>
> > napisał(a):
> > >
> > >> Hi,
> > >>
> > >> See my comment inline
> > >>
> > >>> Le 7 juil. 2020 à 11:22, Romain Manni-Bucau <rm...@gmail.com>
> a
> > >> écrit :
> > >>>
> > >>> Hi JB,
> > >>>
> > >>> I see more issues using felix http:
> > >>>
> > >>> 1. it only supports felix today AFAIK which directly impacts the
> > >> production
> > >>> since then your monitoring/observability/instrumentation can be to
> redo
> > >> so
> > >>> for me it is way more impacting than the dev side - and more vicious
> > >>
> > >> Good point, we can have impact with Equinox, true.
> > >>
> > >>> 2. felix is a fatjar so you can't upgrade jetty when needed which is
> > >> also a
> > >>> big loss compared to not having R7 IMHO
> > >>
> > >> That’s a discussion standpoint. Having a fat jar can be seen as a good
> > >> point as upgrading Jetty (or Tomcat, or undertow) is not always (never
> > ;))
> > >> "smooth" at Pax Web.
> > >>
> > >>>
> > >>> How far is paxweb from R7? Not being 100% compliant is fine IMO
> while:
> > >>> a. it can be manually switched to a compliant impl if required
> > >>> b. there is no regression from previous version
> > >>>
> > >>
> > >> I think we are pretty close just for R7, but we also started a large
> > >> refactoring (maybe it was too "ambitious").
> > >> So, another approach would by to start from Pax Web 7.2.x and just
> > update
> > >> the minimal set to R7 (new HTTP service).
> > >>
> > >> Regards
> > >> JB
> > >>
> > >>> Indeed just my 2cts,
> > >>> Romain Manni-Bucau
> > >>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > >>> <https://rmannibucau.metawerx.net/> | Old Blog
> > >>> <http://rmannibucau.wordpress.com> | Github <
> > >> https://github.com/rmannibucau> |
> > >>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > >>> <
> > >>
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >>>
> > >>>
> > >>>
> > >>> Le mar. 7 juil. 2020 à 11:18, Jean-Baptiste Onofre <jb...@nanthrax.net>
> a
> > >>> écrit :
> > >>>
> > >>>> Hi everyone,
> > >>>>
> > >>>> It’s more than a year now that we started Apache Karaf 4.3.0 release
> > >>>> process, fully supporting OSGi R7.
> > >>>>
> > >>>> If the 4.3.0 distribution is ready, we are blocked by Pax Web. I’m
> > >>>> concerned about that as R8 will be there and we will have issue in
> Pax
> > >> Web
> > >>>> again.
> > >>>>
> > >>>> Greg started a huge effort heading to Pax Web 8.0.0 with a large
> > >>>> refactoring.
> > >>>> However, the process is long and painful.
> > >>>> So, I think it’s fair to have a discussion about the HTTP service in
> > >> Karaf
> > >>>> and "relationship" with Pax Web.
> > >>>>
> > >>>> I see three options for Karaf 4.3.0:
> > >>>>
> > >>>> 1. We are able to release Pax Web 8.0.0 (with R7 support) and so, no
> > >>>> brainer, we can move forward.
> > >>>> 2. Instead of using Pax Web by default, we "switch" to Felix HTTP by
> > >>>> default. For the "pure" HTTP service, it will be transparent but it
> > >> would
> > >>>> have two impacts:
> > >>>> * the configuration changes (as obviously etc/org.ops4j.pax.web.cfg
> > >>>> doesn’t exist anymore)
> > >>>> * users using WebContainer PaxWeb API instead of HTTP service won’t
> > >> work
> > >>>> 3. We consider that Pax Web as it is today is not flexible enough
> and
> > >> too
> > >>>> painful, and we start an even larger refactoring on Pax Web.
> > >>>>
> > >>>> The reason why I’m bringing this discussion on the mailing list: we
> > >> really
> > >>>> need a clear plan and release 4.3.0 (I would really love to release
> > >> 4.3.0
> > >>>> mid July max, so we need a plan).
> > >>>>
> > >>>> Thoughts ?
> > >>>>
> > >>>> Regards
> > >>>> JB
> > >>
> > >>
> >
> >
>
> --
>
> Apache Member
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
> Project Lead
> blog <http://notizblog.nierbeck.de/>
> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>

Re: [DISCUSSION] Apache Karaf 4.3.0 and Pax Web

Posted by Achim Nierbeck <bc...@googlemail.com.INVALID>.

Hi,

as being responsible for supporting more then one container for Pax-Web
it's been unclear at the time if Jetty would always be the best idea.
(which you now can see regarding the latest Servlet spec)
That's why I added Tomcat and Guillaume added Undertow later on.
So much for the Why multiple underlying containers.

Now regarding R6 compatibility:
Pax Web does support a Whiteboard Approach since it's earliest stages: 0.6.
It's been improved all those years from 1.0 till 4.x to match what was
capable with the web-container approach.
Then the Felix HTTP project created a "new" reference for the Whiteboard
Specification (aka R6).
When trying to adapt to it, it's always been a trade off between sticking
to the already known implementation to the community and aligning with R6.
That's why it's never been really R6 compliant, only close to.

I know what a tremendous workload it is to refactor the whole stack to be
R6 compliant.
So big Kudos to Greg for taking this :)

Unfortunately my dayjob has been consuming too much of my time to be of any
help, and when I tried to help out a bit I realised the refactored version
isn't what I was remembering.
So I have to admit ... I won't be much of a help on the project anymore :(

If you would ask me where to take a shortcut, I'd say, sorry no way.
If we want it to be R6/7/8 compliant we'll need to go through that valley
of tears to get to it.
I just hope there are more people able to help Greg to get there.

regards, Achim

P.S. it really saddens me of not being able to help on this, anymore :(

Am Di., 7. Juli 2020 um 14:17 Uhr schrieb Jean-Baptiste Onofre <
jb@nanthrax.net>:

> Hi,
>
> I will help you. The purpose is to have a viable ETA for Pax Web 8.0 (for
> Karaf 4.3).
>
> Do you think reasonable to target end of next week fo Pax Web 8.0.0 (even
> if all is not completed/fixed) if we work together ?
>
> That would be great.
>
> Regards
> JB
>
> > Le 7 juil. 2020 à 12:23, Grzegorz Grzybek <gr...@gmail.com> a
> écrit :
> >
> > Hello
> >
> > The problem with Pax-Web 8 and R7 compatibility is mostly related to ...
> > Pax-Web 7 (and 6) not being R6 compatible at all...
> >
> > Indeed - the refactoring was very ambitious - 1st, I didn't want to get
> rid
> > of all the huge work and design of Pax Web, 2nd, I though it'll be
> > comparable to my previous Pax Logging refactoring (where among others
> I've
> > increased number of real integration tests from 0 to 100+).
> >
> > I'm working now on "resource and welcome file handling" - and while
> > "welcome files" are not covered at all in Whiteboard/HttpService specs,
> Pax
> > Web is known to support them - so not having them would be a regression.
> >
> > I hope to have working resources/welcome files implementation this week -
> > just check the related test size to see what I'm talking about:
> >
> https://github.com/ops4j/org.ops4j.pax.web/blob/master-improvements/pax-web-jetty/src/test/java/org/ops4j/pax/web/service/jetty/internal/UnifiedJettyTest.java#L360-L663
> > (with similar tests for Tomcat and Undertow).
> >
> > After resources/welcome-files, the big remaining thing is
> > pax-web-extender-war, however the refactoring will be minimal, because
> the
> > biggest changes were related to model (pax-web-spi), pax-web-runtime and
> > whiteboard trackers.
> >
> > For now, master-improvements branch is in a state where chance for merge
> > conflict is minimal (for some time initially I did really huge changes,
> > removals and moves of the files/packages).
> >
> > Also, the most important integration tests are now in the process of
> moving
> > (in other words - those that are moved, work).
> >
> > During my work I have also created some serious issues like:
> > - https://github.com/eclipse-ee4j/servlet-api/issues/300
> > - https://github.com/eclipse/jetty.project/pull/5025
> >
> > I'm aware that R8 is coming, but when we have working R7 implementation
> (or
> > rather R6 implementation in the first place), it'd be a matter of ~2
> weeks
> > to implement R8 on top of working R7.
> >
> > So, thanks for patience, sorry for delay and please help if you like ;)
> >
> > regards
> > Grzegorz Grzybek
> >
> > wt., 7 lip 2020 o 11:27 Jean-Baptiste Onofre <jb...@nanthrax.net>
> napisał(a):
> >
> >> Hi,
> >>
> >> See my comment inline
> >>
> >>> Le 7 juil. 2020 à 11:22, Romain Manni-Bucau <rm...@gmail.com> a
> >> écrit :
> >>>
> >>> Hi JB,
> >>>
> >>> I see more issues using felix http:
> >>>
> >>> 1. it only supports felix today AFAIK which directly impacts the
> >> production
> >>> since then your monitoring/observability/instrumentation can be to redo
> >> so
> >>> for me it is way more impacting than the dev side - and more vicious
> >>
> >> Good point, we can have impact with Equinox, true.
> >>
> >>> 2. felix is a fatjar so you can't upgrade jetty when needed which is
> >> also a
> >>> big loss compared to not having R7 IMHO
> >>
> >> That’s a discussion standpoint. Having a fat jar can be seen as a good
> >> point as upgrading Jetty (or Tomcat, or undertow) is not always (never
> ;))
> >> "smooth" at Pax Web.
> >>
> >>>
> >>> How far is paxweb from R7? Not being 100% compliant is fine IMO while:
> >>> a. it can be manually switched to a compliant impl if required
> >>> b. there is no regression from previous version
> >>>
> >>
> >> I think we are pretty close just for R7, but we also started a large
> >> refactoring (maybe it was too "ambitious").
> >> So, another approach would by to start from Pax Web 7.2.x and just
> update
> >> the minimal set to R7 (new HTTP service).
> >>
> >> Regards
> >> JB
> >>
> >>> Indeed just my 2cts,
> >>> Romain Manni-Bucau
> >>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >>> <https://rmannibucau.metawerx.net/> | Old Blog
> >>> <http://rmannibucau.wordpress.com> | Github <
> >> https://github.com/rmannibucau> |
> >>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> >>> <
> >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >>>
> >>>
> >>>
> >>> Le mar. 7 juil. 2020 à 11:18, Jean-Baptiste Onofre <jb...@nanthrax.net> a
> >>> écrit :
> >>>
> >>>> Hi everyone,
> >>>>
> >>>> It’s more than a year now that we started Apache Karaf 4.3.0 release
> >>>> process, fully supporting OSGi R7.
> >>>>
> >>>> If the 4.3.0 distribution is ready, we are blocked by Pax Web. I’m
> >>>> concerned about that as R8 will be there and we will have issue in Pax
> >> Web
> >>>> again.
> >>>>
> >>>> Greg started a huge effort heading to Pax Web 8.0.0 with a large
> >>>> refactoring.
> >>>> However, the process is long and painful.
> >>>> So, I think it’s fair to have a discussion about the HTTP service in
> >> Karaf
> >>>> and "relationship" with Pax Web.
> >>>>
> >>>> I see three options for Karaf 4.3.0:
> >>>>
> >>>> 1. We are able to release Pax Web 8.0.0 (with R7 support) and so, no
> >>>> brainer, we can move forward.
> >>>> 2. Instead of using Pax Web by default, we "switch" to Felix HTTP by
> >>>> default. For the "pure" HTTP service, it will be transparent but it
> >> would
> >>>> have two impacts:
> >>>> * the configuration changes (as obviously etc/org.ops4j.pax.web.cfg
> >>>> doesn’t exist anymore)
> >>>> * users using WebContainer PaxWeb API instead of HTTP service won’t
> >> work
> >>>> 3. We consider that Pax Web as it is today is not flexible enough and
> >> too
> >>>> painful, and we start an even larger refactoring on Pax Web.
> >>>>
> >>>> The reason why I’m bringing this discussion on the mailing list: we
> >> really
> >>>> need a clear plan and release 4.3.0 (I would really love to release
> >> 4.3.0
> >>>> mid July max, so we need a plan).
> >>>>
> >>>> Thoughts ?
> >>>>
> >>>> Regards
> >>>> JB
> >>
> >>
>
>

-- 

Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>

Re: [DISCUSSION] Apache Karaf 4.3.0 and Pax Web

Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.

Hi,

I will help you. The purpose is to have a viable ETA for Pax Web 8.0 (for Karaf 4.3).

Do you think reasonable to target end of next week fo Pax Web 8.0.0 (even if all is not completed/fixed) if we work together ?

That would be great.

Regards
JB

> Le 7 juil. 2020 à 12:23, Grzegorz Grzybek <gr...@gmail.com> a écrit :
> 
> Hello
> 
> The problem with Pax-Web 8 and R7 compatibility is mostly related to ...
> Pax-Web 7 (and 6) not being R6 compatible at all...
> 
> Indeed - the refactoring was very ambitious - 1st, I didn't want to get rid
> of all the huge work and design of Pax Web, 2nd, I though it'll be
> comparable to my previous Pax Logging refactoring (where among others I've
> increased number of real integration tests from 0 to 100+).
> 
> I'm working now on "resource and welcome file handling" - and while
> "welcome files" are not covered at all in Whiteboard/HttpService specs, Pax
> Web is known to support them - so not having them would be a regression.
> 
> I hope to have working resources/welcome files implementation this week -
> just check the related test size to see what I'm talking about:
> https://github.com/ops4j/org.ops4j.pax.web/blob/master-improvements/pax-web-jetty/src/test/java/org/ops4j/pax/web/service/jetty/internal/UnifiedJettyTest.java#L360-L663
> (with similar tests for Tomcat and Undertow).
> 
> After resources/welcome-files, the big remaining thing is
> pax-web-extender-war, however the refactoring will be minimal, because the
> biggest changes were related to model (pax-web-spi), pax-web-runtime and
> whiteboard trackers.
> 
> For now, master-improvements branch is in a state where chance for merge
> conflict is minimal (for some time initially I did really huge changes,
> removals and moves of the files/packages).
> 
> Also, the most important integration tests are now in the process of moving
> (in other words - those that are moved, work).
> 
> During my work I have also created some serious issues like:
> - https://github.com/eclipse-ee4j/servlet-api/issues/300
> - https://github.com/eclipse/jetty.project/pull/5025
> 
> I'm aware that R8 is coming, but when we have working R7 implementation (or
> rather R6 implementation in the first place), it'd be a matter of ~2 weeks
> to implement R8 on top of working R7.
> 
> So, thanks for patience, sorry for delay and please help if you like ;)
> 
> regards
> Grzegorz Grzybek
> 
> wt., 7 lip 2020 o 11:27 Jean-Baptiste Onofre <jb...@nanthrax.net> napisał(a):
> 
>> Hi,
>> 
>> See my comment inline
>> 
>>> Le 7 juil. 2020 à 11:22, Romain Manni-Bucau <rm...@gmail.com> a
>> écrit :
>>> 
>>> Hi JB,
>>> 
>>> I see more issues using felix http:
>>> 
>>> 1. it only supports felix today AFAIK which directly impacts the
>> production
>>> since then your monitoring/observability/instrumentation can be to redo
>> so
>>> for me it is way more impacting than the dev side - and more vicious
>> 
>> Good point, we can have impact with Equinox, true.
>> 
>>> 2. felix is a fatjar so you can't upgrade jetty when needed which is
>> also a
>>> big loss compared to not having R7 IMHO
>> 
>> That’s a discussion standpoint. Having a fat jar can be seen as a good
>> point as upgrading Jetty (or Tomcat, or undertow) is not always (never ;))
>> "smooth" at Pax Web.
>> 
>>> 
>>> How far is paxweb from R7? Not being 100% compliant is fine IMO while:
>>> a. it can be manually switched to a compliant impl if required
>>> b. there is no regression from previous version
>>> 
>> 
>> I think we are pretty close just for R7, but we also started a large
>> refactoring (maybe it was too "ambitious").
>> So, another approach would by to start from Pax Web 7.2.x and just update
>> the minimal set to R7 (new HTTP service).
>> 
>> Regards
>> JB
>> 
>>> Indeed just my 2cts,
>>> Romain Manni-Bucau
>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>> <https://rmannibucau.metawerx.net/> | Old Blog
>>> <http://rmannibucau.wordpress.com> | Github <
>> https://github.com/rmannibucau> |
>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>> 
>>> 
>>> 
>>> Le mar. 7 juil. 2020 à 11:18, Jean-Baptiste Onofre <jb...@nanthrax.net> a
>>> écrit :
>>> 
>>>> Hi everyone,
>>>> 
>>>> It’s more than a year now that we started Apache Karaf 4.3.0 release
>>>> process, fully supporting OSGi R7.
>>>> 
>>>> If the 4.3.0 distribution is ready, we are blocked by Pax Web. I’m
>>>> concerned about that as R8 will be there and we will have issue in Pax
>> Web
>>>> again.
>>>> 
>>>> Greg started a huge effort heading to Pax Web 8.0.0 with a large
>>>> refactoring.
>>>> However, the process is long and painful.
>>>> So, I think it’s fair to have a discussion about the HTTP service in
>> Karaf
>>>> and "relationship" with Pax Web.
>>>> 
>>>> I see three options for Karaf 4.3.0:
>>>> 
>>>> 1. We are able to release Pax Web 8.0.0 (with R7 support) and so, no
>>>> brainer, we can move forward.
>>>> 2. Instead of using Pax Web by default, we "switch" to Felix HTTP by
>>>> default. For the "pure" HTTP service, it will be transparent but it
>> would
>>>> have two impacts:
>>>> * the configuration changes (as obviously etc/org.ops4j.pax.web.cfg
>>>> doesn’t exist anymore)
>>>> * users using WebContainer PaxWeb API instead of HTTP service won’t
>> work
>>>> 3. We consider that Pax Web as it is today is not flexible enough and
>> too
>>>> painful, and we start an even larger refactoring on Pax Web.
>>>> 
>>>> The reason why I’m bringing this discussion on the mailing list: we
>> really
>>>> need a clear plan and release 4.3.0 (I would really love to release
>> 4.3.0
>>>> mid July max, so we need a plan).
>>>> 
>>>> Thoughts ?
>>>> 
>>>> Regards
>>>> JB
>> 
>>

Re: [DISCUSSION] Apache Karaf 4.3.0 and Pax Web

Posted by Grzegorz Grzybek <gr...@gmail.com>.

Hello

The problem with Pax-Web 8 and R7 compatibility is mostly related to ...
Pax-Web 7 (and 6) not being R6 compatible at all...

Indeed - the refactoring was very ambitious - 1st, I didn't want to get rid
of all the huge work and design of Pax Web, 2nd, I though it'll be
comparable to my previous Pax Logging refactoring (where among others I've
increased number of real integration tests from 0 to 100+).

I'm working now on "resource and welcome file handling" - and while
"welcome files" are not covered at all in Whiteboard/HttpService specs, Pax
Web is known to support them - so not having them would be a regression.

I hope to have working resources/welcome files implementation this week -
just check the related test size to see what I'm talking about:
https://github.com/ops4j/org.ops4j.pax.web/blob/master-improvements/pax-web-jetty/src/test/java/org/ops4j/pax/web/service/jetty/internal/UnifiedJettyTest.java#L360-L663
(with similar tests for Tomcat and Undertow).

After resources/welcome-files, the big remaining thing is
pax-web-extender-war, however the refactoring will be minimal, because the
biggest changes were related to model (pax-web-spi), pax-web-runtime and
whiteboard trackers.

For now, master-improvements branch is in a state where chance for merge
conflict is minimal (for some time initially I did really huge changes,
removals and moves of the files/packages).

Also, the most important integration tests are now in the process of moving
(in other words - those that are moved, work).

During my work I have also created some serious issues like:
 - https://github.com/eclipse-ee4j/servlet-api/issues/300
 - https://github.com/eclipse/jetty.project/pull/5025

I'm aware that R8 is coming, but when we have working R7 implementation (or
rather R6 implementation in the first place), it'd be a matter of ~2 weeks
to implement R8 on top of working R7.

So, thanks for patience, sorry for delay and please help if you like ;)

regards
Grzegorz Grzybek

wt., 7 lip 2020 o 11:27 Jean-Baptiste Onofre <jb...@nanthrax.net> napisał(a):

> Hi,
>
> See my comment inline
>
> > Le 7 juil. 2020 à 11:22, Romain Manni-Bucau <rm...@gmail.com> a
> écrit :
> >
> > Hi JB,
> >
> > I see more issues using felix http:
> >
> > 1. it only supports felix today AFAIK which directly impacts the
> production
> > since then your monitoring/observability/instrumentation can be to redo
> so
> > for me it is way more impacting than the dev side - and more vicious
>
> Good point, we can have impact with Equinox, true.
>
> > 2. felix is a fatjar so you can't upgrade jetty when needed which is
> also a
> > big loss compared to not having R7 IMHO
>
> That’s a discussion standpoint. Having a fat jar can be seen as a good
> point as upgrading Jetty (or Tomcat, or undertow) is not always (never ;))
> "smooth" at Pax Web.
>
> >
> > How far is paxweb from R7? Not being 100% compliant is fine IMO while:
> > a. it can be manually switched to a compliant impl if required
> > b. there is no regression from previous version
> >
>
> I think we are pretty close just for R7, but we also started a large
> refactoring (maybe it was too "ambitious").
> So, another approach would by to start from Pax Web 7.2.x and just update
> the minimal set to R7 (new HTTP service).
>
> Regards
> JB
>
> > Indeed just my 2cts,
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le mar. 7 juil. 2020 à 11:18, Jean-Baptiste Onofre <jb...@nanthrax.net> a
> > écrit :
> >
> >> Hi everyone,
> >>
> >> It’s more than a year now that we started Apache Karaf 4.3.0 release
> >> process, fully supporting OSGi R7.
> >>
> >> If the 4.3.0 distribution is ready, we are blocked by Pax Web. I’m
> >> concerned about that as R8 will be there and we will have issue in Pax
> Web
> >> again.
> >>
> >> Greg started a huge effort heading to Pax Web 8.0.0 with a large
> >> refactoring.
> >> However, the process is long and painful.
> >> So, I think it’s fair to have a discussion about the HTTP service in
> Karaf
> >> and "relationship" with Pax Web.
> >>
> >> I see three options for Karaf 4.3.0:
> >>
> >> 1. We are able to release Pax Web 8.0.0 (with R7 support) and so, no
> >> brainer, we can move forward.
> >> 2. Instead of using Pax Web by default, we "switch" to Felix HTTP by
> >> default. For the "pure" HTTP service, it will be transparent but it
> would
> >> have two impacts:
> >>  * the configuration changes (as obviously etc/org.ops4j.pax.web.cfg
> >> doesn’t exist anymore)
> >>  * users using WebContainer PaxWeb API instead of HTTP service won’t
> work
> >> 3. We consider that Pax Web as it is today is not flexible enough and
> too
> >> painful, and we start an even larger refactoring on Pax Web.
> >>
> >> The reason why I’m bringing this discussion on the mailing list: we
> really
> >> need a clear plan and release 4.3.0 (I would really love to release
> 4.3.0
> >> mid July max, so we need a plan).
> >>
> >> Thoughts ?
> >>
> >> Regards
> >> JB
>
>

Re: [DISCUSSION] Apache Karaf 4.3.0 and Pax Web

Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.

Hi,

See my comment inline

> Le 7 juil. 2020 à 11:22, Romain Manni-Bucau <rm...@gmail.com> a écrit :
> 
> Hi JB,
> 
> I see more issues using felix http:
> 
> 1. it only supports felix today AFAIK which directly impacts the production
> since then your monitoring/observability/instrumentation can be to redo so
> for me it is way more impacting than the dev side - and more vicious

Good point, we can have impact with Equinox, true.

> 2. felix is a fatjar so you can't upgrade jetty when needed which is also a
> big loss compared to not having R7 IMHO

That’s a discussion standpoint. Having a fat jar can be seen as a good point as upgrading Jetty (or Tomcat, or undertow) is not always (never ;)) "smooth" at Pax Web.

> 
> How far is paxweb from R7? Not being 100% compliant is fine IMO while:
> a. it can be manually switched to a compliant impl if required
> b. there is no regression from previous version
> 

I think we are pretty close just for R7, but we also started a large refactoring (maybe it was too "ambitious").
So, another approach would by to start from Pax Web 7.2.x and just update the minimal set to R7 (new HTTP service).

Regards
JB

> Indeed just my 2cts,
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
> 
> 
> Le mar. 7 juil. 2020 à 11:18, Jean-Baptiste Onofre <jb...@nanthrax.net> a
> écrit :
> 
>> Hi everyone,
>> 
>> It’s more than a year now that we started Apache Karaf 4.3.0 release
>> process, fully supporting OSGi R7.
>> 
>> If the 4.3.0 distribution is ready, we are blocked by Pax Web. I’m
>> concerned about that as R8 will be there and we will have issue in Pax Web
>> again.
>> 
>> Greg started a huge effort heading to Pax Web 8.0.0 with a large
>> refactoring.
>> However, the process is long and painful.
>> So, I think it’s fair to have a discussion about the HTTP service in Karaf
>> and "relationship" with Pax Web.
>> 
>> I see three options for Karaf 4.3.0:
>> 
>> 1. We are able to release Pax Web 8.0.0 (with R7 support) and so, no
>> brainer, we can move forward.
>> 2. Instead of using Pax Web by default, we "switch" to Felix HTTP by
>> default. For the "pure" HTTP service, it will be transparent but it would
>> have two impacts:
>>  * the configuration changes (as obviously etc/org.ops4j.pax.web.cfg
>> doesn’t exist anymore)
>>  * users using WebContainer PaxWeb API instead of HTTP service won’t work
>> 3. We consider that Pax Web as it is today is not flexible enough and too
>> painful, and we start an even larger refactoring on Pax Web.
>> 
>> The reason why I’m bringing this discussion on the mailing list: we really
>> need a clear plan and release 4.3.0 (I would really love to release 4.3.0
>> mid July max, so we need a plan).
>> 
>> Thoughts ?
>> 
>> Regards
>> JB

Re: [DISCUSSION] Apache Karaf 4.3.0 and Pax Web

Posted by Romain Manni-Bucau <rm...@gmail.com>.

Hi JB,

I see more issues using felix http:

1. it only supports felix today AFAIK which directly impacts the production
since then your monitoring/observability/instrumentation can be to redo so
for me it is way more impacting than the dev side - and more vicious
2. felix is a fatjar so you can't upgrade jetty when needed which is also a
big loss compared to not having R7 IMHO

How far is paxweb from R7? Not being 100% compliant is fine IMO while:
a. it can be manually switched to a compliant impl if required
b. there is no regression from previous version

Indeed just my 2cts,
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mar. 7 juil. 2020 à 11:18, Jean-Baptiste Onofre <jb...@nanthrax.net> a
écrit :

> Hi everyone,
>
> It’s more than a year now that we started Apache Karaf 4.3.0 release
> process, fully supporting OSGi R7.
>
> If the 4.3.0 distribution is ready, we are blocked by Pax Web. I’m
> concerned about that as R8 will be there and we will have issue in Pax Web
> again.
>
> Greg started a huge effort heading to Pax Web 8.0.0 with a large
> refactoring.
> However, the process is long and painful.
> So, I think it’s fair to have a discussion about the HTTP service in Karaf
> and "relationship" with Pax Web.
>
> I see three options for Karaf 4.3.0:
>
> 1. We are able to release Pax Web 8.0.0 (with R7 support) and so, no
> brainer, we can move forward.
> 2. Instead of using Pax Web by default, we "switch" to Felix HTTP by
> default. For the "pure" HTTP service, it will be transparent but it would
> have two impacts:
>   * the configuration changes (as obviously etc/org.ops4j.pax.web.cfg
> doesn’t exist anymore)
>   * users using WebContainer PaxWeb API instead of HTTP service won’t work
> 3. We consider that Pax Web as it is today is not flexible enough and too
> painful, and we start an even larger refactoring on Pax Web.
>
> The reason why I’m bringing this discussion on the mailing list: we really
> need a clear plan and release 4.3.0 (I would really love to release 4.3.0
> mid July max, so we need a plan).
>
> Thoughts ?
>
> Regards
> JB