Ales Dolecek created CXF-8255:
---------------------------------
Summary: 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
Fix For: 3.4.0
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)
