Thanks Freeman for putting me back on track (of the discussion) :) Sorry for moving the discussion towards OSGi - just to summarize, I'm quite happy with the javax → jakarta migration, because it may be a positive impulse to clean up the state of JavaEE/JakartaEE in OSGi.
regards Grzegorz Grzybek pon., 8 lis 2021 o 18:47 Freeman Fang <[email protected]> napisał(a): > 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 > > > >>>>>>> > > > >>>>>>> > > > >>>>>> > > > >>>>> > > > >>>> > > > >> > > > >> > > > > > > > > >
