You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Andriy Redko <dr...@gmail.com> on 2021/11/06 02:00:19 UTC
Re: Jakarta namespace and OSGI
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
Re: Jakarta namespace and OSGI
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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é <jb...@nanthrax.net> 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 <fr...@gmail.com> 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é <jb...@nanthrax.net> 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 <fr...@gmail.com> 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 <
> >> rmannibucau@gmail.com>
> >>>> 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 <fr...@gmail.com> 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 <
> >> rmannibucau@gmail.com
> >>>>>
> >>>>> 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 <dr...@gmail.com> 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
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>
> >>
>
>
Re: Jakarta namespace and OSGI
Posted by Grzegorz Grzybek <gr...@gmail.com>.
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 <fr...@gmail.com> 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 <gr...@gmail.com>
> 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é <jb...@nanthrax.net> 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 <fr...@gmail.com> 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é <jb...@nanthrax.net> 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 <fr...@gmail.com> 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 <
> > > >> rmannibucau@gmail.com>
> > > >>>> 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 <freeman.fang@gmail.com
> >
> > 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 <
> > > >> rmannibucau@gmail.com
> > > >>>>>
> > > >>>>> 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 <dr...@gmail.com> 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
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > > >>
> > > >>
> > >
> > >
> >
>
Re: Jakarta namespace and OSGI
Posted by Freeman Fang <fr...@gmail.com>.
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 <gr...@gmail.com>
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é <jb...@nanthrax.net> 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 <fr...@gmail.com> 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é <jb...@nanthrax.net> 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 <fr...@gmail.com> 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 <
> > >> rmannibucau@gmail.com>
> > >>>> 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 <fr...@gmail.com>
> 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 <
> > >> rmannibucau@gmail.com
> > >>>>>
> > >>>>> 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 <dr...@gmail.com> 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
> > >>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>
> > >>
> >
> >
>
Re: Jakarta namespace and OSGI
Posted by JB Onofré <jb...@nanthrax.net>.
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 <rm...@gmail.com> 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 <gr...@gmail.com> 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é <jb...@nanthrax.net> 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 <fr...@gmail.com> 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é <jb...@nanthrax.net> 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 <fr...@gmail.com> 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 <
>>>>> rmannibucau@gmail.com>
>>>>>>> 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 <fr...@gmail.com>
>> 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 <
>>>>> rmannibucau@gmail.com
>>>>>>>>
>>>>>>>> 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 <dr...@gmail.com> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>>
Re: Jakarta namespace and OSGI
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <gr...@gmail.com> 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é <jb...@nanthrax.net> 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 <fr...@gmail.com> 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é <jb...@nanthrax.net> 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 <fr...@gmail.com> 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 <
> > >> rmannibucau@gmail.com>
> > >>>> 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 <fr...@gmail.com>
> 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 <
> > >> rmannibucau@gmail.com
> > >>>>>
> > >>>>> 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 <dr...@gmail.com> 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
> > >>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>
> > >>
> >
> >
>
Re: Jakarta namespace and OSGI
Posted by Grzegorz Grzybek <gr...@gmail.com>.
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é <jb...@nanthrax.net> 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 <fr...@gmail.com> 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é <jb...@nanthrax.net> 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 <fr...@gmail.com> 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 <
> >> rmannibucau@gmail.com>
> >>>> 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 <fr...@gmail.com> 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 <
> >> rmannibucau@gmail.com
> >>>>>
> >>>>> 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 <dr...@gmail.com> 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
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>
> >>
>
>
Re: Jakarta namespace and OSGI
Posted by JB Onofré <jb...@nanthrax.net>.
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 <fr...@gmail.com> 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é <jb...@nanthrax.net> 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 <fr...@gmail.com> 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 <
>> rmannibucau@gmail.com>
>>>> 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 <fr...@gmail.com> 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 <
>> rmannibucau@gmail.com
>>>>>
>>>>> 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 <dr...@gmail.com> 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>>
Re: Jakarta namespace and OSGI
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Maven-shade-plugin has transformers, some are about manifest and they
rewrite the manifest with relocation rules so imports/exports can transform
javax to jakarta so long story short, if desired you can have a javax code
which runs in OSGi and a shade with relocation which runs in OSGi but with
jakarta package for (almost) free (just a transformer to adjust if the
default is not sufficient). Sounds like the best quick win to me- before
the big bang.
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 à 17:59, Freeman Fang <fr...@gmail.com> 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é <jb...@nanthrax.net> 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 <fr...@gmail.com> 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 <
> > rmannibucau@gmail.com>
> > >> 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 <fr...@gmail.com> 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 <
> > rmannibucau@gmail.com
> > >>>
> > >>> 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 <dr...@gmail.com> 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
> > >>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> >
>
Re: Jakarta namespace and OSGI
Posted by Freeman Fang <fr...@gmail.com>.
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é <jb...@nanthrax.net> 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 <fr...@gmail.com> 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 <
> rmannibucau@gmail.com>
> >> 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 <fr...@gmail.com> 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 <
> rmannibucau@gmail.com
> >>>
> >>> 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 <dr...@gmail.com> 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
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
>
>
Re: Jakarta namespace and OSGI
Posted by JB Onofré <jb...@nanthrax.net>.
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 <fr...@gmail.com> 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 <rm...@gmail.com>
>> 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 <fr...@gmail.com> 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 <rmannibucau@gmail.com
>>>
>>> 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 <dr...@gmail.com> 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
>>>>>
>>>>>
>>>>
>>>
>>
Re: Jakarta namespace and OSGI
Posted by Freeman Fang <fr...@gmail.com>.
On Sat, Nov 6, 2021 at 12:37 PM Andriy Redko <dr...@gmail.com> wrote:
> Hey guys,
>
> I am also all in to reduce the scope to begin with (leaving full OSGi
> support
> to later), but I think the OSGi manifests should be at least in line with
> the
> rewritten jakarta.* packages / versions. At worst, we could strip the OSGi
> instructions
> from the manifests altogether, it is better than providing incomplete or
> inconsistent
> ones. Hope it makes sense. Thanks for the great feedback.
>
Thanks Andriy!
I don't see any simple way to rewrite jakarta.* packages / versions OSGi
headers for cxf-module-jakarta jars. Because maven-bundle-plugin will scan
cxf source code to determine used API package name on the fly(though this
behaviour is configurable), if cxf source code still actually uses javax.
package, it's not easy to get OSGi headers right. If others know how to do
it along with the transformer plugin, please point it out.
Yes, probably we should strip off the OSGi headers from cxf-module-jakarta
jars to make it less confusing.
Freeman
>
> Best Regards,
> Andriy Redko
>
> FF> Hi Romain,
>
> FF> Thanks for the feedback, and please see my comments inline below.
>
> FF> On Sat, Nov 6, 2021 at 9:53 AM Romain Manni-Bucau <
> rmannibucau@gmail.com>
> FF> 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.
>
> FF> Yes, I know maven-shade-plugin, Apache Servicemix bundles/specs
> projects
> FF> use it to OSGi-fy(or simply fix OSGGi headers) non-OSGi jars. But I
> can't
> FF> follow how this can help cxf-module-jarkarta.jar(using jakarta package
> API)
> FF> to work in Karaf container short term, especially considering that
> Karaf
> FF> ecosystem(karaf and other projects deployed in Karaf) still lingers
> with
> FF> 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).
>
>
>
> FF> Historically we have such specs jars from Apache Servicemix ;), and we
> can
> FF> also add jakarta api there if needed
>
> FF> 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.
>
> FF> We surely can discuss it further along the track.
>
> FF> And guys,
> FF> What I want to express is that if feasible, we can get Jim's PR in if
> it's
> FF> a good start along the track, even though it's not a full support of
> all
> FF> features from CXF. So that we can get feedback earlier(like run JAXRS
> TCK
> FF> and see the result). Moving forward, everyone is free to make whatever
> FF> contribution on cxf-module-jarkarta jars to make CXF works in more
> FF> runtimes(OSGi, SpringBoot, you name it).
>
> FF> Just my 2 cents.
>
> FF> Have a nice weekend!
> FF> Freeman
>
>
>
> >> Le sam. 6 nov. 2021 à 14:02, Freeman Fang <fr...@gmail.com> 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 <
> rmannibucau@gmail.com
> >> >
> >> > 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 <dr...@gmail.com> 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
> >> > > >
> >> > > >
> >> > >
> >> >
>
>
Re: Jakarta namespace and OSGI
Posted by Andriy Redko <dr...@gmail.com>.
Hey guys,
I am also all in to reduce the scope to begin with (leaving full OSGi support
to later), but I think the OSGi manifests should be at least in line with the
rewritten jakarta.* packages / versions. At worst, we could strip the OSGi instructions
from the manifests altogether, it is better than providing incomplete or inconsistent
ones. Hope it makes sense. Thanks for the great feedback.
Best Regards,
Andriy Redko
FF> Hi Romain,
FF> Thanks for the feedback, and please see my comments inline below.
FF> On Sat, Nov 6, 2021 at 9:53 AM Romain Manni-Bucau <rm...@gmail.com>
FF> 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.
FF> Yes, I know maven-shade-plugin, Apache Servicemix bundles/specs projects
FF> use it to OSGi-fy(or simply fix OSGGi headers) non-OSGi jars. But I can't
FF> follow how this can help cxf-module-jarkarta.jar(using jakarta package API)
FF> to work in Karaf container short term, especially considering that Karaf
FF> ecosystem(karaf and other projects deployed in Karaf) still lingers with
FF> 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).
FF> Historically we have such specs jars from Apache Servicemix ;), and we can
FF> also add jakarta api there if needed
FF> 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.
FF> We surely can discuss it further along the track.
FF> And guys,
FF> What I want to express is that if feasible, we can get Jim's PR in if it's
FF> a good start along the track, even though it's not a full support of all
FF> features from CXF. So that we can get feedback earlier(like run JAXRS TCK
FF> and see the result). Moving forward, everyone is free to make whatever
FF> contribution on cxf-module-jarkarta jars to make CXF works in more
FF> runtimes(OSGi, SpringBoot, you name it).
FF> Just my 2 cents.
FF> Have a nice weekend!
FF> Freeman
>> Le sam. 6 nov. 2021 à 14:02, Freeman Fang <fr...@gmail.com> 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 <rmannibucau@gmail.com
>> >
>> > 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 <dr...@gmail.com> 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
>> > > >
>> > > >
>> > >
>> >
Re: Jakarta namespace and OSGI
Posted by Freeman Fang <fr...@gmail.com>.
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 <rm...@gmail.com>
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 <fr...@gmail.com> 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 <rmannibucau@gmail.com
> >
> > 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 <dr...@gmail.com> 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
> > > >
> > > >
> > >
> >
>
Re: Jakarta namespace and OSGI
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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.
Long term guess geronimo would likely be a natural asf home (joined with
karaf for some serious "common" spec jars).
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.
Le sam. 6 nov. 2021 à 14:02, Freeman Fang <fr...@gmail.com> 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 <rm...@gmail.com>
> 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 <dr...@gmail.com> 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
> > >
> > >
> >
>
Re: Jakarta namespace and OSGI
Posted by Freeman Fang <fr...@gmail.com>.
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 <rm...@gmail.com>
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 <dr...@gmail.com> 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
> >
> >
>
Re: Jakarta namespace and OSGI
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <dr...@gmail.com> 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
>
>