You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Colm O hEigeartaigh (Jira)" <ji...@apache.org> on 2020/06/10 15:27:00 UTC

[jira] [Commented] (CXF-8255) CXF should not depend on any particular implementation of JAXB

    [ https://issues.apache.org/jira/browse/CXF-8255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17130791#comment-17130791 ] 

Colm O hEigeartaigh commented on CXF-8255:
------------------------------------------

Please consider submitting a pull request.

> CXF should not depend on any particular implementation of JAXB
> --------------------------------------------------------------
>
>                 Key: CXF-8255
>                 URL: https://issues.apache.org/jira/browse/CXF-8255
>             Project: CXF
>          Issue Type: Improvement
>    Affects Versions: 3.3.6
>            Reporter: Ales Dolecek
>            Priority: Minor
>
> I belive that CXF should NOT depend on any particular implementation of JAXB. The project should update documentation at [https://cxf.apache.org/docs/jaxb.html] and explain that JAXB was deprecated in Java 9 and removed in Java 11. And what to do to get JAXB for their project.
>  
> It is *user freedom of choice* which JAXB implementation he decides to use. And it is therefore also his responsibility to provide one. If CXF pulls in dependency of any particular implementation it might get into conflict user provided implementation. Or with implementation pulled by other libraries, that also take away user right to choose. Or implementaion provided by J2EE server.
>  
> Most of the times everything works fine, but when the classloading is non trivial - like J2EE or even when some code uses Class.forName() it might happend that part of the code will use one Implementation and part of the code other. If that happens you can get very confusing behavior especially for someone who does not understand classloading in Java - which is not common knowledge.
>  
> CXF shall only depend on JAXB API with *provided* scope (Maven) or just require javax.xml.bind (OSGi) so it can compile. It may choose whatever implementation for testing. But it definitelly should not pull it's own JAXB implementation. Not even the API as the implementation shall either contain the API directly (better solution) or pull it as dependency (hence the provided scope).
>  
> It is also much better for CXF code base - since many JAXB implementations, pull in other libraries (like activation) and CXF might wrongly assume that they are generally available. If the user excludes JAXB implemntation chosen by CXF in favor of it's own - which might not pull in the dependencies it might lead to ClassNotFoundException at runtime. By depending solely on API you can avoid such problems. Also depending only on API will help with transition to modules introduced by Java 9.
>  
> The change shall be done in 3.4 release since users tend to read/test more when switching to higher minor version.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)