Konnte nicht geladen oder instanziiert TagLibraryValidator Klasse: org.apache.taglibs.standard.tlv.JstlCoreTLV
So arbeite ich mit JSTL in OSGi, unter Gemini Laufzeit. Und ich bin immer folgende exception, wenn ich versuche, Zugriff auf den url zu meiner servlet
: -
SEVERE: Servlet.service() for servlet jsp threw exception
org.apache.jasper.JasperException: /WEB-INF/login.jsp (line: 3, column: 66) Unable to read TLD "META-INF/c.tld" from JAR file "file:/D:/OSGi%20Runtime/Gemini/gemini-web/dep/com.springsource.javax.servlet.jsp.jstl-1.2.0.v20110728.jar": org.apache.jasper.JasperException: Failed to load or instantiate TagLibraryValidator class: org.apache.taglibs.standard.tlv.JstlCoreTLV
Aber ich habe überprüft, dass ich bereits alle notwendigen bundles in meiner Laufzeit. Die entsprechenden Bündel, das ich habe ist: -
71 ACTIVE javax.servlet_3.0.0.v201103241009
73 ACTIVE javax.el_2.2.0.v201105051105
74 ACTIVE javax.servlet.jsp_2.2.0.v201103241009
75 ACTIVE com.springsource.javax.servlet.jsp.jstl_1.2.0.v20110728
121 ACTIVE com.springsource.org.apache.taglibs.standard_1.1.2.v20110517
Gibt es mehr bundles, aber diese sind diejenigen, die relevant sind. Also, ich kann nicht verstehen, was falsch gelaufen ist.
Aus der Spring Source Repository, von wo ich heruntergeladen habe, das bundle, es ist klar, dass, org.apache.taglibs.standard bundle - Bundle 121, enthält, die JstlCoreTLV class
.
Also, nicht sicher, was hier Los ist.
Hier mein JSP
header, die ich benutze (Nur für den Fall es relevant ist): -
<%@ taglib prefix = "c" uri = "http://java.sun.com/jsp/jstl/core" %>
Bin ich mit: -
Servlet 3.0
JSP 2.2
Gemini Runtime 2.1
JSTL 1.2.0
Update: -
Der unten beschriebene problem scheint gelöst zu sein, und jetzt ich bekomme keine Warnmeldung, wie unten dargestellt. Das war da, ich war mit den taglibs.standard_1.1.2
- (Bundle 121), die nicht kompatibel zu anderen. So, habe ich es entfernt, und die Warnung ging Weg.
So, Sie können ignorieren, was da ist, von hier aus auf. Aber Das problem oben ist immer noch da. Ich bin noch immer, dass JasperException
. Kann dies weiter helfen, wie das problem-Domäne reduziert sich jetzt ein wenig, Dank der wertvollen Beiträge von @BalusC.
Teil, nachdem dies gelöst ist. Also, man kann es ignorieren: -
Auch, ich bin mir nicht sicher, dass die version der OSGi-JSTL-bundle, dass ich - Bundle 75
ist kompatibel mit den anderen bundles - javax.el
, taglibs
, servlets
usw, oder nicht. Denn ich war mit JSTL 1.2.1
, aber ich konnte nicht Holen Sie sich das bundle für JSTL 1.2.1
. Was ich bekam, war das bundle die ich verwendet (JSTL 1.2.0
). Warum dies so ist, mich stört, ist, weil diese Art von Nachrichten kommt, wenn ich starte meine Anwendung: -
Jan 22, 2013 7:14:05 PM org.apache.catalina.startup.TaglibUriRule body
INFO: TLD skipped. URI: http://java.sun.com/jstl/core is already defined
Jan 22, 2013 7:14:05 PM org.apache.catalina.startup.TaglibUriRule body
INFO: TLD skipped. URI: http://java.sun.com/jsp/jstl/core is already defined
Jan 22, 2013 7:14:05 PM org.apache.catalina.startup.TaglibUriRule body
INFO: TLD skipped. URI: http://java.sun.com/jstl/fmt_rt is already defined
Jan 22, 2013 7:14:05 PM org.apache.catalina.startup.TaglibUriRule body
INFO: TLD skipped. URI: http://java.sun.com/jstl/fmt is already defined
Jan 22, 2013 7:14:05 PM org.apache.catalina.startup.TaglibUriRule body
INFO: TLD skipped. URI: http://java.sun.com/jsp/jstl/fmt is already defined
Jan 22, 2013 7:14:05 PM org.apache.catalina.startup.TaglibUriRule body
INFO: TLD skipped. URI: http://java.sun.com/jsp/jstl/functions is already defined
Wie Sie sehen können, dass es zwei unterschiedliche URLs oben gezeigt: -
- URI:
http://java.sun.com/jstl/core
- URI:
http://java.sun.com/jsp/jstl/core
Nun, AFAIK beide URLs gehören nicht derselben JSTL
Versionen.
So, könnte das Probleme aufwerfen? Und was kann der Grund sein, für Sie zu kommen? Ich habe gerade verwendet eine JSTL bundle
.
- Haben Sie geprüft über JSTL-Tag in es ist SO wiki? Es könnte Ihnen helfen, dieses Rätsel zu lösen.
Du musst angemeldet sein, um einen Kommentar abzugeben.
Sie mischen JSTL 1.2.0 API+impl mit JSTL 1.1.2 impl.
Den beiden impls mit miteinander in Konflikt, das erklärt die Schwierigkeiten, die Sie sehen.
Loswerden 1.1.2 impl.
Siehe auch:
taglibs.standard
bundle, da die Pakete, die es exportiert wurde, in Konflikt mit den Paketen exportiert ersten bundle. Überraschend, die Ausnahme ist die gleiche. Kein Erfolg 🙁 🙁/WEB-INF/lib
des gebacken KRIEG/bereitstellen?/WEB-INF/lib
innerhalb derWAR
- Datei?context
ist jetzt immer korrekt initialisiert durch den Hörer. War es früher nicht. Aber, nochmal, wenn ich gehen, um das Feuer der URL, gruselige Ausnahme gibt es nur.standard.jar
nicht in exportierten KRIEG mehr?javax.servlet_3.0.0.v201103241009, javax.el_2.2.0.v201105051105, javax.servlet.jsp_2.2.0.v201103241009, com.springsource.javax.servlet.jsp.jstl_1.2.0.v20110728
. Wenn Sie möchten, um zu sehen, die Pakete, die Sie exportieren oder importieren, poste ich den link zuspringsource
im nächsten Kommentare.target runtime
. Und jetzt habe ich es entfernt von der Laufzeit. Also, es ist nicht da.imported package
desWAR file
: -javax.servlet;version="3.0.0", javax.servlet.http;version="3.0.0", javax.servlet.jsp.jstl.fmt;version="1.2.0.v20110728", javax.servlet.jsp.jstl.sql;version="1.2.0.v20110728", javax.servlet.jsp.jstl.tlv;version="1.2.0.v20110728", javax.servlet.jsp.resources;version="2.2.0", javax.servlet.jsp.tagext;version="2.2.0", javax.servlet.resources;version="3.0.0",
/WEB-INF/lib
. Sie können auch diese Art von Ausnahme, wenn die container bereits Schiffe mit JSTL von selbst (wie Glassfish und JBoss). Sie sollten nur bieten, JSTL zusammen mit der webapp, wenn der container nicht Lieferumfang (wie Tomcat und Jetty). Aber für keine dieser Container, die Sie haben, zu bündeln JSP - /Servlet/EL zusammen. Also mit JSP/Servlet/EL Bibliotheken in webapp ist auch etwas seltsam. Aber wieder, OSGi ist völlig jenseits mir.JSTL 1.2.0
Arbeit mitServlet 3.0
? In der Wiki-Seite geschrieben, dassJSTL 1.2
Schiffe mitServlet 2.5
haben und die mitServlet 2.4
auch. Kann dies ein problem sein?Dies ist nur ein Schuss im Dunkeln. Nicht sicher, wenn Sie kam nach links unten.
Die Fehlermeldung, die du gepostet "konnte nicht geladen oder instanziiert TagLibraryValidator Klasse: org.apache.taglibs.standard.tlv.JstlCoreTLV" scheint zu sein, ziemlich Häufig.
Unter diesem link :
http://christerblog.wordpress.com/2010/05/04/tag-library-woes-deploying-war-on-tomcat-6/
Haben Sie eine widersprüchliche/unvereinbare jar-Bibliotheken in Ihrer war-Datei ?
Anderen hier auch Punkte für unvereinbar jars in den build-Pfad:
Nicht Lesen TLD "META-INF/c.tld"
Ich habe ein Upgrade von
Tomcat 8
zuTomcat 9
, die125: jstl.jar,taglibs-standard-spec-*.jar,
in seinercatalina.properties
. Bedeutet das, dass jstl vorinstalliert ist, im Gegensatz zu tomcat 8, wojstl 1.2
nötig war, in diebuild.gradle
?Da musste ich entfernen Sie die folgenden Zeilen, um es arbeiten
Wenn meine Antwort falsch ist, bitte lassen Sie mich wissen, ich bin glücklich, es zu löschen. Da @BalusC Antwort gab mir die Ahnung.
Zunächst, ich glaube nicht, ich kann wirklich diese Frage beantworten, keine Ahnung, ob dies für Sie relevant ist.
Ich kämpfte mit diesem problem auch, bis ich eingeschaltet, um Pax Web. Es funktionierte ziemlich viel aus der box. Ich soll zurück zu gehen und genau herauszufinden, warum meine bisherigen setup hat nicht funktioniert, aber naja, es ist nie passiert.
So, wenn es möglich ist, in Ihrer situation, verwenden Pax Web-Seite der Kommissionierung Ihre eigenen bundles.
PaxWeb
für mein Aktuelles Projekt, würde ich lieber wechseln vonJSP
zuAdobe Flex
für die Benutzeroberfläche Zweck, was haben wir bis jetzt getan. Das wäre einfach für mich.Equinox
Zeug.Gemini
wo ich sagteEquinox
in meine vorherigen zwei Kommentare.