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 <francois.pa...@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 > fpa...@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 <rmannibu...@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 <j...@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 > >
