You mean make the Java ServiceLoader "just work" in OSGi when the API JAR and an Impl JAR are loaded as bundles in the OSGi Framework? There is a specification for that already called Service Loader Mediator [1]. While that is possible, it requires a framework extension that performs aspect weaving around calls sites to the Java ServiceLoader so that it can do "the right thing" for discovering the implementation in OSGi. This is a bit messy to do and not exactly well defined what the woven aspect would do [2], but there is an implementation of it available called SPI fly [3]. The OSGi specification project is looking at better ways to make that work [4], but I think we need some additional support from the Java ServiceLoader to allow the OSGi Framework to hook into the ServiceLoader for discovery.
At any rate, you have answered my questions on the topic for the EE 10 release. I don't see a need to address this issue for EE 10 at this time.
Thanks.
Tom
----- Original message -----
From: "Lukas Jungmann" <lukas.jungmann@xxxxxxxxxx>
Sent by: "jakartaee-platform-dev" <jakartaee-platform-dev-bounces@xxxxxxxxxxx>
To: jakartaee-platform-dev@xxxxxxxxxxx
Cc:
Subject: Re: [jakartaee-platform-dev] [External] : Re: : Reviewing Activation for Jakarta 10 - Hardcoding Glassfish reflection?
Date: Wed, Jan 5, 2022 1:35 AM
On 1/4/22 9:49 PM, Thomas Watson wrote:
> I see, so is issue
> https://github.com/eclipse-ee4j/jakartaee-platform/issues/360
> <https://github.com/eclipse-ee4j/jakartaee-platform/issues/360> about
> pulling a general utility into jakarta similar to the small hk2 library
> so that specs can depend on that directly for the OSGi service loader
> lookup support instead of reflectively calling the hk2 library?
Is such, likely new, general utility library really required? Wouldn't
it be sufficient to use some OSGI-specific metadata in manifest probably
generated during the build letting OSGi runtime do the work for us instead?
thanks,
--lukas
>
> Tom
>
> ----- Original message -----
> From: "Lukas Jungmann" <lukas.jungmann@xxxxxxxxxx>
> Sent by: "jakartaee-platform-dev"
> <jakartaee-platform-dev-bounces@xxxxxxxxxxx>
> To: jakartaee-platform-dev@xxxxxxxxxxx
> Cc:
> Subject: Re: [jakartaee-platform-dev] [External] : Reviewing
> Activation for Jakarta 10 - Hardcoding Glassfish reflection?
> Date: Tue, Jan 4, 2022 2:37 PM
> On 1/4/22 8:37 PM, Thomas Watson wrote:
> > Upfront I have to apologize that I know this is late in the
> process. I
> > also am unsure how others reviewing ballots handle reviewing all the
> > different changes when making the decision to approve a ballot ...
> > With that said, I started looking into what changed for
> Activation for
> > EE 10 in order to cast the IBM ballot. It seems the main theme
> for the
> > 2.1 Activation release is to split the implementation out of the API
> > artifact. This makes sense to me. But I have concerns with how the
> > implementation gets discovered. In particular I am looking at
> this PR:
> > https://github.com/eclipse-ee4j/jaf/pull/85
> <https://github.com/eclipse-ee4j/jaf/pull/85>
>
> > <https://github.com/eclipse-ee4j/jaf/pull/85
> <https://github.com/eclipse-ee4j/jaf/pull/85>>
> > The PR is about handling impl lookup in an OSGi env. Presumably
> so that
> > it can work with a compliant implementation loaded as a bundle in
> > glassfish. But the solution seems to be directly dependent on
> glassfish
> > itself be reflecting on some class
> > called org.glassfish.hk2.osgiresourcelocator.ServiceLoader
> > A quick look at the 2.1 proposed Activation specification does
> not seem
> > to specify exactly how implementations are discovered in this
> case. But
> > I have to say it seems inappropriate to hardcode a glassfish
> reference
> > (even if reflectively) to discover implementations in OSGi. Can
> this be
> > done more generally to work in OSGi?
>
> since https://github.com/eclipse-ee4j/jakartaee-platform/issues/360
> <https://github.com/eclipse-ee4j/jakartaee-platform/issues/360> has
> not been targeted for EE10, the approach taken in few other specs has
> been taken; see also minutes from the platform call around Feb 16 2021.
>
> Note that org.glassfish.hk2:osgi-resource-locator is NOT GlassFish, it
> is a small library created by the HK2 project bringing serviceloader
> support to OSGi. One can, for example, use this library in Eclipse
> RCP/Equinox based app even without GlassFish.
>
> thanks,
> --lukas
>
> >
> > Tom
> >
> >
> >
> > _______________________________________________
> > jakartaee-platform-dev mailing list
> > jakartaee-platform-dev@xxxxxxxxxxx
> > To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
> <https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev>
>
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
> <https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev>
>
>
>
>
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
