Hi JB, You mean wrap on jakarta official bundles? Can become tricky if you want to do it right with capabilities and resource rewriting (thinking to xml which can be handled by shade transformers) so maybe not an actual solution?
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 à 18:51, JB Onofré <[email protected]> a écrit : > 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 > >>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >> > >> > >
