Hi Grzegorz, The discussion has become more Karaf/OSGi centric and actually isn't strongly connected with the original context(Jim's PR which is an experiment to use eclipse transformer plugin to make CXF source code work with Jakarta EE 9.1 API without changing CXF code, and OSGi support isn't a priority in that PR). So I will keep Jim's PR related comments in that PR only and let this more karaf/OSGi centric discussion keep going.
I totally agree that we should go with the boot-delegation/system bundle way, so many lessons learned from past decade and I'd say the specs API is the most tricky part from OSGi container(At least the Karaf based OSGi container which we verify CXF/CAME/AMQ can work on it, and I'd call it Karaf ecosystem) And if we go the boot-delegation/system bundle way, we have to ensure we have all jakarta. package name or all javax. package when starting Karaf, in this case the specs features actually can't kick in. And I believe we should avoid having two sets of fundamental APIs in the same Karaf container(well, another lesson learned in the real world, OSGi is too flexible, sometimes we may want to restrict this flexibility) . And we also need to consider when the so-called Karaf ecosystem can move to jakarta. API, and we need to sync the same behaviour across all karaf targeted projects. Just my 2 cents. Best Regards Freeman On Mon, Nov 8, 2021 at 1:44 AM Grzegorz Grzybek <[email protected]> wrote: > Hello > > Interesting and very important discussion! > > After all the years working with OSGi, one thing didn't change in my view > of it - OSGi is full of contrasts. I can think of at least 3 different ways > to make OSGi runtime like Karaf work with JakartaEE: > > - ClassLoading hooks that do the transformation - ivory tower approach > without worrying about performance > - Exposing jakarta.* packages from system bundle > (${karaf.etc}/jre.properties) and (to be sure) boot delegation of entire > jakarta.* package namespace > - Simply installing Jakarta API jars as bundles (they're not as bad in > terms of OSGi manifests - I've even pushed some PRs merged to > jakarta.transactions API) and let them coexist with javax.* packages - > that's what OSGi is for after all. > > The contrasts in OSGi are in several aspects: > > - OSGi is claimed to be µservices platform (remember the blog post from > 2010? https://blog.osgi.org/2010/03/services.html) and is used as > application server > - When used as application server, every application "deployed" into it > can (by default) alter everything by replacing system services with > custom, > higher-ranked services. There's no system–application separation here > (without special tricks) > - OSGi encourages careful design with carefully crafted manifests and > coupling by interfaces, while most of the applications rely on default > configuration of bnd/bundle-maven-plugin > - OSGi specifications are generally very well written, but when > something goes wrong in practice, devs switch to private-packaging and > re-exporting > - good enough amount of Maven Central libraries are OSGi aware, but > usually due to one-time contributions made in the golden age of OSGi, > because library authors usually "are not OSGi developers in day-to-day > work" > > So what's the solution here? I ... don't know. Recently I was working on > making Fuse product (custom Karaf distro) running consistently on both JDK > 8 and JDK11+. Taking into account ext/endorsed libraries for JDK8 and > patch/opens/exports for JDK11 my decision was (after some consideration) > clear: > > The more javax.* packages exported from system bundle and boot-delegated, > the better. > > This was obvious for JAXB, JAX-RS, JWS, Activation APIs which were simply > removed after JDK11 (JDK9 still contained this java.ee module) - finally! > These should NEVER have been put into JavaSE in the first place. > But then, I decided to put several more APIs to system bundle. > > So I'd rather do: > > - drop the OSGi promise that everything should be a bundle and put > jakarta.* packages to boot/system classloader > - ${karaf.etc}/jre.properties should specify the exported packages in > desired versions > - boot-delegate jakarta.* packages > - Jakarta API jars don't have to be proper bundles with the above > - however, service discovery will be a problem if the Jakarta APIs are > boot delegated. Karaf's locator/activator can help > - JAXB is fine for Karaf, because Karaf requires JAXB implementation > anyway (feature parsing) > - After all - how many different Jakarta API implementations there > are to choose from? IMO the original promise of JavaEE (now > JakartaEE) that > one can switch implementations every day didn't work well - you > have to be > aware of the implementation and (IMO) you need particular > implementation be > part of the design/implementation process > - having jakarta.* packages boot delegated will make all > dependency="true" bundles not installed with Karaf features, so no > duplicate API JARs in the classspace > > Why boot-delegation/system bundle? Simply because if we treat Karaf (or any > other OSGi runtime) as application server, one of the most important > application server "features" is that your deployed application (WAR in > JavaEE or set of bundles in OSGi) should NOT include any fundamental > library (like API JARs). > > I agree with JBO, that Karaf's spec feature (feature sets) can be used for > this - there could be "javaee8" feature (set) and "jakartaee9" feature > (set). Karaf (now looking at the µservices side of Karaf - it's like with > wave/particle duality of matter - Karaf is an application server AND a > bunch of equal bundles at the same time...) should allow you to choose > desired feature, while not constraining you. Karaf "official" distro could > be any (but only one) flavor though. > > I'm afraid there's no clear solution that satisfies everyone - in either > case someone will be unhappy - either the purists that want everything to > be a bundle or the pragmatists who would like to choose their own JakartaEE > API JARs. Someone may prefer canonical jakarta.* groupId but someone may be > forced to use SMX/Geronimo bundles which are more OSGi friendly > (locators/activators)... > > Also, Karaf is not the only project based on an OSGi runtime... > > kind regards > Grzegorz Grzybek > > sob., 6 lis 2021 o 18:51 JB Onofré <[email protected]> napisał(a): > > > Hi > > > > My point is to include wrap spec bundle as SMX for those spec features. > > > > It should fix our issue in flexible way. > > > > Regards > > JB > > > > > Le 6 nov. 2021 à 17:59, Freeman Fang <[email protected]> a écrit > : > > > > > > Hi JB, > > > > > > Thanks for jumping on this. > > > > > > But to be honest, I doubt this spec feature can provide such > flexibility. > > > > > > Currently in Karaf we actually expose javax packages from system bundle > > 0, > > > and those classes are from bootstrap classloader. We also use endorse > > > mechanism(for JDK8) and patch-module(for JDK9+) to use our revised > > > APIs(from karaf specs module), so in most cases, the specs in different > > > karaf features.xml are not installed because they have > dependency="true" > > > flag, and the packages/versions from system bundle 0 can already meet > the > > > OSGi resolution. We need use those APIs from bootstrap classloader and > > > system bundle 0 because Karaf itself needs to use some javax APIs and > we > > > need to ensure those fundamental API classes only have one copy in the > > OSGi > > > container, otherwise we can run into ClassCastExceptions during > runtime. > > So > > > AFAICS, once Karaf is started, it can work with javax. API or jakarta. > > API > > > is determined. And it's not a trivial task to keep both javax. API or > > > jakarta. API in a certain Karaf version,so this be a "this" or "that" > > > choice. > > > > > > Best Regards > > > Freeman > > > > > >> On Sat, Nov 6, 2021 at 11:31 AM JB Onofré <[email protected]> wrote: > > >> > > >> Hi guys > > >> > > >> What I proposed and started is to provide spec feature. We can have > both > > >> javax and Jakarta spec features and use the one needed. > > >> > > >> That’s probably the most flexible approach. > > >> > > >> FYI Karaf 4.3.3 already includes specs feature repo that we can > extend. > > >> > > >> Regards > > >> JB > > >> > > >>>> Le 6 nov. 2021 à 16:17, Freeman Fang <[email protected]> a > > écrit : > > >>> > > >>> Hi Romain, > > >>> > > >>> Thanks for the feedback, and please see my comments inline below. > > >>> > > >>>> On Sat, Nov 6, 2021 at 9:53 AM Romain Manni-Bucau < > > >> [email protected]> > > >>>> wrote: > > >>>> > > >>>> If it helps: maven shade plugin rewrited manifest meta using > > relocation > > >>>> making it often osgi friendly at some header exception and several > > >> apache > > >>>> projects use that so can actually be trivial after all to run cxf + > > >> spec in > > >>>> osgi if all are relocated properly short term. > > >>>> > > >>> Yes, I know maven-shade-plugin, Apache Servicemix bundles/specs > > projects > > >>> use it to OSGi-fy(or simply fix OSGGi headers) non-OSGi jars. But I > > can't > > >>> follow how this can help cxf-module-jarkarta.jar(using jakarta > package > > >> API) > > >>> to work in Karaf container short term, especially considering that > > Karaf > > >>> ecosystem(karaf and other projects deployed in Karaf) still lingers > > with > > >>> javax API for a while. > > >>> > > >>>> > > >>>> Long term guess geronimo would likely be a natural asf home (joined > > with > > >>>> karaf for some serious "common" spec jars). > > >>>> > > >>> > > >>> > > >>> Historically we have such specs jars from Apache Servicemix ;), and > we > > >> can > > >>> also add jakarta api there if needed > > >>> > > >>> Side note: as an cxf consumer a common cxf pain is the transitive > spec > > >>>> jars, making them all provided or optional would make their > > integration > > >>>> smoother so can be a low hanging fruit in this track too. > > >>>> > > >>> We surely can discuss it further along the track. > > >>> > > >>> And guys, > > >>> What I want to express is that if feasible, we can get Jim's PR in if > > >> it's > > >>> a good start along the track, even though it's not a full support of > > all > > >>> features from CXF. So that we can get feedback earlier(like run JAXRS > > TCK > > >>> and see the result). Moving forward, everyone is free to make > whatever > > >>> contribution on cxf-module-jarkarta jars to make CXF works in more > > >>> runtimes(OSGi, SpringBoot, you name it). > > >>> > > >>> Just my 2 cents. > > >>> > > >>> Have a nice weekend! > > >>> Freeman > > >>> > > >>> > > >>> > > >>>> Le sam. 6 nov. 2021 à 14:02, Freeman Fang <[email protected]> > a > > >>>> écrit : > > >>>> > > >>>>> Hi Guys, > > >>>>> > > >>>>> In Karaf features, we use specs bundles created from Apache > > Servicemix, > > >>>>> which are using javax package name. Also in Apache Karaf, there is > a > > >>>> specs > > >>>>> module which is also using javax package name. Given the Karaf is a > > >>>>> universal OSGi container and needs to support a lot more > > >> projects(Camel, > > >>>>> Activemq, OPS4J, etc) outside CXF, I don't think the ecosystem > around > > >>>> Karaf > > >>>>> can move to jakarta package name that fast. > > >>>>> > > >>>>> So I think we can start the jakarta package rename work from a > > >> restricted > > >>>>> scope in CXF , say, Jim's PR can skip the OSGi support for now(as > we > > >>>> still > > >>>>> have cxf released jars without the jakarta classifier which have > full > > >>>> OSGi > > >>>>> support). We can see if this transformer plugin solution will work > > out > > >>>> for > > >>>>> non-OSGi scenarios first. > > >>>>> > > >>>>> Moving forward, we can add OSGi support for CXF jakarta package > name > > >> jars > > >>>>> once the ecosystem in OSGi matures. IMO, ideally the best time to > > >> support > > >>>>> CXF work with jakarta ee 9.1/10.0 API in OSGi container is when > > jakarta > > >>>> ee > > >>>>> 9.1/10.0 API becomes the first citizen in CXF(we use jarkarta > package > > >>>> name > > >>>>> in CXF but not the transform solution) > > >>>>> > > >>>>> Best Regards > > >>>>> Freeman > > >>>>> > > >>>>> On Sat, Nov 6, 2021 at 3:07 AM Romain Manni-Bucau < > > >> [email protected] > > >>>>> > > >>>>> wrote: > > >>>>> > > >>>>>> Hi, > > >>>>>> > > >>>>>> There are several Karaf users, as well as aries-jaxrs which use > CXF > > in > > >>>>>> OSGi. > > >>>>>> Not sure SMix will but Geronimo#specs still targets Jakarta and if > > >>>> needed > > >>>>>> we can create all the artifacts there - it is one of the reason we > > >>>> didn't > > >>>>>> stop doing specs, cause Jakarta does not care of OSGi, even if now > > the > > >>>>>> licensing is better. > > >>>>>> > > >>>>>> 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 sam. 6 nov. 2021 à 03:00, Andriy Redko <[email protected]> a > > écrit > > >> : > > >>>>>> > > >>>>>>> Hi Jim, > > >>>>>>> > > >>>>>>> Thank you for working on this. I actually don't know about > > >>>> ServiceMix, > > >>>>>> but > > >>>>>>> over the > > >>>>>>> years I have seen CXF being used inside OSGi containers along > with > > >>>>> Apache > > >>>>>>> Camel, as > > >>>>>>> well as independently, for JAX-RS / JAX-WS services. I am certain > > >>>> that > > >>>>>>> @Freeman could > > >>>>>>> provide more broader context. Thank you! > > >>>>>>> > > >>>>>>> Best Regards, > > >>>>>>> Andriy Redko > > >>>>>>> > > >>>>>>> JM> Hi Andriy, > > >>>>>>> JM> Sorry for the long delay about the work for > > >>>>>>> JM> https://github.com/apache/cxf/pull/855 > > >>>>>>> JM> I tried to find some information about ServiceMix's plan > about > > >>>>>> jakarta > > >>>>>>> JM> namespace support. I guess ServiceMix is the only user of > CXF's > > >>>>> OSGI > > >>>>>>> stuff, > > >>>>>>> JM> right ? Any other downstream projects which consume CXF's > OSGI > > >>>>>> thing ? > > >>>>>>> > > >>>>>>> JM> Thanks, > > >>>>>>> JM> Jim > > >>>>>>> > > >>>>>>> > > >>>>>> > > >>>>> > > >>>> > > >> > > >> > > > > >
