taglibs tag custom java eclipse jsp taglib custom-tags

java - tag - Eclipse "no puede encontrar el descriptor de biblioteca de etiquetas" para etiquetas personalizadas(¡no JSTL!)



taglibs jsp (22)

Cuando traté de incluir JSTL Core Library en mi JSP:

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>

Obtuve el siguiente error en Eclipse (Indigo):

Can not find the tag library descriptor for "http://java.sun.com/jsp/jstl/core"

Fui a Propiedades del proyecto -> Tiempo de ejecución dirigido, y luego revisé el servidor que estaba usando (Geronimo 3.0). La mayoría de la gente estaría usando Tomcat. Esto resolvió mi problema. ¡Espero eso ayude!

Tengo un proyecto de Java EE que funciona bien con Ant, se implementa perfectamente en JBoss y se ejecuta sin problemas. Este proyecto incluye algunas bibliotecas de etiquetas personalizadas (¡que no es JSTL !), Que también funcionan sin dificultades.

El problema es con el Eclipse IDE (Ganymede): en cada archivo JSP que utiliza nuestras etiquetas personalizadas, el analizador JSP marca el taglib include line con este error:

Cannot find the tag library descriptor for (example).tld

Esto también hace que cada uso de la biblioteca de pestañas se marque como un error, y dado que el IDE no tiene su definición, no puede verificar los parámetros de las etiquetas, etc.

Nuestros archivos JSP que funcionan perfectamente son un mar de errores rojos, y mis ojos comienzan a arder.

¿Cómo puedo simplemente decirle a Eclipse, "El descriptor de la biblioteca de etiquetas que está buscando es" src / web / WEB-INF / (ejemplo) -taglib / (ejemplo) .tld "?

Ya hice esta pregunta en los foros de soporte de Eclipse, sin resultados útiles.

En Eclipse Helios "Dependencias del módulo Java EE" en las propiedades del proyecto se ha reemplazado por "Implementación del despliegue".

Entonces, para resolver este problema con Eclipse Helios, la forma en que lo hice es la siguiente:

  • Haga clic derecho en el proyecto en el explorador de paquetes y seleccione "Importar ..."
  • Acepte la selección predeterminada "Sistema de archivos" y presione "Siguiente"
  • Presiona "Buscar" en la línea del directorio Desde, ve a tu instalación de tomcat y busca el archivo webapps / examples / WEB-INF / lib (tengo tomcat 6, otras versiones de Tomcat pueden tener la ruta webapps / jsp-examples / WEB- INF / lib). Una vez en el camino, presione OK.
  • Haga clic además de jstl.jar y standard.jar para activar las casillas de verificación
  • En la línea En la carpeta, haga clic en Examinar y elija la carpeta de la biblioteca. Yo uso / lib dentro del proyecto.
  • Haga clic en "Finalizar"
  • Haga clic con el botón derecho en el proyecto en la vista Explorador de paquetes y seleccione propiedades (o presione Alt + Intro)
  • Haga clic en "Java Build Path"
  • Haga clic en "Agregar tarro", haga clic en su proyecto, en la carpeta lib, seleccione jstl.jar, presione OK
  • Haga clic en "Agregar jar", haga clic en su proyecto, en la carpeta lib, seleccione standard.jar, presione OK
  • Presione OK para cerrar el cuadro de diálogo de propiedades
  • Haga clic en la vista de Problemas y seleccione el mensaje "La entrada de Classpath ... / jstl.jar no se exportará ni publicará. Puede producirse Runtime ClassNotFoundExceptions".
  • Haga clic derecho sobre él y seleccione "Solución rápida".
  • Acepte el valor predeterminado "Marcar la entrada asociada de classpath sin procesar como una dependencia de publicación / exportación" y presione Finalizar.
  • Haz lo mismo para standard.jar

Esto resuelve el problema, pero si desea verificar lo que sucedió en "Implementación del despliegue", vuelva a abrir las propiedades del proyecto, seleccione "Ensamblaje de despliegue" y verá que se agregaron standard.jar y jstl.jar a WEB- Carpeta INF / lib.

Estaba teniendo el mismo problema al usar Tomcat 6.0 y Eclipse y probé algo que mi amigo me sugirió y funcionó para mí. El enlace para la pregunta que hice y mi respuesta comentada se puede encontrar aquí:

JSTL Tomcat 6.0 No se puede encontrar el descriptor taglib Error

Avíseme si esto resuelve su problema "No se puede encontrar el descriptor de la taglibrary".

Este error puede surgir de varias fuentes diferentes. Un caso (no mencionado en otras respuestas a esta pregunta) ocurre cuando Eclipse no implementa la versión del conjunto de especificaciones JSP en el documento TLD. Las versiones de Eclipse suelen tardar más de un año en implementar las especificaciones más recientes de servlets y JSP. Vea este error Eclipse por ejemplo.

