Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] What does it mean for Jakarta EE 9 Full Platform that Jakarta RESTful Web Services are depending on (optional) Jakarta XML Binding in Jakarta EE 9? 


On 9/21/20 9:23 AM, Andy McCright wrote:
> So, jax-rs requires jaxb when building.  Building the api?  Building jersey?  both?
Building the API for sure - I'm not sure about Jersey, but I would think that it would also require the dependency if it is implementing the Link (and especially the Link.JaxbAdapter inner class) API.
Does the resulting api binary have a dependency on jaxb?  If it does, 
then that's a problem.
Yes it does.  But users should not notice the dependency unless they explicitly use the Link class.  Since the vast majority of RESTful WS function is available without using that class, I would claim that it is an /optional/ dependency.
I'm not clear on this "Link" class.  I guess this gets back to the
previous question.  If the dependency on jaxb is soft and dynamic, and the only time that the dependency is required is when this "Link" class is utilized, then we're getting closer to workable solution.
It is certainly a hard dependency from the Link.JaxbAdapter inner class.  It is not soft/dynamic from the perspective that it is loaded reflectively and handled gracefully if not available.  If a user attempts to use this class without having Jakarta XML Binding in their classpath, they will see a nasty ClassNotFoundException/NoClassDefFoundError like Scott reported.
Another question is whether other classes that reference the Link class directly or indirectly (e.g. ClientResponseContext, ClientResponseFilter, Configurable, ...) also need to be considered optional within Jakarta Restful Web Services.
https://github.com/eclipse-ee4j/jaxrs-api/issues/906#issuecomment-694865420 mentions ^ question about these classes. 




Is this "Link" class marked "optional" as part of the API?
The javadoc has the wording I mentioned previously.  Is there a more official way to mark the class as "optional"? 



Does the TCK test this "Link" class and are those tests marked optional?
The TCK does use the Link class, and afaict those tests are not currently marked optional.
We are looking at allowing the TCK tests that directly use the Link class to be skipped via "-Dkeywords=!xml_binding" via https://github.com/eclipse-ee4j/jakartaee-tck/pull/511 (for https://github.com/eclipse-ee4j/jakartaee-tck/issues/491).
In the Jakarta RESTful WS spec, there are requirements for implementations when other Jakarta APIs are available.  For example, an implementation is required to supply a built-in JSON-B provider if the JSON-B APIs are available.  I don't know how (or if) this is tested in the TCK, but IMO we should use a similar mechanism to test the Link class - basically something like JUnit's "assume" method - i.e. assumeThat(canLoadJakartaXMLBindingAPIs()); That should prevent the test from failing if the environment does not have XML Binding, but should perform the test if it does.
In case it helps, https://github.com/eclipse-ee4j/jakartaee-tck/blob/980f006a0d09852be82a11fce15c1ecf72dbb39b/src/com/sun/ts/lib/harness/keyword.properties#L154 shows the "xml_binding" keyword that we added for each test that directly references the Link class.
We do need to understand if other TCK test classes that indirectly depend on the Link class (e.g. perhaps loaded due to a Java bytecode constant pool reference) need to be considered optional as well. 

Scott



Hope this helps,

Andy
On Fri, Sep 18, 2020 at 7:49 AM Kevin Sutter <sutter@xxxxxxxxxx <mailto:sutter@xxxxxxxxxx>> wrote: 

    Hi Andy,
    Thanks for the background information.  But, I'm just not familiar
    enough with the jax-rs architecture to know if the solution is
    sufficient.

    >  So, what this means is that RESTful WS depends on XML Binding API at
    build time.  The Link class is rarely used in user applications, but
    when it is, users must ensure that their runtime environment
    includes XML Binding APIs and an implementation.  For most users,
    they will not need a runtime dependency on XML Binding.

    So, jax-rs requires jaxb when building.  Building the api?  Building
    jersey?  both?

    Does the resulting api binary have a dependency on jaxb?  If it
    does, then that's a problem.

    I'm not clear on this "Link" class.  I guess this gets back to the
    previous question.  If the dependency on jaxb is soft and dynamic,
    and the only time that the dependency is required is when this
    "Link" class is utilized, then we're getting closer to workable
    solution.  Is this "Link" class marked "optional" as part of the
    API?  Does the TCK test this "Link" class and are those tests marked
    optional?

    Bottom line is that with jaxb being marked as an Optional
    technology, then the standard jax-rs and jakarta ee runtime can not
    have a hard, non-optional dependency on jaxb.

    ---------------------------------------------------
    Kevin Sutter
    STSM, MicroProfile and Jakarta EE architect @ IBM
    e-mail: sutter@xxxxxxxxxx <mailto:sutter@xxxxxxxxxx>     Twitter:
      @kwsutter
    phone: tl-553-3620 (office), 507-253-3620 (office)
    LinkedIn: https://www.linkedin.com/in/kevinwsutter



    From: Andy McCright <j.andrew.mccright@xxxxxxxxx
    <mailto:j.andrew.mccright@xxxxxxxxx>>
    To: jakartaee-platform developer discussions
    <jakartaee-platform-dev@xxxxxxxxxxx
    <mailto:jakartaee-platform-dev@xxxxxxxxxxx>>
    Cc: Kevin Sutter <sutter@xxxxxxxxxx <mailto:sutter@xxxxxxxxxx>>
    Date: 09/17/2020 20:26
    Subject: [EXTERNAL] Re: [jakartaee-platform-dev] What does it mean
    for Jakarta EE 9 Full Platform that Jakarta RESTful Web Services are
    depending on (optional) Jakarta XML Binding in Jakarta EE 9?
    ------------------------------------------------------------------------



    Hi All, The dependency has been there since JAX-RS 2.0.  When we had
    discussed this...
    *This Message Is From an External Sender*
    This message came from outside your organization.


    Hi All,

    The dependency has been there since JAX-RS 2.0.  When we had
    discussed this previously we decided that we could not remove the
    dependency as that would be a breaking change. Instead we decided
    that user applications that use this API are responsible for
    providing the Jakarta XML Binding APIs and implementation
