It turns out that the cause was that this project wasn't being considered by Eclipse to actually be a Java EE project at all; it was an old project from 3.1, and the Eclipse 3.5 we are using now requires several "natures" to be set in the project configuration file.
I was able to find the cause by creating a new "Dynamic Web Project" which properly read its JSP files, and diffing against the config of the older project.
The only way I could find to add these was by editing the .project file, but after re-opening the project, everything magically worked. The settings referenced by pribeiro, above, weren't necessary since the project already conformed to the default settings.
Both pribeiro and nitind's answers gave me ideas to jumpstart my search, thanks.
Is there a way of editing these "natures" from within the UI?
I also faced the same problem. Make sure you have same versions of JSTL in Eclipse and in the Tomcat work directory, i.e in
\webapps\examples\WEB-INF\lib and in
replace jstl.jar to jstl1.2.jar resolved the issue for tomcat 7.0
I had the same problem with MyEclipse and Eclipse 6.6.0. It red lined the uri value in every
<%@ taglib prefix="s" uri="/struts-tags"%>.
I fixed it by going to 'Project/MyEclipse/Web/Tag Libraries' and setting the Default TLD Prefix for Struts 1.2 Tiles Tags to 's'. I also had to do the same under 'Project/MyEclipse/Web/Configure workspace settings.../Tag Libraries'.
I had the same problem with STS (springtool source suite).
Under STS, right click on the project, than "Properties", "Project Facets", than on the right of the window click on the "runtime" tab, and check "VMware vFabric tc Server (...)", and click "Apply" and it should be OK after the workspace refresh.
I was having the same problem using Tomcat 6.0 and Eclipse and I tried out something which my friend suggested and it worked for me. The link for the question I asked and my reply commented can be found here:
Let me know if this solves your "Cannot find the taglibrary descriptor" problem.
well you need to understand there are always two things the API and the implementation (mind the gradle format of the following code)
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'
so If you're using a servlet container with no jstl support then of course it will not provide both of them, a mistake which I made is that I only put the first one, but if you're using full stack application server i.e glassfish then glassfish will have both of them already inside.
For me, this error occurs whenever I try to use a new version of eclipse. Apparently, the new eclipse resets the
M2_REPO variable and I get all the tag library error in the
Marker view (sometimes with ejb validation errors).
M2_REPO variable to point to actual maven repository location, it takes 2-3 Project -> Clean iterations to get everything working.
And sometimes, there are some xml validation errors(ejb) along with this tag library errors. Manually updating the corresponding XML file, initiates a *.xsd file lookup and the xml validations errors are resolved. Post this, the tag library errors also vanish.
On the other hand, if you are only working on java source and are getting these errors from stuff you don't touch in a large project that is working, you can just turn off the validations in Eclipse. The settings are under Preferences->Web->JSP Files->Validation
This error can arise from several different sources. One case (not mentioned in other answers to this question) occurs when Eclipse does not implement the version of the JSP specification set in the TLD document. Eclipse releases typically lag behind up to a year in implementing newer servlet and JSP specifications. See this Eclipse bug for example.
In this case, your web application may run fine in the latest version of Tomcat, but Eclipse may still complain about a missing TLD. The short term solution (short of ignoring the error in Eclipse) is to bump down the JSP version to the one that your version of Eclipse supports.
Also, keep in mind the TLD version you are implementing. The tag names have changed slightly from v1.1 to v2.0 (i.e.,
info is now
taglib and is not a valid element under
tag, many of the element names now contain a hyphen). Eclipse has no tolerance for misspelled TLD tag names.
You can simply go to Build Path -> Add Libraries and for the library type to add select "Server Runtime." Click Next and select a server runtime to add to the classpath and the problem goes away if jstl.jar and standard.jar are in your server's classpath.
I'm using Spring STS plugin and a Spring webmvc template project. I had to install the Maven m2e plugin first: http://www.eclipse.org/m2e/
And then clean the project. Under
Project -> Clean...
If your tld's are on the classpath, typically under the WEB-INF directory, the following two tips should resolve the issue (irrespective of your environment setup):
Ensure that the
<uri>in the TLD and the uri in the taglib directive of your jsp pages match. The
<uri>element of the tld is a unique name for the tag library.
If the tld does not have a
<uri>element, the Container will attempt to use the uri attribute in the taglib directive as a path to the actual TLD. for e.g. I could have a custom tld file in my WEB-INF folder and use the path to the this tld as the uri value in my JSP. However, this is a bad practice and should be avoided since the paths would then be hardcoded.
Check the two libraries in
I faced same problem. This is what I did to resolve the issue.
- Select Project and right click.
- Click on properties.
- Click on libraries tab.
- Click on 'Add Jars'.
- Add relevant jar for your error.
A lot depends on what kind of project it is. WTP's JSP support either expects the JSP files to be under the same folder that's the parent of the WEB-INF folder (src/web, which it will then treat as "/" to find TLDs), or to have project metadata set up to help it know where that root is (done for you in a Dynamic Web Project through Deployment Assembly). How are you referring to the TLD file, and where is the JSP file located?
And maybe I missed the original post to the Eclipse forums; the one I saw was posted a full day after this one.
I fixed this problem today.
- Change your output directory to your WEB-INF/classes folder. (Project/Properties/Java Build Path, Default output folder)
- Assigne the module dependencies. (Project/Properties/Java EE Module Dependencies) they will be copied to the WEB-INF/lib folder where Eclipse looks for the tag lib definitions too.
I hope it helps.
When I tried to include the JSTL Core Library in my JSP:
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
I got the following error in Eclipse (Indigo):
Can not find the tag library descriptor for "http://java.sun.com/jsp/jstl/core"
I went to the Project Properties -> Targeted Runtimes, and then checked the Server I was using (Geronimo 3.0). Most people would be using Tomcat. This solved my problem. Hope it helps!
Ran into the same problem, I'm using maven so I added this to the pom in my web project:
<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>
This fixed the problem and I used "provided" scope because like the OP, everything was already working in JBoss.
Here's where I found the solution: http://alfredjava.wordpress.com/2008/12/22/jstl-connot-resolved/
I had the same problem with a stripes taglib uri showing as not found. I was using Indigo and Maven and when I checked Properties->Java Build Path->Order & Export Tab I found (on a fresh project checkout) that the "Maven Dependencies" checkbox was unchecked for some reason. Simply checking that box and doing a Maven clean install cleared all the errors.
I wonder why Eclipse doesn't assume I want my Maven dependencies in the build path...
This was my problem and how I fixed it...
I had done everything everyone had mentioned above etc. but was still getting this error. Turns out I was using the uri's of
http://java.sun.com/jsp/jstl/core which were incorrect.
Try switching the uris from above to:
Also, make sure you have the correct jars referenced in your class path.
In Eclipse Helios "Java EE Module Dependencies" in the project properties has been replaced with "Deployment Assembly".
So for solving this problem with Eclipse Helios, the way I did it is the following:
- Right click on the project in package explorer and choose "Import..."
- Accept the default selection "File System" and press "Next"
- Press "Browse" in the From directory line, go to your tomcat installation and locate the file webapps/examples/WEB-INF/lib (I have tomcat 6, other versions of Tomcat may have the path webapps/jsp-examples/WEB-INF/lib). Once in the path press OK.
- Click besides jstl.jar and standard.jar to activate the check boxes
- On the line Into folder click on Browse and choose the library folder. I use /lib inside the project.
- Click "Finish"
- Right click on the project in Package Explorer view and choose properties (or press Alt + Enter)
- Click on "Java Build Path"
- Click "Add Jar", click on your project, folder lib, select jstl.jar, press OK
- Click "Add Jar", click on your project, folder lib, select standard.jar, press OK
- Press OK to dismiss the properties dialog
- Click on the Problems view and select the message "Classpath entry .../jstl.jar will not be exported or published. Runtime ClassNotFoundExceptions may result.".
- Right click on it and select "Quick Fix".
- Accept the default "Mark the associated raw classpath entry as a publish/export dependency" and press Finish.
- Do the same for standard.jar
This solves the problem, but if you want to check what has happened in "Deployment Assembly", open the project properties again, select "Deployment Assembly" and you'll see that standard.jar and jstl.jar have been added to WEB-INF/lib folder.
- Eclipse "cannot find the tag library descriptor" for custom tags (not JSTL!)
- eclipse : Can not find the tag library descriptor for "/struts-tags"
- How to fix "Can not find the tag library descriptor" in eclipse 4.3 for my custom EL function
- Can not find the tag library descriptor for “http://java.sun.com/jsp/jstl/core”
- Cannot find the JSTL core library descriptor error in Eclipse
- Can not find the tag library descriptor for "http://richfaces.ajax4jsf.org/rich"
- Java EE 7 : Can not find the tag library descriptor for "http://java.sun.com/jsp/jstl/core"
- cannot find tag library descriptor for spring framework in maven eclipse project
- Custom tag-colors for imported tag library tags in Eclipse
- Cannot find the library in Eclipse for a C++ code to connect to MySQL
- My imported eclipse project gives error the project was not build since the build path is incomplete. Cannot find the class file for java.lang.object
- Maven: Can not find the tag library descriptor
- eclipse maven error: Archive for required library in project cannot be read or is not a valid ZIP file
- Eclipse - Can't find facelet tag library for uri http://java.sun.com/jsf/html
- cannot not find library files in eclipse cdt
- Cannot find a free socket for the debugger in eclipse
- import error while adding TextEditor to eclipse plugin - Cannot find the class file for org.eclipse.jface.text.revisions.RevisionInformation
- Jenkins cannot find the external Jars added for the selenium project through Eclipse
- Where do I find gwt-dev-windows.jar ? It does not look like it was included in the GWT SDK for Eclipse
- Maven eclipse error: "Archive for required library cannot be read or is not a valid ZIP file"
- eclipse broken since java 6.31: Cannot find the class file for java.lang.Enum
- The dynamic link library for GLPK for Java could not be loaded. Eclipse
- Eclipse Cannot find the UnitTest++ library
- cannot not find library files in Eclipse with GNU C/C++ compiler
- Eclipse Error for GLPK library: The dynamic link library for GLPK for Java could not beloaded
- eclipse juno jstl error cannot find tag lib
- Eclipse - "Incompatible JVM. Version 1.8.0_261 of the JVM is not suitable for this product. Version: 11 or greater is required"
- unable to get system library for the project on eclipse ide
- Error launching Eclipse 4.4 "Version 1.6.0_65 of the JVM is not suitable for this product."
- "Could not find the main class" error when running jar exported by Eclipse
More Query from same tag
- JavaFx on Eclipse, impossibility loading .fxml
- Installing SVN plugin for Eclipse on Ubuntu
- Can not open file with special charecters from Java when using Eclipse on MacOSX
- Eclipse Galileo SQL Editor: is there a code formatter (tidy) function?
- Confusion in choosing between JavaGit, JGit and EGit
- Eclipse giving "weird" error concerning opencv
- Is in Visual Studio an equivalent to the Eclipse "Run Configurations"?
- No console output for specific project - Java Eclipse
- Cannot Open/view sqlite database file in Eclipse with external Virtual Device Manager
- Reading a .txt file into JAR. It works in Eclipse but not in exported JAR
- How to multiple work spaces in eclipse windows
- How to change the constant value in Debug mode
- Calling a method from superclass not working Java
- Clean out Eclipse workspace metadata
- Eclipse Luna requested Java 1.8 but failed
- Very lightweight Eclipse-Maven integration - dependency management only?
- PySide/PyDev not autcompleting correctly
- In scala eclipse how do I use a library in my workspace
- Android, Eclipse in Mac
- Eclipse Makefile project to be built within a Cygwin environment
- java_cup cannot be resolved
- Two Eclipse Android Projects: One is a widget, one is a normal app. How to connect?
- Eclipse class version bug
- Starting AWS DynamoDB Local from Eclipse STS on OSX
- Including Google Play Downloader Library | APK File Expansion Library
- Syntax error, insert "EnumBody" to complete
- How to host and run the GCM XMPP CCS Server 24x7 on Internet?
- Jackson dependency in maven and developing in eclipse with JBoss EAP 6.3/6.4
- Getting this error: 'Building Workspace' has encountered an error. Errors occurred during the build
- Stanford Eclipse not building applications properly