[
https://issues.apache.org/jira/browse/CXF-9041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Marwell updated CXF-9041:
----------------------------------
Description:
Found via: [https://github.com/OpenLiberty/open-liberty/issues/28414]
Excerpt from an IBM case:
{quote}[..] the post-update problem is caused by their third-party Web Service
implementation (Apache CXF 4.0). CXF had a similar issue with the XML Binding
specification look up algorithm, which they addressed by hard coding their own
dependency on the XML Binding Reference implementation. This is the code from
JAXBUtils.java:
{quote}
{code:java}
public static JAXBContext createContext(final Set<Class<?>> classes,
final Map<String, Object> map)
throws JAXBException {
JAXBContext ctx = null;
try {
ctx = AccessController.doPrivileged(new
PrivilegedExceptionAction<JAXBContext>() {
public JAXBContext run() throws Exception {
//This is a workaround for CXF-8675
Class<?> factoryClass =
ClassLoaderUtils.loadClass("org.glassfish.jaxb.runtime.v2.ContextFactory",
JAXBContextCache.class);
Method m = factoryClass.getMethod("createContext",
Class[].class, Map.class);
Object context = m.invoke(null, classes.toArray(new
Class<?>[0]), map);
return (JAXBContext) context;
}
});
} catch (PrivilegedActionException e2) {
if (e2.getException() instanceof JAXBException) {
JAXBException ex = (JAXBException) e2.getException();
throw ex;
} else {
throw new RuntimeException(e2.getException());
}
}
return ctx;
}
{code}
{quote}In the developers opinion, this was a terrible fix on Apache CXF's part,
since they've introduced a hard dependency on a specific implementation of XML
Binding, rather then allowing a user to provide their own implementation (which
is how its always been in the past, and its how our xmlWS-4.0 feaeture is
written).
{quote}
Confirmed by [~rmannibucau] (Regression):
!jaxb-no-fallback.png|width=1005,height=428!
was:
Found via: https://github.com/OpenLiberty/open-liberty/issues/28414
Excerpt from an IBM case:
{quote}[..] the post-update problem is caused by their third-party Web Service
implementation (Apache CXF 4.0). CXF had a similar issue with the XML Binding
specification look up algorithm, which they addressed by hard coding their own
dependency on the XML Binding Reference implementation. This is the code from
JAXBUtils.java:
{quote}
{code}
public static JAXBContext createContext(final Set<Class<?>> classes,
final Map<String, Object> map)
throws JAXBException {
JAXBContext ctx = null;
try {
ctx = AccessController.doPrivileged(new
PrivilegedExceptionAction<JAXBContext>() {
public JAXBContext run() throws Exception {
//This is a workaround for CXF-8675
Class<?> factoryClass =
ClassLoaderUtils.loadClass("org.glassfish.jaxb.runtime.v2.ContextFactory",
JAXBContextCache.class);
Method m = factoryClass.getMethod("createContext",
Class[].class, Map.class);
Object context = m.invoke(null, classes.toArray(new
Class<?>[0]), map);
return (JAXBContext) context;
}
});
} catch (PrivilegedActionException e2) {
if (e2.getException() instanceof JAXBException) {
JAXBException ex = (JAXBException) e2.getException();
throw ex;
} else {
throw new RuntimeException(e2.getException());
}
}
return ctx;
}
{code}
{quote}
In the developers opinion, this was a terrible fix on Apache CXF's part, since
they've introduced a hard dependency on a specific implementation of XML
Binding, rather then allowing a user to provide their own implementation (which
is how its always been in the past, and its how our xmlWS-4.0 feaeture is
written).
{quote}
Confirmed by [~rmannibucau] (Regression):
!jaxb-no-fallback.png!
> Regression: CXF will only accept org.glassfish.jaxb.runtime.v2.ContextFactory
> -----------------------------------------------------------------------------
>
> Key: CXF-9041
> URL: https://issues.apache.org/jira/browse/CXF-9041
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS, JAX-WS Runtime, Soap Binding, WS-* Components
> Environment: OpenLiberty 24.0.0.6
> JDK 17 (IBM Semeru)
> Reporter: Benjamin Marwell
> Priority: Critical
> Attachments: jaxb-no-fallback.png
>
>
> Found via: [https://github.com/OpenLiberty/open-liberty/issues/28414]
> Excerpt from an IBM case:
> {quote}[..] the post-update problem is caused by their third-party Web
> Service implementation (Apache CXF 4.0). CXF had a similar issue with the XML
> Binding specification look up algorithm, which they addressed by hard coding
> their own dependency on the XML Binding Reference implementation. This is the
> code from JAXBUtils.java:
> {quote}
> {code:java}
> public static JAXBContext createContext(final Set<Class<?>> classes,
> final Map<String, Object> map)
> throws JAXBException {
> JAXBContext ctx = null;
> try {
> ctx = AccessController.doPrivileged(new
> PrivilegedExceptionAction<JAXBContext>() {
> public JAXBContext run() throws Exception {
> //This is a workaround for CXF-8675
> Class<?> factoryClass =
> ClassLoaderUtils.loadClass("org.glassfish.jaxb.runtime.v2.ContextFactory",
> JAXBContextCache.class);
> Method m = factoryClass.getMethod("createContext",
> Class[].class, Map.class);
> Object context = m.invoke(null, classes.toArray(new
> Class<?>[0]), map);
> return (JAXBContext) context;
> }
> });
> } catch (PrivilegedActionException e2) {
> if (e2.getException() instanceof JAXBException) {
> JAXBException ex = (JAXBException) e2.getException();
> throw ex;
> } else {
> throw new RuntimeException(e2.getException());
> }
> }
> return ctx;
> }
> {code}
> {quote}In the developers opinion, this was a terrible fix on Apache CXF's
> part, since they've introduced a hard dependency on a specific implementation
> of XML Binding, rather then allowing a user to provide their own
> implementation (which is how its always been in the past, and its how our
> xmlWS-4.0 feaeture is written).
> {quote}
> Confirmed by [~rmannibucau] (Regression):
> !jaxb-no-fallback.png|width=1005,height=428!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
