You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by A Misra <a_...@yahoo.com> on 2003/12/18 11:48:02 UTC

problem in .tld pickup from a jar

Hi,

I am facing some problem in .tld pickup from a jar(in
WEB-INF/lib). This may be a bug or my poor
understanding of the jsp specifications. Any
pointer/clarification will be highly appreciated.


Scenario - 1
------------

Two tlds placed under META-INF directory and
META-INF/subdirectory respectively (with separate
uri's)

(a.jar)
 -- META-INF
      -- someNotDef.tld (uri - abc)
      -- subDir
           -- someNotDef.tld (uri - xyz)

This jar is not mapped in the web.xml.

Both the tlds's are read and i get the expected output
from the jsp.


Scenario - 2
------------

A single taglib is placed as someDef.tld under
META-INF dir of the jar.

This jar is mapped in the web.xml.

Now the parser is looking just for the taglib.tld in
the META-INF directory and i get the following
stack-trace

org.apache.jasper.JasperException: Unable to read TLD
"META-INF/taglib.tld" from JAR file
"file:/home/ambrish/tools/jakarta-tomcat-5.0.4/webapps/tld_pick_dh/WEB-INF/lib/notDef.jar":
java.lang.NullPointerException
	at
org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:94)
	at
org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:365)
	at
org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:216)
	at
org.apache.jasper.compiler.TagLibraryInfoImpl.(TagLibraryInfoImpl.java:203)
	at
org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:456)
	at
org.apache.jasper.compiler.Parser.parseDirective(Parser.java:517)
	at
org.apache.jasper.compiler.Parser.parseElements(Parser.java:1567)
	at
org.apache.jasper.compiler.Parser.parse(Parser.java:174)
	at
org.apache.jasper.compiler.ParserController.parse(ParserController.java:254)
	at
org.apache.jasper.compiler.ParserController.parse(ParserController.java:154)
	at
org.apache.jasper.compiler.ParserController.parse(ParserController.java:140)
	at
org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:250)
	at
org.apache.jasper.compiler.Compiler.compile(Compiler.java:458)
	at
org.apache.jasper.compiler.Compiler.compile(Compiler.java:444)
	at
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:603)
	at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:300)
	at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:293)
	at
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:240)
	at
javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
	at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:286)
	at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
	at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
	at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:562)
	at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:974)
	at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:205)
	at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
	at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:562)
	at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:974)
	at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:177)
	at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
	at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171)
	at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:149)
	at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172)
	at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:149)
	at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:562)
	at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:974)
	at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:156)
	at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
	at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:562)
	at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:974)
	at
org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:203)
	at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:637)
	at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:488)
	at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:568)
	at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:631)
	at java.lang.Thread.run(Thread.java:534)


My query is while in the first scenario tomcat was
smart enough to match the uri's for all the available
tld's even when they are not mapped in web.xml; while
in the second scenario - if explicitly mapped it
throws the JasperEeception of not able to find the
META-INF/taglib.tld.


I think that any tld if present in the META-INF
subdirectory of the jar should be picked.

Here are the respective spec sections:

JSP.7.2.1 Packaged Tag Libraries 
JSP page authoring tools and JSP containers are
required to accept a tag library that is packaged as a
JAR file. When deployed in a JSP container, the
standard JAR conventions described in the Servlet 2.3
specification apply, including the conventions for
dependencies on extensions. Packaged tag libraries
must have at least one tag library descriptor file.
The JSP 1.1 specification allowed only a single TLD,
in META-INF/taglib.tld, but in JSP 1.2 multiple tag
libraries are allowed. See Section JSP.7.3.1 for how
TLDs are identified.

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. The DTD for a
TLD document is
"http://java.sun.com/dtd/webjsptaglibrary_ 1_2.dtd"


Thanks,
A Misra

__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org