AbstractAnnotationConfigDispatcherServletInitializer mit Jetty

9

Ich verwende Jetty 9.1.0.RC2 und Spring 4. Haben Sie AbstractAnnotationConfigDispatcherServletInitializer und versuchen Sie die Initialisierung mit:

zu starten %Vor%

Aber nicht erkennen:

%Vor%     
Matthew Campbell 05.03.2014, 16:50
quelle

1 Antwort

0

Dies ist ein häufiges Problem. Noch mehr Menschen stehen vor diesem Problem. Manchmal verursacht es einen Fehler oder manchmal gibt es nur info . Für Info gibt es kein Problem (genau wie eine Warnung). Für den Fehler gibt es viele Gründe, warum dieser Fehler auftritt. Ich versuche dir eine Lösung zu geben.

  1. Manchmal verursacht die Spring-Bibliothek und die jdk-Versionskonflikte diesen Fehler. Klassen sind in der niedrigeren Version von jdk gebaut und versuchen, im oberen Bereich zu laufen Version kann den Fehler verursachen. Dann müssen wir mit Eclipse ändern from Preferences \ Java \ Compiler Wir müssen die Compiler-Compliance einstellen Level: 1.7 "und" Generated .class files compatibility: 1.6 "," Quelle Kompatibilität: 1,6 ".
  2. Einige Leute wissen, dass log4j nicht zur Erfassung von Fehlern konfiguriert wurde Ausgabe, die Konfigurationsfehler in den Hintergrund warf.
  3. Wenn Sie maven verwenden, muss sich das WEB-INF-Verzeichnis in Ihrem befinden Web-App. Struktur wird src/main/webapp/WEB-INF Es löst auch dieses Problem.
  4. Wenn "Project -> Build Automatically" nicht ausgewählt ist. Sie können erzwingen die "m2e-wtp folder and contents" -Generation;

    "(rechte Maustaste     auf Ihrem Projekt) - & gt; Maven - & gt; Projekt aktualisieren ... "

  

Hinweis: stellen Sie sicher, dass       Die Option "Projekte löschen" ist nicht ausgewählt. Sonst der Inhalt von       Ziel / Klassen werden gelöscht und Sie sind zurück auf Platz eins.

  1. Fügen Sie dem Standardverzeichnis das WebROOT-Dateiverzeichnis hinzu Problem wird gelöst.

    properties- & gt; MyEclipse- & gt; Bereitstellung     Assembly- & gt; Hinzufügen

Ressourcenverknüpfung:

  1. Keine Spring WebApplicationInitializer-Typen im Klassenpfad gefunden
  2. INFO: Keine Spring WebApplicationInitializer-Typen im Klassenpfad gefunden
  3. nur ein Fehler: Keine Spring WebApplicationInitializer-Typen erkannt auf Klassenpfad

Für Kater,

  1. Wenn maven tomcat7 plugin hat, die JRE-Umgebung jedoch 1,6. Dann Dieses Problem tritt auf. Dann müssen Sie tomcat7 auf tomcat6 herabstufen oder upgrade jdk und jre version auf 1.7.
  2. Manchmal ist es notwendig, stop your tomcat . Dann clean the project , clean the server und run again your project . Manchmal machen Caches dies Problem. Nach diesem Weg kann es lösen.

Für JBOSS,

@ Sotirios Delimanolis eine sehr schöne Antwort gegeben. Das ist unten angegeben:

In einer typischen Servlet-Anwendung hätten Sie eine Deskriptordatei web.xml , um Ihre serlvets, filters, listeners, context params, security configuration, etc zu deklarieren. für Ihre Anwendung. Seit servlet 3.0 können Sie das meiste programmatisch machen.

Servlet 3.0 bietet die Schnittstelle ServletContainerInitializer , die Sie implementieren können. Ihr Servlet-Container sucht nach Ihrer Implementierung dieser Klasse in META-INF/services/javax.servlet.ServletContainerInitializer file, instanziiert sie und ruft ihre Methode onStartup() auf.

