2010-08-10 12 views
18

jest ten problem z JSTL, z którym utknąłem przez ostatnie kilka dni. Każda pomoc jest doceniana.Nie można odczytać TLD "META-INF/c.tld"

Tomcat 6.0.28
Eclipse Helios

pom.xml:

<dependency> 
    <groupId>javax.servlet</groupId> 
    <artifactId>jstl</artifactId> 
    <version>1.1.2</version> 
</dependency> 
<dependency> 
    <groupId>javax.servlet</groupId> 
    <artifactId>servlet-api</artifactId> 
    <version>2.4</version> 
    <scope>provided</scope> 
</dependency> 
<dependency> 
    <groupId>taglibs</groupId> 
    <artifactId>standard</artifactId> 
    <version>1.1.2</version> 
</dependency> 
<dependency> 
    <groupId>javax.servlet.jsp</groupId> 
    <artifactId>jsp-api</artifactId> 
    <version>2.0</version> 
    <scope>provided</scope> 
</dependency> 

JP:

<%@ page session="true"%> 
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %> 
<%@ taglib prefix="fmt" uri="http://java.sun.com/jsp/jstl/fmt" %> 
<%@ taglib prefix="utilfn" uri="/utility-functions" %> 

web.xml:

<web-app id="WebApp_ID" version="2.4" 
xmlns="http://java.sun.com/xml/ns/j2ee" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee 
    http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"> 

Wh pl Wdrażam zbudowaną przez Mavena wojnę na tomcat 6, używając menedżera, który działa dobrze. Kiedy uruchamiam go jako "run as> uruchomić na serwerze" wewnątrz Eclipse, otrzymuję to:

Nie można odczytać TLD "META-INF/c.tld" z pliku JAR „file:/< - Położenie -> /. metadane/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/Myproject/WEB-INF/lib/standard-1.1.2.jar ": org.apache.jasper.JasperException: niepowodzenie klasa obciążenia lub wystąpienia TagLibraryValidator: org.apache.taglibs.standard.tlv.JstlCoreTLV

Gdziekolwiek patrzę, to mówi to samo:

  1. Upewnij się, że serwlet-api i jsp-api nie znajdują się w bibliotece
  2. Upewnij się, że używasz właściwej wersji JSTL i identyfikatora URI zgodnego z JSP 2.0.

Wygląda na to, że czuję się dobrze, ponieważ mogę samodzielnie rozpocząć wojnę. Co tu jest nie tak?

+2

Dobrze napisane pytanie, mnóstwo przykładów. Dobra robota. – Spedge

Odpowiedz

4

Sprawdź, czy .metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/Myproject/WEB-INF/lib/standard-1.1.2.jar nie jest uszkodzony (i wykonaj czyszczenie, jeśli jest to wymagane).

+5

Mimo że standard-1.1.2.jar nie był problemem, nadal akceptuję twoją odpowiedź, ponieważ nie udało mi się sprawdzić tej lokalizacji. Po prostu mi się nie przydarzyło. Problem polegał na tym, że plik servlet-api.jar został skopiowany do tej lokalizacji w jakiś sposób po usunięciu i ponownym skonfigurowaniu serwera w środowisku Eclipse. Usunięcie tego pliku rozwiązało problem. Za każdym razem, gdy wybieram "Wyczyść" i "Wyczyść katalog roboczy Tomcat" z menu kontekstowego serwera, słoik pojawia się tam ponownie. Nie wiem, dlaczego/jak. Jednak od tej pory ręczne usuwanie tego pliku powoduje jego działanie. Dziękuję za odpowiedź! –

+0

Dzięki, to było przydatne. Nadal nie zrozumiałem, dlaczego/jak słój pojawia się ponownie - czy ty? –

+1

Zdarzyło mi się też, że czasami JAR są uwzględniane, nawet jeśli są oznaczone jako dostarczone w pom, znalazłem rozwiązanie z opakowaniemZobacz http://stackoverflow.com/questions/6477504/maven-javax-servlet-specification-deployed – stivlo

5

Wygląda na to, że istnieje problem z wtyczką maven/m2eclipse. Nawet widzę ten sam problem. Domyślnie przesyła wszystkie pliki jar do katalogu lib serwera. Co obejmuje zakres "dostarczonych" plików JAR. Ten problem został rozwiązany w starszych wersjach m2eclipse. Ale wydaje się, że znowu się wprowadził.

+0

Dzięki . Tak, m2e 1.0 zawiera dostarczone JAR, jak mówisz. To jest problem, ponieważ Tomcat nie chce javax.servlet.jsp: jsp-api jak Sobree zauważa powyżej. –

6

remove:
javax.servlet.jsp JSP API 2,0 warunkiem

od ciebie pom.xml i że należy zrobić .. to zadziałało w moim przypadku :-)

15

Po przeniesieniu za pomocą Indigo Eclipse 3.7 i wziąłem trwałą aktualizację m2e, ten problem przydarzył mi się, usunąłem zależność poniżej, która działała dobrze.

Nie jestem pewien, dlaczego problemy zniknęły, ponieważ moje zrozumienie nowej wersji m2e ma już bibliotekę kompilacji jsp.

+1

Uratowałeś moje zdrowie psychiczne! –

0

