Jar scanning for tld files seems to have been refactored recently in
rev 817685 (sept 22 2009) with the introduction of the jasper
JarScannerFactory.
I'm getting a stack trace:
[INFO] [jspc:compile {execution: default}]
Created dir: /Users/david/projects/geronimo/server/trunk/plugins/
activemq/activemq-portlets/target/jsp-source
[INFO] Compiling JSP source files to /Users/david/projects/geronimo/
server/trunk/plugins/activemq/activemq-portlets/target/jsp-source
[INFO]
------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO]
------------------------------------------------------------------------
[INFO] The absolute uri: http://java.sun.com/jsp/jstl/core cannot be
resolved in either web.xml or the jar files deployed with this
application
[INFO]
------------------------------------------------------------------------
[INFO] Trace
org.apache.jasper.JasperException: The absolute uri: http://java.sun.com/jsp/jstl/core
cannot be resolved in either web.xml or the jar files deployed with
this application
at
org
.apache
.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:
51)
at
org
.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:
409)
at
org
.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:
116)
at
org
.apache
.jasper
.compiler
.TagLibraryInfoImpl.generateTLDLocation(TagLibraryInfoImpl.java:322)
at
org
.apache
.jasper.compiler.TagLibraryInfoImpl.<init>(TagLibraryInfoImpl.java:154)
at
org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:430)
at
org.apache.jasper.compiler.Parser.parseDirective(Parser.java:494)
at
org.apache.jasper.compiler.Parser.parseElements(Parser.java:1440)
at org.apache.jasper.compiler.Parser.parse(Parser.java:136)
at
org
.apache.jasper.compiler.ParserController.doParse(ParserController.java:
239)
at
org
.apache.jasper.compiler.ParserController.parse(ParserController.java:
103)
at
org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:171)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:
333)
at org.apache.jasper.JspC.processFile(JspC.java:1005)
at org.apache.jasper.JspC.execute(JspC.java:1154)
at
org
.codehaus
.mojo
.jspc.compiler.tomcat6.JspCompilerImpl.compile(JspCompilerImpl.java:111)
(we've configured the jspc plugin to use jasper from tomcat 7)
The jsp generation used to work fine with tomcat 6.0.20.
It looks to me as if the problem is that no JarScanner is installed
in the ServletContext used by JspC. (There definitely isn't one
installed, and I think that is the cause of the problem). So, jasper
cant find the jstl jar which is in the classloader all this is running
with.
I don't see how it would be possible for a JarScanner to get installed
so I'm wondering if there is a bug and what a way to fix it or work
around it might be.
JspC.execute has at line 1115
if( context==null ) {
initServletContext();
}
and proceeds directly to call processFile at line 1154 leading to the
error.
Going back a bit
protected void initServletContext() {
try {
context =new JspCServletContext
(new PrintWriter(System.out),
new URL("file:" + uriRoot.replace('\\','/') + '/'));
tldLocationsCache = new TldLocationsCache(context);
sets the context and supplies it to TkdLocationsCache which eventually
goes fishing for the JarScanner.
I don't see any opportunities for integration code to add a JarScanner
to the context without subclassing perhaps JspC.
Before proposing any code changes it would be great to have some
advice on how this is supposed to work and confirmation that my
theories on what is wrong are reasonable.
thanks
david jencks
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