(either through their own app or through the vendor app server). Back in March, I added these lines to the Javadocs: 

           * Note that usage of this class requires the Jakarta XML
    Binding API and an implementation. The Jakarta RESTful Web
           * Services implementation is not required to provide these
    dependencies.

    So, what this means is that RESTful WS depends on XML Binding API at
    build time.  The Link class is rarely used in user applications, but
    when it is, users must ensure that their runtime environment
    includes XML Binding APIs and an implementation. For most users,
    they will not need a runtime dependency on XML Binding.

    At the time we discussed this, it was approved by the RESTful WS
    project and at least consensus reached by the platform committee,
    but if we don't like that answer now, I'm open to considering other
    options.

    Hope this helps,

    Andy

    On Thu, Sep 17, 2020 at 2:20 PM Scott Marlow <_smarlow@redhat.com_
    <mailto:smarlow@xxxxxxxxxx>> wrote:



    On 9/17/20 2:41 PM, Kevin Sutter wrote:
    > According to the early discussions on this topic, the JAX-RS team  had
    > indicated they would be changing their spec, api, javadoc (whatever)  to
    > allow for jaxb to be optional.  It looks like the javadoc (at  least)
> still indicates that jaxb is required. That has to change (at a > minimum).  Once this is properly delineated as optional, then any 
    > corresponding TCKs will need to be marked optional as well.  Which  would
    > then flow into the Platform TCK...
    _
    __https://github.com/eclipse-ee4j/jaxrs-api/issues/906_is for updating
    jakarta.ws.rs.core.Link to not depend on optional (for Jakarta EE 9)
    jakarta.xml.bind (JAXB).  The issue includes a link to this mailing
    list
    conversation.

    Scott
> > --------------------------------------------------- 
    > Kevin Sutter
    > STSM, MicroProfile and Jakarta EE architect @ IBM
    > e-mail:  _sutter@xxxxxx.com_ <mailto:sutter@xxxxxxxxxx>    Twitter:  @kwsutter
    > phone: tl-553-3620 (office), 507-253-3620 (office)
    > LinkedIn: _https://www.linkedin.com/in/kevinwsutter_
> > > > From: Scott Marlow <_smarlow@redhat.com_ <mailto:smarlow@xxxxxxxxxx>> > To: jakartaee-platform developer discussions > <_jakartaee-platform-dev@eclipse.org_ 
    <mailto:jakartaee-platform-dev@xxxxxxxxxxx>>
    > Date: 09/17/2020 13:26
    > Subject: [EXTERNAL] [jakartaee-platform-dev] What does it mean for
> Jakarta EE 9 Full Platform that Jakarta RESTful Web Services are > depending on (optional) Jakarta XML Binding in Jakarta EE 9? 
    > Sent by: _jakartaee-platform-dev-bounces@eclipse.org_
    <mailto:jakartaee-platform-dev-bounces@xxxxxxxxxxx>
    > ------------------------------------------------------------------------
> > > > Hi, > > It looks like Jakarta RESTful Web Services SPEC API depends on 
    > (optional) Jakarta XML Binding.  See line 28 in jaxrs-api [1]  (line 551
    > is also interesting).
> > How can Jakarta XML Binding be optional [2] if Jakarta RESTful Web 
    > Services depends on them?
> > Thanks Alwin for mentioning this on jakartaee-tck/issues/491 [3]! > > Scott > > [1] 
    > _https://github.com/eclipse-ee4j/jaxrs-api/blob/master/jaxrs-api/src/main/java/jakarta/ws/rs/core/Link.java#L28_
> > [2] 
    > _https://jakarta.ee/specifications/platform/9/platform-spec-9-SNAPSHOT.html#xml-binding-3-0-requirements-optional_
> > [3] 
    > _https://github.com/eclipse-ee4j/jakartaee-tck/issues/491#issuecomment-694324790_
> > _______________________________________________ 
    > jakartaee-platform-dev mailing list
    > _jakartaee-platform-dev@eclipse.org_
    <mailto: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@eclipse.org_
    <mailto: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@eclipse.org_
    <mailto: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

Back to the top