En este caso, su aplicación web puede funcionar bien en la última versión de Tomcat, pero Eclipse aún puede quejarse sobre un TLD perdido. La solución a corto plazo (si no se ignora el error en Eclipse) es reducir la versión de JSP a la que admite su versión de Eclipse.

Además, tenga en cuenta la versión de TLD que está implementando. Los nombres de las etiquetas han cambiado ligeramente de v1.1 a v2.0 (es decir, la info ahora es una description en taglib y no es un elemento válido debajo de la tag , muchos de los nombres de los elementos ahora contienen un guión). Eclipse no tiene tolerancia para los nombres de etiquetas TLD mal escritas.

TLD 2.0 (jsp-versión 2.0) Referencia

TLD 2.1 (jsp-versión 2.3) Referencia

Este fue mi problema y cómo lo arreglé ...

Había hecho todo lo que todos habían mencionado anteriormente, etc., pero todavía estaba recibiendo este error. Resulta que estaba usando los uri de http://java.sun.com/jsp/jstl/fmt y http://java.sun.com/jsp/jstl/core que eran incorrectos.

Intenta cambiar el uris de arriba a:

http://java.sun.com/jstl/fmt http://java.sun.com/jstl/core

Además, asegúrese de tener las jarras correctas a las que se hace referencia en su ruta de clases.

Estoy usando el plugin Spring STS y un proyecto de plantilla webmvc de Spring. Primero tuve que instalar el plugin Maven m2e: http://www.eclipse.org/m2e/

Y luego limpia el proyecto. En Project -> Clean...

Me encontré con el mismo problema, estoy usando maven, así que lo agregué al pom en mi proyecto web:

<dependency> <groupId>javax.servlet</groupId> <artifactId>jstl</artifactId> <version>1.2</version> <!-- just used the latest version, make sure you use the one you need --> <scope>provided</scope> </dependency>

Esto solucionó el problema y usé el alcance "provisto" porque al igual que el OP, todo estaba funcionando en JBoss.

Aquí es donde encontré la solución: http://alfredjava.wordpress.com/2008/12/22/jstl-connot-resolved/

Me enfrenté al mismo problema. Esto es lo que hice para resolver el problema.

  1. Seleccione Proyecto y haga clic derecho.
  2. Haga clic en propiedades.
  3. Haga clic en la pestaña de bibliotecas.
  4. Haga clic en ''Agregar tarros''.
  5. Agregue el jar relevante para su error.

Mucho depende del tipo de proyecto que sea. El soporte JSP de WTP o bien espera que los archivos JSP estén bajo la misma carpeta que el padre de la carpeta WEB-INF (src / web, que luego tratará como "/" para encontrar TLD), o para tener los metadatos del proyecto configurados para ayúdelo a saber dónde está esa raíz (hecho para usted en un Proyecto web dinámico a través del Ensamblaje de despliegue). ¿Cómo se refiere al archivo TLD y dónde se encuentra el archivo JSP?

Y tal vez me perdí la publicación original en los foros de Eclipse; el que vi fue publicado un día completo después de este.

Para mí, este error ocurre cada vez que trato de usar una nueva versión de eclipse. Aparentemente, el nuevo eclipse restablece la variable M2_REPO y obtengo todo el error de la biblioteca de etiquetas en la vista Marker (a veces con errores de validación ejb).

Después de actualizar la variable M2_REPO para que apunte a la ubicación real del repositorio maven, se necesita 2-3 Proyecto -> Borrar iteraciones para que todo funcione.

Y a veces, hay algunos errores de validación xml (ejb) junto con estos errores de biblioteca de etiquetas. Actualizando manualmente el archivo XML correspondiente, inicia una búsqueda de archivo * .xsd y se resuelven los errores de validación de xml. Publica esto, los errores de la biblioteca de etiquetas también desaparecen.

Por otro lado, si solo está trabajando en Java Source y está recibiendo estos errores de cosas que no toca en un proyecto grande que está funcionando, puede desactivar las validaciones en Eclipse. La configuración está en Preferencias-> Web-> Archivos JSP-> Validación

Resultó que la causa era que Eclipse no consideraba este proyecto como realmente un proyecto de Java EE; era un proyecto antiguo de 3.1, y el Eclipse 3.5 que estamos utilizando ahora requiere varias "naturalezas" para establecerse en el archivo de configuración del proyecto.

<natures> <nature>org.eclipse.jdt.core.javanature</nature> <nature>InCode.inCodeNature</nature> <nature>org.eclipse.dltk.javascript.core.nature</nature> <nature>net.sf.eclipsecs.core.CheckstyleNature</nature> <nature>org.eclipse.wst.jsdt.core.jsNature</nature> <nature>org.eclipse.wst.common.project.facet.core.nature</nature> <nature>org.eclipse.wst.common.modulecore.ModuleCoreNature</nature> <nature>org.eclipse.jem.workbench.JavaEMFNature</nature> </natures>

