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 > >> > > >
