Agree. That’s why I still think specs features is a better approach. Just need clean OSGi headers (which is not a big deal with Geronimo or smx if needed).
Regards JB > Le 8 nov. 2021 à 07:58, Romain Manni-Bucau <[email protected]> a écrit : > > Well, fact is that with jakarta namespace boot delegation is never needed - > javax was a bit different and harder to solve. > So if we want an OSGi solution it must not be in boot delegation - > otherwise you defeat OSGi and can only support a single version which is > only part of the full story - usages ;). > > So think there are a few points: > > 1. Where to do spec jars. Indeed i'm biased but tempted to say this is why > Geronimo#specs are (still) there, if you all decide it is Karaf role then > we'll drop this Geronimo role at some point, > 2. What to do with CXF build before the big bang? Indeed I think shade > enables to solve it elegantly where eclipse transformer is less powerful > and requires more build hacks but at the end it is to CXF core dev to pick > a solution they will maintain ;) > > 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 lun. 8 nov. 2021 à 07:44, Grzegorz Grzybek <[email protected]> a >> écrit : >> >> 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>>> >>> >>> >>
