minfrin
commented
1 year ago Managed to catch this in a debugger.
While returning the JAXB response, we hit this line which NPEs because _me is null.
Eventually this exception is silently swallowed by this code:
static Object lookupUsingOSGiServiceLoader(String factoryId, Logger logger) {
try {
// Use reflection to avoid having any dependency on ServiceLoader class
Class serviceClass = Class.forName(factoryId);
Class target = Class.forName(OSGI_SERVICE_LOADER_CLASS_NAME);
Method m = target.getMethod(OSGI_SERVICE_LOADER_METHOD_NAME, Class.class);
Iterator iter = ((Iterable) m.invoke(null, serviceClass)).iterator();
if (iter.hasNext()) {
Object next = iter.next();
logger.fine("Found implementation using OSGi facility; returning object [" +
next.getClass().getName() + "].");
return next;
} else {
return null;
}
} catch (IllegalAccessException |
InvocationTargetException |
ClassNotFoundException |
NoSuchMethodException ignored) {
[logged, but not visible in tomcat logging, so invisible]
logger.log(Level.FINE, "Unable to find from OSGi: [" + factoryId + "]", ignored);
[exception dropped on the floor here]
return null;
}
}Now we end up here:
Class ctxFactoryClass =
(Class) ServiceLoaderUtil.lookupUsingOSGiServiceLoader("javax.xml.bind.JAXBContext", logger);
if (ctxFactoryClass != null) {
return newInstance(classes, properties, ctxFactoryClass);
}
// else no provider found
logger.fine("Trying to create the platform default provider");
[we end up here, because everything is null]
return newInstance(classes, properties, ModuleUtil.DEFAULT_FACTORY_CLASS);Now we're in tomcat, here:
if (clazz == null) {
if (log.isDebugEnabled()) {
log.debug(" --> Returning ClassNotFoundException");
}
[we complain that com.sun.xml.bind.v2.ContextFactory is not found]
throw new ClassNotFoundException(name);
}Then we end up here in tomcat:
try {
clazz = findClass(name);
if (clazz != null) {
if (log.isDebugEnabled()) {
log.debug(" Loading class from local repository");
}
if (resolve) {
resolveClass(clazz);
}
return clazz;
}
} catch (ClassNotFoundException e) {
[we're here, and the exception is ignored]
// Ignore
}Now we're back in jersey-media-jaxb, and we reach here:
@Override
public final void writeTo(
Object t,
Class<?> type,
Type genericType,
Annotation[] annotations,
MediaType mediaType,
MultivaluedMap<String, Object> httpHeaders,
OutputStream entityStream) throws IOException {
try {
final Marshaller m = getMarshaller(type, mediaType);
final Charset c = getCharset(mediaType);
if (c != UTF8) {
m.setProperty(Marshaller.JAXB_ENCODING, c.name());
}
setHeader(m, annotations);
writeTo(t, mediaType, c, m, entityStream);
} catch (JAXBException ex) {
[we hit here]
throw new InternalServerErrorException(ex);
}
}The variable ex above is:
javax.xml.bind.JAXBException: Implementation of JAXB-API has not been found on module path or classpath.
- with linked exception:
[java.lang.ClassNotFoundException: com.sun.xml.bind.v2.ContextFactory]We eventually arrive here in jersey-server:
@Override
public void aroundWriteTo(final WriterInterceptorContext context) throws IOException, WebApplicationException {
try {
context.proceed();
} catch (final WebApplicationException | MappableException e) {
[we're here]
throw e;
} catch (final MessageBodyProviderNotFoundException nfe) {
throw new InternalServerErrorException(nfe);
} catch (final Exception e) {
throw new MappableException(e);
}
}The contents of e above are:
javax.ws.rs.InternalServerErrorException: HTTP 500 Internal Server ErrorAt this point we're thrown away all the exceptions that brought us to this point, and we fail on 500 with no explanation and no logging.
When an existing application is upgraded[1] to jersey v2.40, and an attempt is made to hit a previously-working endpoint using an Accept header of application/json, we get a correct response back.
If we change the Accept header to application/xml, tomcat throws a 500 internal server error as follows:
The exception that triggered the 500 is not logged anywhere, and without the exception we're stuck.
The dependency tree looks like this:
I suspect we're providing the wrong jaxb implementation.
There seem to be two different jaxb interfaces, and it's not clear which is correct:
[INFO] | - javax.xml.bind:jaxb-api:jar:2.3.1:compile [INFO] | - jakarta.xml.bind:jakarta.xml.bind-api:jar:2.3.3:compile
If we had the exception, we could probably fix this.
[1] We're in dependency hell.