Description
We've got a broken setup, that is unlikely to be caused by the problem described herein. Via the stacktrace, however, we did find a possible improvement for Jetty 12.0.14 using EE8. No wars are going to be won by this, but still, it might be a useful improvement.
Given this stacktrace:
org.eclipse.jetty.ee8.webapp.WebAppContext - Failed startup of context oeje8w.WebAppContext@310ac970{ROOT,/,file:///home/guus/SourceCode/IgniteRealtime/Openfire/distribution/target/distribution-base/plugins/admin/webapp/,false}{/home/guus/SourceCode/IgniteRealtime/Openfire/distribution/target/distribution-base/plugins/admin/webapp}
java.lang.NullPointerException: Cannot invoke "java.nio.file.Path.getFileName()" because "path" is null
at org.eclipse.jetty.util.FileID.isClassFile(FileID.java:369) ~[?:?]
at org.eclipse.jetty.ee8.annotations.AnnotationParser.parse(AnnotationParser.java:489) ~[?:?]
at org.eclipse.jetty.ee8.annotations.AnnotationConfiguration$ParserTask.call(AnnotationConfiguration.java:170) ~[?:?]
at org.eclipse.jetty.util.ExceptionUtil.call(ExceptionUtil.java:333) ~[?:?]
at org.eclipse.jetty.util.ExceptionUtil$MultiException.callAndCatch(ExceptionUtil.java:270) ~[?:?]
at org.eclipse.jetty.ee8.annotations.AnnotationConfiguration.lambda$scanForAnnotations$0(AnnotationConfiguration.java:488) ~[?:?]
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:979) ~[?:?]
at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.doRunJob(QueuedThreadPool.java:1209) ~[?:?]
at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1164) ~[?:?]
at java.lang.Thread.run(Thread.java:840) [?:?]
It appears that there's room for improvement in AnnotationParser
:
public void parse(final Set<? extends Handler> handlers, Resource r) throws Exception {
if (r == null)
return;
if (FileID.isJavaArchive(r.getPath())) {
parseJar(handlers, r);
return;
}
if (r.isDirectory()) {
parseDir(handlers, r);
return;
}
if (FileID.isClassFile(r.getPath())) {
parseClass(handlers, null, r.getPath());
}
if (LOG.isDebugEnabled())
LOG.warn("Resource not able to be scanned for classes: {}", r);
}
If the Resource argument is null
, the method immediately short-circuits to false
. If the Resource is not null
, but has a null
path, then a NPE is thrown in only the last check (in FileID.isClassFile()
). FileID.isJavaArchive()
isn't bothered by having a null argument, but isClassFile
is.
I'd suggest to make this behavior consistent, either by short-circuiting in the first check, or by adjusting the implementation of FileID.isClassFile()
Metadata
Metadata
Assignees
Type
Projects
Status