Pude encontrar la causa al crear un nuevo "Proyecto web dinámico" que lee correctamente sus archivos JSP y difiere de la configuración del proyecto anterior.

La única forma que pude encontrar para agregar estos fue editando el archivo .project, pero después de reabrir el proyecto, todo funcionó mágicamente. La configuración a la que hace referencia pribeiro, arriba, no era necesaria dado que el proyecto ya se ajustaba a la configuración predeterminada.

Las respuestas de pribeiro y nitind me dieron ideas para comenzar mi búsqueda, gracias.

¿Hay alguna manera de editar estas "naturalezas" desde dentro de la UI?

Si los tld están en la ruta de clase, generalmente en el directorio WEB-INF, los siguientes dos consejos deberían resolver el problema (independientemente de la configuración de su entorno):

  1. Asegúrese de que el <uri> en el TLD y el uri en la directiva taglib de sus páginas jsp coincidan. El elemento <uri> del tld es un nombre único para la biblioteca de etiquetas.

  2. Si el tld no tiene un elemento <uri> , el contenedor intentará usar el atributo uri en la directiva taglib como una ruta al TLD real. por ejemplo, podría tener un archivo tld personalizado en mi carpeta WEB-INF y utilizar la ruta de este tld como el valor uri en mi JSP. Sin embargo, esta es una mala práctica y debe evitarse ya que las rutas serían codificadas.

Simplemente puede ir a Build Path -> Add Libraries y para el tipo de biblioteca para agregar seleccione "Server Runtime". Haga clic en Siguiente y seleccione un tiempo de ejecución del servidor para agregar al classpath y el problema desaparecerá si jstl.jar y standard.jar están en classpath de su servidor.

Solucioné este problema hoy.

  • Cambie su directorio de salida a su carpeta WEB-INF / classes. (Proyecto / Propiedades / Ruta de compilación de Java, carpeta de salida predeterminada)
  • Asigne las dependencias del módulo. (Dependencias del módulo Project / Properties / Java EE) se copiarán en la carpeta WEB-INF / lib, donde Eclipse también busca las definiciones de lib de la etiqueta.

Espero que ayude.

También me enfrenté al mismo problema. Asegúrese de tener las mismas versiones de JSTL en Eclipse y en el directorio de trabajo de Tomcat, es decir, en /webapps/examples/WEB-INF/lib y en la carpeta lib .

Tuve el mismo problema con MyEclipse y Eclipse 6.6.0. Rojo forrado el valor de uri en cada

<%@ taglib prefix="s" uri="/struts-tags"%> . Lo arreglé yendo a ''Project / MyEclipse / Web / Tag Libraries'' y estableciendo el Prefijo de TLD predeterminado para Struts 1.2 Tiles Tags a ''s''. También tuve que hacer lo mismo en ''Project / MyEclipse / Web / Configure settings del espacio de trabajo ... / Tag Libraries''.

Tuve el mismo problema con STS (Springtool source suite).

Bajo STS, haga clic derecho en el proyecto, que "Propiedades", "Facetas del proyecto", que a la derecha de la ventana, haga clic en la pestaña "runtime", y seleccione "VMware vFabric tc Server (...)", y haga clic "Aplicar" y debería estar bien después de actualizar el espacio de trabajo.

Tuve el mismo problema con un taglib uri de rayas que muestra como no encontrado. Estaba usando Indigo y Maven y cuando revisé Properties-> Java Build Path-> Order & Export Tab Encontré (en una nueva comprobación del proyecto) que la casilla de verificación "Maven Dependencies" estaba desmarcada por algún motivo. Simplemente marcando esa casilla y haciendo una instalación limpia de Maven se borraron todos los errores.

Me pregunto por qué Eclipse no supone que quiero mis dependencias Maven en la ruta de compilación ...

Verifique las dos bibliotecas en F:/apache-tomcat-7.0.21/webapps/examples/WEB-INF/lib :

  1. jstl.jar
  2. standard.jar

bueno, necesitas entender que siempre hay dos cosas, la API y la implementación (ten en cuenta el formato gradle del siguiente código)

compile group:''javax.servlet.jsp.jstl'', name:''javax.servlet.jsp.jstl-api'', version:''1.2.1''

compile group:''org.glassfish.web'', name:''javax.servlet.jsp.jstl'',version:''1.2.1''

Entonces, si está utilizando un contenedor de servlets sin soporte jstl, por supuesto no proporcionará ambos, un error que cometí es que solo puse el primero, pero si está utilizando un servidor de aplicaciones de pila completa, es decir, glassfish entonces glassfish los tendrá a ambos dentro.

reemplace jstl.jar por jstl1.2.jar resolvió el problema para tomcat 7.0