| Re: [jakartaee-platform-dev] : Reviewing Activation for Jakarta 10 - Hardcoding Glassfish reflection? |
----- 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>
> 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 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
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev