You don't have to replace all tld's. When did this error start creeping?
With JSP 2.0, you have to just drop the jar in the lib directory under
WEB-INF. If it confirms to JSP 2.0 the tld file is expected to be in the
META-INF directory or META-INF subdirectory of the jar. Make sure that
tld it is there in the jar under META-INF directory or its
subdirectories . Over and above the web.xml should refer to 2.4xsd, like
what is given below.
web-app 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;
version=2.4
See JSP 2.0 Spec 7.3.1 ... 7.3.x
Copy paste of TLD resoultion
JSP.7.3.1 Identifying Tag Library Descriptors
---
Tag library descriptor files have names that use the extension .tld, and the
extension indicates a tag library descriptor file. When deployed inside
a JAR file,
the tag library descriptor files must be in the META-INF directory, or a
subdirectory
of it. When deployed directly into a web application, the tag library
descriptor
files must always be in the WEB-INF directory, or some subdirectory of
it. TLD
files should not be placed in /WEB-INF/classes or /WEB-INF/lib.
The XML Schema for a TLD document is http://java.sun.com/xml/ns/j2ee/
web-jsptaglibrary_2_0.xsd. See Section JSP.C.1, “XML Schema for TLD, JSP
2.0”.
Note that tag files, which collectively form tag libraries, may or may
not have
an explicitly defined TLD. In the case that they do not, the container
generates an
implicit TLD that can be referenced using the tagdir attribute of the taglib
The Tag Library Descriptor 1-161
JavaServer Pages 2.0 Specification
directive. More details about identifying this implicit Tag Library
Descriptor can
be found in Chapter JSP.8, “Tag Files”.
Thanks,
Vijay Venkataraman
Anuradha Vaidya wrote:
Hi
I am using Tomcat/5.5.12 and java version 1.4.2_10 and am receiving
errors: the description follows...
SEVERE: Error reading tld listeners javax.servlet.ServletException:
Exception processing TLD at resource path /WEB-INF/s
n context /mycontext
javax.servlet.ServletException: Exception processing TLD at resource
path /WEB-INF/struts-logic.tld in context /mycontext
at
org.apache.catalina.startup.TldConfig.tldScanTld(TldConfig.java:547)
at
org.apache.catalina.startup.TldConfig.execute(TldConfig.java:300)
at
org.apache.catalina.core.StandardContext.processTlds(StandardContext.jav
a:4216)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:4072
)
at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1012)
at
org.apache.catalina.core.StandardHost.start(StandardHost.java:718)
at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1012)
at
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442)
at
org.apache.catalina.core.StandardService.start(StandardService.java:450)
at
org.apache.catalina.core.StandardServer.start(StandardServer.java:680)
at org.apache.catalina.startup.Catalina.start(Catalina.java:536)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:275)
at
org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
It seems to work by getting rid of the DOCTYPE declaration and using the
new taglib start
taglib 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/web-jsptaglibrary_2_
0.xsd
version=2.0
but I cant replace all the tld's, besides the current set of tld's are
working fine for a colleague with similar environment.
Please answer whatever you may think might be the best solution and if
someone is sure request you to send a reply asap...
Thanks
Anu
MASTEK
Making a valuable difference
Mastek in NASSCOM's 'India Top 20' Software Service Exporters List.
In the US, we're called MAJESCOMASTEK
~~
Opinions expressed in this e-mail are those of the individual and not that of
Mastek Limited, unless specifically indicated to that effect. Mastek Limited
does not accept any responsibility or liability for it. This e-mail and
attachments (if any) transmitted with it are confidential and/or privileged and
solely for the use of the intended person or entity to which it is addressed.
Any review, re-transmission, dissemination or other use of or taking of any
action
