Hello
Interesting and very important discussion!
After all the years working with OSGi, one thing didn't change in my view
of it - OSGi is full of contrasts. I can think of at least 3 different ways
to make OSGi runtime like Karaf work with JakartaEE:
- ClassLoading hooks that do the transformation - ivory tower approach
without worrying about performance
- Exposing jakarta.* packages from system bundle
(${karaf.etc}/jre.properties) and (to be sure) boot delegation of entire
jakarta.* package namespace
- Simply installing Jakarta API jars as bundles (they're not as bad in
terms of OSGi manifests - I've even pushed some PRs merged to
jakarta.transactions API) and let them coexist with javax.* packages -
that's what OSGi is for after all.
The contrasts in OSGi are in several aspects:
- OSGi is claimed to be µservices platform (remember the blog post from
2010? https://blog.osgi.org/2010/03/services.html) and is used as
application server
- When used as application server, every application "deployed" into it
can (by default) alter everything by replacing system services with custom,
higher-ranked services. There's no system–application separation here
(without special tricks)
- OSGi encourages careful design with carefully crafted manifests and
coupling by interfaces, while most of the applications rely on default
configuration of bnd/bundle-maven-plugin
- OSGi specifications are generally very well written, but when
something goes wrong in practice, devs switch to private-packaging and
re-exporting
- good enough amount of Maven Central libraries are OSGi aware, but
usually due to one-time contributions made in the golden age of OSGi,
because library authors usually "are not OSGi developers in day-to-day work"
So what's the solution here? I ... don't know. Recently I was working on
making Fuse product (custom Karaf distro) running consistently on both JDK
8 and JDK11+. Taking into account ext/endorsed libraries for JDK8 and
patch/opens/exports for JDK11 my decision was (after some consideration)
clear:
The more javax.* packages exported from system bundle and boot-delegated,
the better.
This was obvious for JAXB, JAX-RS, JWS, Activation APIs which were simply
removed after JDK11 (JDK9 still contained this java.ee module) - finally!
These should NEVER have been put into JavaSE in the first place.
But then, I decided to put several more APIs to system bundle.
So I'd rather do:
- drop the OSGi promise that everything should be a bundle and put
jakarta.* packages to boot/system classloader
- ${karaf.etc}/jre.properties should specify the exported packages in
desired versions
- boot-delegate jakarta.* packages
- Jakarta API jars don't have to be proper bundles with the above
- however, service discovery will be a problem if the Jakarta APIs are
boot delegated. Karaf's locator/activator can help
- JAXB is fine for Karaf, because Karaf requires JAXB implementation
anyway (feature parsing)
- After all - how many different Jakarta API implementations there
are to choose from? IMO the original promise of JavaEE (now
JakartaEE) that
one can switch implementations every day didn't work well - you
have to be
aware of the implementation and (IMO) you need particular
implementation be
part of the design/implementation process
- having jakarta.* packages boot delegated will make all
dependency="true" bundles not installed with Karaf features, so no
duplicate API JARs in the classspace
Why boot-delegation/system bundle? Simply because if we treat Karaf (or any
other OSGi runtime) as application server, one of the most important
application server "features" is that your deployed application (WAR in
JavaEE or set of bundles in OSGi) should NOT include any fundamental
library (like API JARs).
I agree with JBO, that Karaf's spec feature (feature sets) can be used for
this - there could be "javaee8" feature (set) and "jakartaee9" feature
(set). Karaf (now looking at the µservices side of Karaf - it's like with
wave/particle duality of matter - Karaf is an application server AND a
bunch of equal bundles at the same time...) should allow you to choose
desired feature, while not constraining you. Karaf "official" distro could
be any (but only one) flavor though.
I'm afraid there's no clear solution that satisfies everyone - in either
case someone will be unhappy - either the purists that want everything to
be a bundle or the pragmatists who would like to choose their own JakartaEE
API JARs. Someone may prefer canonical jakarta.* groupId but someone may be
forced to use SMX/Geronimo bundles which are more OSGi friendly
(locators/activators)...
Also, Karaf is not the only project based on an OSGi runtime...
kind regards
Grzegorz Grzybek
sob., 6 lis 2021 o 18:51 JB Onofré <[email protected]> napisał(a):
> Hi
>
> My point is to include wrap spec bundle as SMX for those spec features.
>
> It should fix our issue in flexible way.
>
> Regards
> JB
>
> > Le 6 nov. 2021 à 17:59, Freeman Fang <[email protected]> a écrit :
> >
> > Hi JB,
> >
> > Thanks for jumping on this.
> >
> > But to be honest, I doubt this spec feature can provide such flexibility.
> >
> > Currently in Karaf we actually expose javax packages from system bundle
> 0,
> > and those classes are from bootstrap classloader. We also use endorse
> > mechanism(for JDK8) and patch-module(for JDK9+) to use our revised
> > APIs(from karaf specs module), so in most cases, the specs in different
> > karaf features.xml are not installed because they have dependency="true"
> > flag, and the packages/versions from system bundle 0 can already meet the
> > OSGi resolution. We need use those APIs from bootstrap classloader and
> > system bundle 0 because Karaf itself needs to use some javax APIs and we
> > need to ensure those fundamental API classes only have one copy in the
> OSGi
> > container, otherwise we can run into ClassCastExceptions during runtime.
> So
> > AFAICS, once Karaf is started, it can work with javax. API or jakarta.
> API
> > is determined. And it's not a trivial task to keep both javax. API or
> > jakarta. API in a certain Karaf version,so this be a "this" or "that"
> > choice.
> >
> > Best Regards
> > Freeman
> >
> >> On Sat, Nov 6, 2021 at 11:31 AM JB Onofré <[email protected]> wrote:
> >>
> >> Hi guys
> >>
> >> What I proposed and started is to provide spec feature. We can have both
> >> javax and Jakarta spec features and use the one needed.
> >>
> >> That’s probably the most flexible approach.
> >>
> >> FYI Karaf 4.3.3 already includes specs feature repo that we can extend.
> >>
> >> Regards
> >> JB
> >>
> >>>> Le 6 nov. 2021 à 16:17, Freeman Fang <[email protected]> a
> écrit :
> >>>
> >>> Hi Romain,
> >>>
> >>> Thanks for the feedback, and please see my comments inline below.
> >>>
> >>>> On Sat, Nov 6, 2021 at 9:53 AM Romain Manni-Bucau <
> >> [email protected]>
> >>>> wrote:
> >>>>
> >>>> If it helps: maven shade plugin rewrited manifest meta using
> relocation
> >>>> making it often osgi friendly at some header exception and several
> >> apache
> >>>> projects use that so can actually be trivial after all to run cxf +
> >> spec in
> >>>> osgi if all are relocated properly short term.
> >>>>
> >>> Yes, I know maven-shade-plugin, Apache Servicemix bundles/specs
> projects
> >>> use it to OSGi-fy(or simply fix OSGGi headers) non-OSGi jars. But I
> can't
> >>> follow how this can help cxf-module-jarkarta.jar(using jakarta package
> >> API)
> >>> to work in Karaf container short term, especially considering that
> Karaf
> >>> ecosystem(karaf and other projects deployed in Karaf) still lingers
> with
> >>> javax API for a while.
> >>>
> >>>>
> >>>> Long term guess geronimo would likely be a natural asf home (joined
> with
> >>>> karaf for some serious "common" spec jars).
> >>>>
> >>>
> >>>
> >>> Historically we have such specs jars from Apache Servicemix ;), and we
> >> can
> >>> also add jakarta api there if needed
> >>>
> >>> Side note: as an cxf consumer a common cxf pain is the transitive spec
> >>>> jars, making them all provided or optional would make their
> integration
> >>>> smoother so can be a low hanging fruit in this track too.
> >>>>
> >>> We surely can discuss it further along the track.
> >>>
> >>> And guys,
> >>> What I want to express is that if feasible, we can get Jim's PR in if
> >> it's
> >>> a good start along the track, even though it's not a full support of
> all
> >>> features from CXF. So that we can get feedback earlier(like run JAXRS
> TCK
> >>> and see the result). Moving forward, everyone is free to make whatever
> >>> contribution on cxf-module-jarkarta jars to make CXF works in more
> >>> runtimes(OSGi, SpringBoot, you name it).
> >>>
> >>> Just my 2 cents.
> >>>
> >>> Have a nice weekend!
> >>> Freeman
> >>>
> >>>
> >>>
> >>>> Le sam. 6 nov. 2021 à 14:02, Freeman Fang <[email protected]> a
> >>>> écrit :
> >>>>
> >>>>> Hi Guys,
> >>>>>
> >>>>> In Karaf features, we use specs bundles created from Apache
> Servicemix,
> >>>>> which are using javax package name. Also in Apache Karaf, there is a
> >>>> specs
> >>>>> module which is also using javax package name. Given the Karaf is a
> >>>>> universal OSGi container and needs to support a lot more
> >> projects(Camel,
> >>>>> Activemq, OPS4J, etc) outside CXF, I don't think the ecosystem around
> >>>> Karaf
> >>>>> can move to jakarta package name that fast.
> >>>>>
> >>>>> So I think we can start the jakarta package rename work from a
> >> restricted
> >>>>> scope in CXF , say, Jim's PR can skip the OSGi support for now(as we
> >>>> still
> >>>>> have cxf released jars without the jakarta classifier which have full
> >>>> OSGi
> >>>>> support). We can see if this transformer plugin solution will work
> out
> >>>> for
> >>>>> non-OSGi scenarios first.
> >>>>>
> >>>>> Moving forward, we can add OSGi support for CXF jakarta package name
> >> jars
> >>>>> once the ecosystem in OSGi matures. IMO, ideally the best time to
> >> support
> >>>>> CXF work with jakarta ee 9.1/10.0 API in OSGi container is when
> jakarta
> >>>> ee
> >>>>> 9.1/10.0 API becomes the first citizen in CXF(we use jarkarta package
> >>>> name
> >>>>> in CXF but not the transform solution)
> >>>>>
> >>>>> Best Regards
> >>>>> Freeman
> >>>>>
> >>>>> On Sat, Nov 6, 2021 at 3:07 AM Romain Manni-Bucau <
> >> [email protected]
> >>>>>
> >>>>> wrote:
> >>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> There are several Karaf users, as well as aries-jaxrs which use CXF
> in
> >>>>>> OSGi.
> >>>>>> Not sure SMix will but Geronimo#specs still targets Jakarta and if
> >>>> needed
> >>>>>> we can create all the artifacts there - it is one of the reason we
> >>>> didn't
> >>>>>> stop doing specs, cause Jakarta does not care of OSGi, even if now
> the
> >>>>>> licensing is better.
> >>>>>>
> >>>>>> Romain Manni-Bucau
> >>>>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> >>>>>> <https://rmannibucau.metawerx.net/> | Old Blog
> >>>>>> <http://rmannibucau.wordpress.com> | Github <
> >>>>>> https://github.com/rmannibucau> |
> >>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> >>>>>> <
> >>>>>>
> >>>>>
> >>>>
> >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Le sam. 6 nov. 2021 à 03:00, Andriy Redko <[email protected]> a
> écrit
> >> :
> >>>>>>
> >>>>>>> Hi Jim,
> >>>>>>>
> >>>>>>> Thank you for working on this. I actually don't know about
> >>>> ServiceMix,
> >>>>>> but
> >>>>>>> over the
> >>>>>>> years I have seen CXF being used inside OSGi containers along with
> >>>>> Apache
> >>>>>>> Camel, as
> >>>>>>> well as independently, for JAX-RS / JAX-WS services. I am certain
> >>>> that
> >>>>>>> @Freeman could
> >>>>>>> provide more broader context. Thank you!
> >>>>>>>
> >>>>>>> Best Regards,
> >>>>>>> Andriy Redko
> >>>>>>>
> >>>>>>> JM> Hi Andriy,
> >>>>>>> JM> Sorry for the long delay about the work for
> >>>>>>> JM> https://github.com/apache/cxf/pull/855
> >>>>>>> JM> I tried to find some information about ServiceMix's plan about
> >>>>>> jakarta
> >>>>>>> JM> namespace support. I guess ServiceMix is the only user of CXF's
> >>>>> OSGI
> >>>>>>> stuff,
> >>>>>>> JM> right ? Any other downstream projects which consume CXF's OSGI
> >>>>>> thing ?
> >>>>>>>
> >>>>>>> JM> Thanks,
> >>>>>>> JM> Jim
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>
> >>
>
>