platforma: eclipse 3,7 indygo, tomcat 6.0.29
wykomentowane następujące zależności w pom.xml:

javax.servlet 
org.apache.taglibs 

to wyjaśnić ten problem (jak są one świadczone przez Tomcat) ...

+0

Osoba pytająca zaakceptowała zupełnie inne rozwiązanie na kilka miesięcy przed odpowiedzią, więc nie był to jego problem. – itsbruce

0

zgadzam się z odpowiedzią Jaya. Mam ten sam problem tutaj. Jeśli usuniemy jsp-api z pom.xlm, test ma się nie powieść, ponieważ nie może znaleźć klasy jspWriter w słoiku jsp-api. Jeśli utrzymam jsp-api w pom i ustawię go na "provided" lub "test", strona tomcat zawiedzie, ponieważ plugin m2e popycha zależności jsp-api słoika do mastera, które są następnie zawarte w mojej wdrożonej bibliotece tomcat. Powiedziałbym, że jest to problem wtyczki, ponieważ jsp-api musi zostać zadeklarowane w pom.xml, ponieważ jest dostarczane przez serwery aplikacji. Nie mogę znaleźć żadnego sposobu rozwiązania tego problemu, ale ręcznie usunąć jsp-api za każdym razem po zsynchronizowaniu serwera tomcat.

0

z Eclipse, należy upewnić się, że zainstalowano „integracja Mavena dla Eclipse WTP” z innymi wtyczki bez WTP Eclipse zmienić ścieżkę klas i obejmują servlet-api.jar w swoim webapps.

+0

Podczas gdy twoja odpowiedź może być pomocna, została już rozwiązana przez zrobienie czegoś innego. –

2

Quickfix:

Zrób kopię zapasową .classpath i .project i .settings/org.eclipse.wst.common.component.

Run to polecenie:

mvn eclipse:eclipse 

Albo prawym przyciskiem nad projektem, w Maven podmenu masz ... polecenie Aktualizacja projektu, który myślę, że robi to samo.

Opublikuj ponownie.

Objaśnienie:

Prawdopodobnie dodaniu wszystkich Maven Zależności jako zespół Deployment do projektu. Spowoduje to skopiowanie wszystkich pozycji ścieżki klasy Maven do katalogu WEB-INF/lib. Otwórz plik .classpath (u podstaw projektu) i prawdopodobnie znajdziesz następujące XML:

<classpathentry kind="con" path="org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER"> 
    <attributes> 
     <attribute name="org.eclipse.jst.component.dependency" value="/WEB-INF/lib"/> 
    </attributes> 
</classpathentry> 

Oznacza to, że każdy plik .jar Kopiuj która staje się problemem w tym przypadku.

Aktualizacja projektu powinna usunąć powyższy blok XML i jawnie wylistować pliki JAR.

Tak więc, jeśli ponownie otwarty .classpath, zobaczysz to zamiast:

<classpathentry kind="var" path="M2_REPO/com/google/code/gson/gson/2.2.1/gson-2.2.1.jar" sourcepath="M2_REPO/com/google/code/gson/gson/2.2.1/gson-2.2.1-sources.jar"/> 
<classpathentry kind="var" path="M2_REPO/javax/servlet/jsp/jsp-api/2.1/jsp-api-2.1.jar" sourcepath="M2_REPO/javax/servlet/jsp/jsp-api/2.1/jsp-api-2.1-sources.jar"/> 
... 

To jest na ścieżce klas, które trzeba jeszcze, ale usuwa zależność je skopiować do lib. Zamiast tego, jeśli otwarte .settings/org.eclipse.wst.common.component /, zobaczysz, że pliki JAR są teraz wyraźnie wymienione:

<dependent-module deploy-path="/WEB-INF/lib" handle="module:/classpath/var/M2_REPO/com/google/code/gson/gson/2.2.1/gson-2.2.1.jar"> 
    <dependency-type>uses</dependency-type> 
</dependent-module> 

I będziesz pamiętać, że JSP API- Brakuje teraz pliku 2.1.jar. Zastosuj tę samą logikę do innych plików JAR.

Czy ktoś wie, jak zrobić to automatycznie?

0

Należy wykluczyć zależność JSP API z importu JSTL w pom.xml:

<dependency> 
    <groupId>javax.servlet.jsp.jstl</groupId> 
    <artifactId>jstl-api</artifactId> 
    <version>1.2</version> 
    <exclusions> 
     <exclusion> 
      <groupId>javax.servlet</groupId> 
      <artifactId>servlet-api</artifactId> 
     </exclusion> 
     <exclusion> 
      <artifactId>jsp-api</artifactId> 
      <groupId>javax.servlet.jsp</groupId> 
     </exclusion> 
    </exclusions> 
</dependency> 
0

Usunięto JSP API 2.0 z .metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/Myproject/WEB-INF/lib/ to działało dla mnie.

0

Otrzymałem ten sam błąd w netbeans IDE 8.0.2. Okazuje się, że moja część została ustawiona na 8080 dla wychodzenia i zamykania. Zmieniłem wychodzące na 8081 dla serwera Tomcat. Zadziałało! Następnie zmieniłem port zamykania 8005. Aby zmienić, przejdź do Narzędzia> Serwery>

Mój serwer Tomcat teraz działa.

Powiązane problemy