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