Thanks for all your detailed analysis, comments and ideas. Moving the osgi stuff to a seperate repo like github.com/apache/cxf-osgi is a good idea. I'll look at this refactoring along with spring after resolving some javax->jakarta test failures. I'll push the change to the working branch: https://github.com/apache/cxf/tree/CXF-8371.
Thanks, Jim On Fri, Mar 4, 2022 at 6:42 PM Grzegorz Grzybek <gr.grzy...@gmail.com> wrote: > Hello > > As long-term OSGi supporter, I'd like to give my +1 for CXF 4.0.0 (?) with > OSGi bits moved to slower-paced github.com/apache/cxf-osgi repo (modules). > > As +Jim Ma <mail2ji...@gmail.com> pointed out, there are several "OSGi > integration points" in CXF with different (including none at all) > dependency in the whole Jakarta migration aspect. > > At lowest level there are 18 BundleActivators in 3.3.6 (sorry this is the > version I have nearby in my IDE). > Here are the activators that only register Blueprint namespace handlers: > – org.apache.cxf.binding.coloc.blueprint.Activator - > http://cxf.apache.org/binding/coloc namespace handler > – org.apache.cxf.binding.soap.blueprint.Activator - > http://cxf.apache.org/blueprint/bindings/soap namespace handler > – org.apache.cxf.clustering.blueprint.Activator - > http://cxf.apache.org/clustering namespace handler > – org.apache.cxf.frontend.blueprint.Activator - > http://cxf.apache.org/blueprint/simple namespace handler > – org.apache.cxf.jaxrs.blueprint.Activator - > http://cxf.apache.org/blueprint/jaxrs namespace handler > – org.apache.cxf.jaxrs.client.blueprint.Activator - > http://cxf.apache.org/blueprint/jaxrs-client namespace handler > – org.apache.cxf.jaxws.blueprint.Activator - > http://cxf.apache.org/blueprint/jaxws namespace handler > – org.apache.cxf.transport.http_jetty.osgi.HTTPJettyTransportActivator - > http://cxf.apache.org/transports/http-jetty/configuration namespace > handler > – org.apache.cxf.transport.http.netty.server.blueprint.Activator - > http://cxf.apache.org/transports/http-netty-server/configuration > namespace handler > – > org.apache.cxf.transport.http_undertow.osgi.HTTPUndertowTransportActivator > - http://cxf.apache.org/transports/http-undertow/configuration namespace > handlers > – org.apache.cxf.ws.addressing.blueprint.Activator - > http://cxf.apache.org/ws/addressing namespace handler > – org.apache.cxf.ws.policy.blueprint.Activator - > http://cxf.apache.org/policy, http://www.w3.org/ns/ws-policy, > http://www.w3.org/2006/07/ws-policy, ... namespace handler > – org.apache.cxf.ws.rm.blueprint.Activator - > http://cxf.apache.org/ws/rm/manager and > http://schemas.xmlsoap.org/ws/2005/02/rm/policy namespace handler > > One sample: > – minimalosgi.Activator - to register minimalosgi.SampleServlet() via > org.osgi.service.http.HttpService#registerServlet() > > These activators besides namespace handler registration, register > additional services. > – org.apache.cxf.bus.osgi.CXFActivator - > http://cxf.apache.org/blueprint/core, > http://cxf.apache.org/configuration/beans, ... namespace handlers, > org.osgi.service.cm.ManagedServiceFactory for org.apache.cxf.workqueues > FactoryPID, org.apache.cxf.bus.osgi.CXFExtensionBundleListener to handle > META-INF/cxf/bus-extensions.txt resources in all the bundles, ... > – org.apache.cxf.ext.logging.osgi.Activator - > org.apache.cxf.features.logging PID org.osgi.service.cm.ManagedService that > registers org.apache.cxf.ext.logging.LoggingFeature > – org.apache.cxf.transport.http.asyncclient.Activator - > org.apache.cxf.transport.http.async PID org.osgi.service.cm.ManagedService > to configure > org.apache.cxf.transport.http.asyncclient.AsyncHTTPConduitFactory in > reachable org.apache.cxf.Bus OSGi services > – org.apache.cxf.transport.http.osgi.HTTPTransportActivator - > http://cxf.apache.org/transports/http/configuration namespace handler, > org.apache.cxf.transport.http.DestinationRegistry OSGi service, > org.apache.cxf.transport.http.HTTPTransportFactory OSGi service, > org.osgi.service.http.HttpService tracker > > So wrt javax → jakarta migration (JavaEE8/JakartaEE8 → JakartaEE9+), there > are roughly three main aspects OSGi aspects to consider: > > 1. the OSGi parts that are not related to JakartaEE at all - blueprint > beans, blueprint namespace handlers > 2. the OSGi parts that rely on OSGi CMPN Rx 102 HttpService > specification (org.osgi.service.http.HttpService service) to register an > instance of org.apache.cxf.transport.servlet.CXFNonSpringServlet into the > underlying HttpService. This simply will not work at all and even won't > compile until OSGi CMPN specification moves entirely to JakartaEE > 3. the Karaf parts (commands, features) > > In theory, Blueprint parts are jakarta/javax dilemma agnostic. And even > (with big patience) it could work in an OSGi runtime, provided that CXF has > access to jakarta.servlet implementation bundles (Jetty 11, Tomcat 10, > Undertow with these extra *-jakarta jars), but because entire Karaf is > still based on javax (even Pax Web 8 uses javax.packages and servlet API > 4), it'd lead to a runtime with two different servlet container > implementations. Felix as OSGi core implementation is JakartaEE agnostic as > well, but still if one would like to configure CXF with Blueprint based on > Jakarta packages, entire "enterprise" OSGi part (CMPN specs) will be kind > of "ignored". It'd be like deploying a WAR with internal embedded servlet > container). > > I'm personally involved in Pax Web implementation, but even if there's > some work on OSGi enterprise side (https://github.com/osgi/osgi/issues/381), > I don't think that we'll have a full CMPN specification based on jakarta > packages only. > > Summarizing, I vote for CXF 4 release with javax → jakarta migration and > OSGi bits moved away. Even the blueprint parts could go away, because > integration testing these with Pax Exam could be a challenge after jakarta > migration. > Then I can gladly support the separated OSGi module. > > The one thing that could be left is the OSGi manifest parts. Same as it's > done in Camel3. > > However, ideally the work could be coordinated with Camel (Camel 4?) > people. > > kind regards > Grzegorz Grzybek > > czw., 3 mar 2022 o 14:58 Andriy Redko <drr...@gmail.com> napisał(a): > >> Hey guys, >> >> Also +1 to @Jim's suggestion, it would also unblock us on supporting >> latest JDKs >> promptly. Going with something like cxf-karaf integration in separate >> repository >> + release cycle makes sense to me. @Jim, I know you have started to look >> at >> Spring specifically, but tackling Karaf/OSGi would have more positive >> impact >> on unblocking migration I believe, ready to help you there, thank you! >> >> Best Regards, >> Andriy Redko >> >> RMB> Hi, >> >> RMB> Think it makes sense to split a bit CXF in a strong "core" leveraging >> RMB> minimal dependency (thinking strongly to servlet there which enables >> most >> RMB> of the runtimes from standalone to EE without forgetting >> microprofile and >> RMB> OSGi) and extract outside the core project all integrations which >> have >> RMB> different lifecycle (spring, OSGi and friends). >> RMB> Ultimately it can makes sense to move these integrations to the >> projects >> RMB> they belong to like aries-jaxrs, karaf and spring itself IMHO. >> >> RMB> Romain Manni-Bucau >> RMB> @rmannibucau <https://twitter.com/rmannibucau> | Blog >> RMB> <https://rmannibucau.metawerx.net/> | Old Blog >> RMB> <http://rmannibucau.wordpress.com> | Github < >> https://github.com/rmannibucau> | >> RMB> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book >> RMB> < >> https://www.packtpub.com/application-development/java-ee-8-high-performance >> > >> >> >> RMB> Le jeu. 3 mars 2022 à 14:10, Freeman Fang <freeman.f...@gmail.com> >> a écrit : >> >> >> Hi Jim, >> >> >> +1 to comment out OSGi bit for now so this won't block the whole >> Jakarta >> >> namespace migration work on CXF 4.x. And we can move fast without >> waiting >> >> for the OSGi spec to be JakartaEE9+ compatible. >> >> >> Going forward, I think we can extract the CXF OSGi/Karaf to a >> subproject of >> >> CXF, maybe with a different release cycle(like the relationship >> between >> >> CXF and cxf-xjc-utils), and this way our "core" CXF project can offer >> us >> >> more flexibility. >> >> >> Apache Camel has already done the similar thing >> >> https://github.com/apache/camel-karaf >> >> >> My 2 cents. >> >> Best Regards >> >> Freeman >> >> >> On Wed, Mar 2, 2022 at 9:40 PM Jim Ma <mail2ji...@gmail.com> wrote: >> >> >> > Hi, >> >> > I took more time to look at more things about Jakarta EE9.x support >> work >> >> > from last week. >> >> > Like Spring integration code, now OSGI relevant code is in different >> >> maven >> >> > modules : >> >> > >> >> > ./core/src/main/java/org/apache/cxf/bus/osgi >> >> > >> >> > >> >> >> ./rt/transports/http-jetty/src/main/java/org/apache/cxf/transport/http_jetty/osgi >> >> > ./rt/transports/http/src/main/java/org/apache/cxf/transport/http/osgi >> >> > ./rt/features/logging/src/main/java/org/apache/cxf/ext/logging/osgi >> >> > >> >> > >> >> >> ./rt/transports/http-undertow/src/main/java/org/apache/cxf/transport/http_undertow/osgi >> >> > >> >> > >> >> >> ./services/sts/systests/sts-osgi/src/main/java/org/apache/cxf/systest/sts/osgi >> >> > >> >> > When CXF moves to support the Jakarta namespace, these should be >> >> > changed to support Jakarta internally. But as Andriy Redko figured >> out on >> >> > the https://issues.apache.org/jira/browse/CXF-8371, the >> >> > OSGI dependency is one of these blockers. From [1] and [2] OSGI >> Jakarta >> >> > release won't >> >> > come in the near future. This made me think if CXF can support >> Jakarta >> >> > with OSGI as optional >> >> > for the first step. That means we temporally remove these OSGI code >> and >> >> > add it back when OSGI >> >> > Jakarta release is ready. What do you think ? >> >> > >> >> > [1] https://issues.apache.org/jira/browse/FELIX-6247 >> >> > [2] https://issues.apache.org/jira/browse/FELIX-6389 >> >> > >> >> > Thanks, >> >> > Jim >> >> > >> >>
