[
https://issues.apache.org/jira/browse/CXF-8255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh updated CXF-8255:
-------------------------------------
Fix Version/s: (was: 3.4.0)
> 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)
