Re: [glassfish-dev] [External] : Re: Where, if, to include javax.xml.bi

[Lukas Jungmann <lukas.jungmann@xxxxxxxxxx>]

Hi Steve,

On 3/16/21, 10:18 AM, "glassfish-dev on behalf of Steve Millidge (Payara)" <glassfish-dev-bounces@xxxxxxxxxxx on behalf of steve.millidge@xxxxxxxxxxx> wrote:

    Hi Lukas,

    (1) isn't in place although maybe you can run the jar through transformer and publish it in new maven coordinates or in one of your jars as part of the metro project?


this would be the best but it's not something I'm able to do in few hours :-(

    (3) is better than the others if (1) isn't possible.

I took this path and you can expect PR updating Metro to 3.0.1-b01 when I wake up (finally!)

    Has there been any upstream work on moving to Jakarta? 

I've already submitted PR to Santuario long time ago (and updated it today) but it does not look like they will accept it anytime soon.

thanks,
--lukas

    Steve


    -----Original Message-----
    From: glassfish-dev <glassfish-dev-bounces@xxxxxxxxxxx> On Behalf Of Lukas Jungmann
    Sent: 15 March 2021 22:39
    To: glassfish developer discussions <glassfish-dev@xxxxxxxxxxx>
    Subject: [glassfish-dev] Where, if, to include javax.xml.bind API?

    Hi,

       as I work through Metro & JDK 11 I've spotted one thing I'm not sure about the best way to resolve.

    Problem:
       Metro uses Apache Santuario for XML security which has not been updated to Jakarta namespace yet[1], so it depends on pre-jakarta XML Binding runtime implementation (and activation)  and thus also corresponding version of the API, the one with javax namespace. That API is there in JDK 8 and till now it could have been taken from there when needed. But on JDK 11, this fallback won't work and in the best case, relevant functionality just does not work, in the worst case, some TCK tests are impacted by inability of resolution of few classes somewhere during execution, in short they are just failing.

    Possible solutions:
    1) use Eclipse Transformer or some other similar solution for this - maybe that is already in place?

    2) keep the status quo  and hope no TCKs are failing due to this

    3) mitigate the risk by inclusion of "old" javax version of the APIs together with "old" xml binding runtime in the webservices-osgi.jar - inclusion of the API can be tricky since the "jakarta" artifact with "javax" classes needs to be used but one cannot use two different versions of the artifact with the same groupId/artifactId (I think I can get around this limitation); inclusion of both versions of runtime at once in one jar should be ok since the new runtime uses different packages (org.glassfish.jaxb vs com.sun.xml.bind). There are some colliding classes further down the road but that should not be that critical from the "old" xml binding runtime point of view.

    4) "somehow" put old APIs and runtime directly in GFs modules directory and made them visible to and consumable by the "outside world"

    I personally prefer going with option 3 - hiding the old API and runtime in place where it is needed but since this has impact on GF as such, I'd like to here you opinion(s), thoughts and/or advices on how to proceed with this. Or just tell me it's already solved (ie through option 1) and I'll be happy

    Thanks,
    --lukas


    [1]: https://urldefense.com/v3/__https://issues.apache.org/jira/browse/SANTUARIO-548__;!!GqivPVa7Brio!JL8rlbOCSarN8iVzPJJImVcIdWnKaXmAYdn1AV8KBunZHLRCDzbsjvVs7xEEfKs9nj8$ 

    _______________________________________________
    glassfish-dev mailing list
    glassfish-dev@xxxxxxxxxxx
    To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/glassfish-dev__;!!GqivPVa7Brio!JL8rlbOCSarN8iVzPJJImVcIdWnKaXmAYdn1AV8KBunZHLRCDzbsjvVs7xEE4MUgB7s$ 
    _______________________________________________
    glassfish-dev mailing list
    glassfish-dev@xxxxxxxxxxx
    To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/glassfish-dev__;!!GqivPVa7Brio!JL8rlbOCSarN8iVzPJJImVcIdWnKaXmAYdn1AV8KBunZHLRCDzbsjvVs7xEE4MUgB7s$