Wann immer ich eine Steganwendung bereitstelle, stieß ich auf dieses Problem. Sieht aus, als wäre eine jar
oder eine Klasse defekt.
git
und maven
)~/.m2
und das erneute Erstellen sind nicht hilfreich.jar
defekt ist. jar tvf $every_jar
ausprobiert und nichts gefunden.Irgendwelche Ideen, wie kann ich das debuggen? Sieht wirklich geheimnisvoll aus und ich vermute, dass einige Dateien beschädigt werden.
Stack trace:
2014-10-21 13:29:25.123:WARN:oejw.WebAppContext:Failed startup of context o.e.j.w.WebAppContext{/,file:/XYZ/},/XYZ/webapps/root
javax.servlet.ServletException: jersey-serlvet
at org.Eclipse.jetty.servlet.ServletHolder.initServlet(ServletHolder.Java:553)
at org.Eclipse.jetty.servlet.ServletHolder.doStart(ServletHolder.Java:344)
at org.Eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.Java:64)
at org.Eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.Java:791)
at org.Eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.Java:265)
at org.Eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.Java:1242)
at org.Eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.Java:717)
at org.Eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.Java:494)
at org.Eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.Java:64)
at org.Eclipse.jetty.deploy.bindings.StandardStarter.processBinding(StandardStarter.Java:39)
at org.Eclipse.jetty.deploy.AppLifeCycle.runBindings(AppLifeCycle.Java:186)
at org.Eclipse.jetty.deploy.DeploymentManager.requestAppGoal(DeploymentManager.Java:494)
at org.Eclipse.jetty.deploy.DeploymentManager.addApp(DeploymentManager.Java:141)
at org.Eclipse.jetty.deploy.providers.ScanningAppProvider.fileAdded(ScanningAppProvider.Java:145)
at org.Eclipse.jetty.deploy.providers.ScanningAppProvider$1.fileAdded(ScanningAppProvider.Java:56)
at org.Eclipse.jetty.util.Scanner.reportAddition(Scanner.Java:615)
at org.Eclipse.jetty.util.Scanner.reportDifferences(Scanner.Java:540)
at org.Eclipse.jetty.util.Scanner.scan(Scanner.Java:403)
at org.Eclipse.jetty.util.Scanner.doStart(Scanner.Java:337)
at org.Eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.Java:64)
at org.Eclipse.jetty.deploy.providers.ScanningAppProvider.doStart(ScanningAppProvider.Java:121)
at org.Eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.Java:64)
at org.Eclipse.jetty.deploy.DeploymentManager.startAppProvider(DeploymentManager.Java:555)
at org.Eclipse.jetty.deploy.DeploymentManager.doStart(DeploymentManager.Java:230)
at org.Eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.Java:64)
at org.Eclipse.jetty.util.component.AggregateLifeCycle.doStart(AggregateLifeCycle.Java:81)
at org.Eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.Java:58)
at org.Eclipse.jetty.server.handler.HandlerWrapper.doStart(HandlerWrapper.Java:96)
at org.Eclipse.jetty.server.Server.doStart(Server.Java:282)
at org.Eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.Java:64)
at org.Eclipse.jetty.xml.XmlConfiguration$1.run(XmlConfiguration.Java:1274)
at Java.security.AccessController.doPrivileged(Native Method)
at org.Eclipse.jetty.xml.XmlConfiguration.main(XmlConfiguration.Java:1197)
at Sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at Sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.Java:57)
at Sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.Java:43)
at Java.lang.reflect.Method.invoke(Method.Java:606)
at org.Eclipse.jetty.start.Main.invokeMain(Main.Java:473)
at org.Eclipse.jetty.start.Main.start(Main.Java:615)
at org.Eclipse.jetty.start.Main.main(Main.Java:96)
gefolgt von
Caused by:
Java.lang.ArrayIndexOutOfBoundsException: 6241
at org.objectweb.asm.ClassReader.<init>(Unknown Source)
at org.objectweb.asm.ClassReader.<init>(Unknown Source)
at org.objectweb.asm.ClassReader.<init>(Unknown Source)
at com.Sun.jersey.spi.scanning.AnnotationScannerListener.onProcess(AnnotationScannerListener.Java:133)
at com.Sun.jersey.core.spi.scanning.uri.FileSchemeScanner$1.f(FileSchemeScanner.Java:86)
at com.Sun.jersey.core.util.Closing.f(Closing.Java:71)
at com.Sun.jersey.core.spi.scanning.uri.FileSchemeScanner.scanDirectory(FileSchemeScanner.Java:83)
at com.Sun.jersey.core.spi.scanning.uri.FileSchemeScanner.scanDirectory(FileSchemeScanner.Java:80)
at com.Sun.jersey.core.spi.scanning.uri.FileSchemeScanner.scanDirectory(FileSchemeScanner.Java:80)
at com.Sun.jersey.core.spi.scanning.uri.FileSchemeScanner.scan(FileSchemeScanner.Java:71)
at com.Sun.jersey.core.spi.scanning.PackageNamesScanner.scan(PackageNamesScanner.Java:223)
at com.Sun.jersey.core.spi.scanning.PackageNamesScanner.scan(PackageNamesScanner.Java:139)
at com.Sun.jersey.api.core.ScanningResourceConfig.init(ScanningResourceConfig.Java:80)
at com.Sun.jersey.api.core.PackagesResourceConfig.init(PackagesResourceConfig.Java:104)
at com.Sun.jersey.api.core.PackagesResourceConfig.<init>(PackagesResourceConfig.Java:78)
at com.Sun.jersey.api.core.PackagesResourceConfig.<init>(PackagesResourceConfig.Java:89)
at com.Sun.jersey.spi.container.servlet.WebComponent.createResourceConfig(WebComponent.Java:700)
Für deine 2 Fehler ..
javax.servlet.ServletException: jersey-serlvet
Das heißt, Sie haben einen Tippfehler in Ihrem WEB-INF/web.xml
Wie für diesen ..
Java.lang.ArrayIndexOutOfBoundsException: 6241
at org.objectweb.asm.ClassReader.<init>(Unknown Source)
Ich habe ähnliche gesehen, wenn Sie eine ältere Version von asm.jar
mit neuerem kompiliertem Java-Bytecode verwenden.
Stellen Sie sicher, dass Ihr asm.jar
(oder org.objectweb.asm.jar
) aktuell ist.
Es gibt ein etwas weniger häufiges Problem, bei dem die Klasse selbst schlecht ist. Manchmal bei Klassen, die in einem JDK (z. B. IBM) kompiliert und dann auf einem anderen Java (z. B. Sun/Oracle) ausgeführt werden.
Ein reales Beispiel dafür wäre der icu4j-2.6.1.jar
und sein com/ibm/icu/impl/data/LocaleElements_zh__PINYIN.class
-Jar-Eintrag .
Verwenden Sie eine neuere Version des Jetty-Maven-Plugins.
Weitere Informationen -> Fehler 419801 - Upgrade auf asm5 für jdk8
Bearbeiten Sie also Ihren pom.xml
wie folgt:
<plugin>
<groupId>org.Eclipse.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>9.3.0.M2</version>
</plugin>
Beachten Sie, dass die groupId " org.Eclipse.jetty " ist.
In meinem Fall verwende ich die ASM-Bibliotheksversion, die keinen Java 8-Lambda-Ausdruck unterstützt. Entweder Sie ändern die ASM-Bibliothek, um Java 8 zu unterstützen, oder ändern den Code.
In meinem Fall verwende ich Java 8-Lambda-Ausdruck für die Iteration und ersetzte ihn durch eine for-Schleife
Ich bin auf ein ähnliches Problem gestoßen, als ich alten Code behielt.
Servlet.init () für Servlet JerseyServlet hat Ausnahme ausgelöst. Typ Ausnahmebericht Nachricht Servlet.init () für Servlet JerseyServlet hat Ausnahme ausgelöst Beschreibung Der Server hat einen internen Fehler festgestellt, durch den die Anforderung nicht erfüllt werden konnte. Ausnahme javax.servlet.ServletException : Servlet.init () für Servlet JerseyServlet hat die Ausnahme Org.Apache.catalina.authenticator.AuthenticatorBase.invoke (AuthenticatorBase.Java:505) Org.Apache.catalina.valves.invoke ausgelöst (ErrorReportValve.Java:103) Org.Apache.catalina.valves.AccessLogValve.invoke (AccessLogValve.Java:956) Org.Apache.catalina.connector.CoyoteAdapter.service (CoyoteAdapter.Java.) : 423) Org.Apache.coyote.http11.AbstractHttp11Processor.process (AbstractHttp11Processor.Java:1079) Org.Apache.coyote.AbstractProtocol $ AbstractConnectionHandler.Joc. .___ _.] org.Apache.Tomcat.util.net.JIoEndpoint $ SocketProcessor.run (JIoEndpoint.Java:316) Java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.Java:1142) . ] Java.util.concurrent.ThreadPoolExecutor $ Worker.run (ThreadPoolExecutor.Java:617) Org.Apache.Tomcat.util.threads.TaskThread $ WrappingRunnable.run (TaskThread.Java:61) Java.lang.Thread.run (Thread.Java:745) Hauptursache Java.lang.ArrayIndexOutOfBoundsException Note Hinweis Die vollständige Stapelverfolgung der Wurzel Ursache ist in den Protokollen von Apache Tomcat/7.0.65 verfügbar.
Ich habe es behoben, indem der Umfang des Paketscans in web.xml reduziert wurde. Zum Beispiel wurde das Problem durch das Entfernen der unten aufgeführten package_with_too_many_classes im param-value-Tag behoben.
<servlet>
<servlet-name>JerseyServlet</servlet-name>
<servlet-class>com.Sun.jersey.spi.spring.container.servlet.SpringServlet</servlet-class>
<init-param>
<param-name>com.Sun.jersey.config.property.packages</param-name>
<param-value>package_with_too_many_classes;package_with_approciate_number_of_classes;org.codehaus.jackson.jaxrs</param-value>
</init-param>
<load-on-startup>2</load-on-startup>
</servlet>