Spring hat WebApplicationInitializer eingerichtet oben auf dieser Schnittstelle als adapter/helper .

Sie benötigen entweder den Deskriptor web.xml oder eine Klasse, die WebApplicationInitializer implementiert, um Ihre Anwendung einzurichten und auszuführen.

Ressourcenverknüpfung:

  1. Jboss Keine Spring WebApplicationInitializer-Typen im Klassenpfad gefunden

Eine kurze Detailantwort wird unten mit Jetty gegeben:

Spring WebApplicationInitializer - wie es funktioniert und was schiefgehen kann

Start von Servlet-Kontexten ohne web.xml

Servlets von Release 3 können programmatisch ohne web.xml konfiguriert werden. Mit Spring und seiner Java-Konfiguration erstellen Sie eine Konfigurationsklasse, die org.springframework.web.WebApplicationInitializer implementiert. Spring findet automatisch alle Klassen, die diese Schnittstelle implementieren, und startet die entsprechenden Servlet-Kontexte. Genauer gesagt ist es nicht Frühling, der nach diesen Klassen sucht, es ist der Servlet-Container (z.B. Anlegesteg oder Kater). Die Klasse org.springframework.web.SpringServletContainerInitializer ist mit kommentiert %Code%) und implementiert @javax.servlet.annotation.HandlesTypes(WebApplicationInitializer.class Gemäß der Servlet 3-Spezifikation ruft der Container javax.servlet.ServletContainerInitializer für jede Klasse im Klassenpfad auf, der diese Schnittstelle implementiert, und liefert eine Gruppe von Klassen, wie in HandlesTypes

definiert

Startreihenfolge, wenn mehr als ein Kontext vorhanden ist

Wenn es mehr als eine Klasse gibt, die org.springframework.web.SpringServletContainerInitializer.onStartup(Set<Class<?>>, ServletContext) implementiert, kann die Reihenfolge, in der sie gestartet werden, mit der Annotation WebApplicationInitializer gesteuert werden.

Dinge, die schiefgehen können

Verschiedene Spring-Versionen im Klassenpfad

Wenn Sie im Klassenpfad verschiedene Versionen von org.springframework.core.Ordered haben, kann der Servlet-Container nach den Klassen suchen, die WebApplicationInitializer von Version 'A' implementieren, während Ihre Konfigurationsklassen WebApplicationInitializer von Version 'B' . Und dann werden deine Konfigurationsklassen nicht gefunden und die Sercletontexte werden nicht gestartet.

Unerwartete WebApplicationInitializer im Klassenpfad

Verpacken Sie keine WebApplicationInitializer in Gläser oder Kriege, die Sie später im Klassenpfad anderer Webanwendungen haben. Sie können gefunden und gestartet werden, wenn Sie es nicht erwarten. Das ist mir passiert, als ich WebApplicationInitializers mit Maven in Test-Gläser gepackt habe, die von anderen Tests wiederverwendet wurden.

Für viele Klassen im Klassenpfad

Der Servlet-Container muss den Klassenpfad durchsuchen, und je mehr Klassen, desto länger dauert es. Zumindest hat Jetty eine eingebaute Zeitüberschreitung, so dass Sie ein

erhalten können %Vor%
  

Die Lösung besteht darin, Anlegestellen mitzuteilen, welche Gläser gescannt werden sollen. Dies wird die   Start viel schneller und vermeidet die Zeitüberschreitung. In Maven kannst du es machen   so:

pom.xml

%Vor%

Spring-Protokollierung

Wenn Sie die Protokollierung konfiguriert haben, sollten Sie einen der folgenden Einträge in Ihrem Protokoll finden:

Wenn Spring keine WebApplicationInitializers findet, sehen Sie im Protokoll:

%Vor%

Wenn Spring mindestens ein WebApplicationInitializer findet, sehen Sie:

%Vor%     
SkyWalker 06.04.2016 16:52
quelle