You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by David Jencks <da...@yahoo.com> on 2009/12/13 10:50:28 UTC
Problem using maven jspc plugin with tomcat 7 and jstl
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
Re: Problem using maven jspc plugin with tomcat 7 and jstl
Posted by David Jencks <da...@yahoo.com>.
Mark,
I've verified that your fix in rev 890479 works great for this.
Many thanks for fixing it so quickly!
david jencks
On Dec 14, 2009, at 11:25 AM, Mark Thomas wrote:
> On 14/12/2009 03:58, David Jencks wrote:
>> I can verify by experiment that the 2nd solution fixes the problem
>> with
>> jspC. I agree that there's a strong case to be made for moving
>> DefaultJarScanner to org.apache.tomcat but doing so introduces a
>> lot of
>> dependencies from that package to
>>
>> org.apache.tomcat.util.res.StringManager
>> org.apache.juli.logging.LogFactory
>> org.apache.catalina.startup.Constants
>>
>> I could resolve these but the results would probably not be
>> consistent
>> with whatever policy tomcat has on dependencies. However if this
>> would
>> be helpful I'll be happy to supply a patch.
>
> I'm in the middle of fixing this now. I'm going with option 2 since
> when
> I looked into the refactoring for option 1 last night there is more
> required than I really want to do at this stage of Tomcat 7
> development.
>
> Mark
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Problem using maven jspc plugin with tomcat 7 and jstl
Posted by Mark Thomas <ma...@apache.org>.
On 14/12/2009 03:58, David Jencks wrote:
> I can verify by experiment that the 2nd solution fixes the problem with
> jspC. I agree that there's a strong case to be made for moving
> DefaultJarScanner to org.apache.tomcat but doing so introduces a lot of
> dependencies from that package to
>
> org.apache.tomcat.util.res.StringManager
> org.apache.juli.logging.LogFactory
> org.apache.catalina.startup.Constants
>
> I could resolve these but the results would probably not be consistent
> with whatever policy tomcat has on dependencies. However if this would
> be helpful I'll be happy to supply a patch.
I'm in the middle of fixing this now. I'm going with option 2 since when
I looked into the refactoring for option 1 last night there is more
required than I really want to do at this stage of Tomcat 7 development.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Problem using maven jspc plugin with tomcat 7 and jstl
Posted by David Jencks <da...@yahoo.com>.
On Dec 13, 2009, at 12:46 PM, Mark Thomas wrote:
> On 13/12/2009 09:50, David Jencks wrote:
>> 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.
>
> Your analysis looks spot on to me.
>
>> 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.
>
> Yep, it's a bug.
>
>> 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.
>
> The motivation behind the original change was to:
> - make TLD handling consistent between Jasper and Tomcat (there are
> some
> edge case anomalies in 6.0.x)
> - reduce code duplication (there is still a lot of duplication between
> TldLocationCache and o.a.c.startup.TldConfig)
>
> Something to keep in mind is that Jasper should not have any
> dependencies on Tomcat. At the moment, there are a few shared
> interfaces
> in o.a.tomcat but no implementation.
>
> The options I can think of off-hand are:
> - refactor the DefaultJarScanner to o.a.tomcat (or a sub-package) and
> add it to the tomcat-api.jar (maybe rename the jar)
> - copy the DefaultJarScanner to the o.a.jasper package
>
> The second option is the simplest but I like the first as it
> provides a
> basis for removing some of the other duplication (eg around TLDs)
> between Tomcat core and Jasper.
I can verify by experiment that the 2nd solution fixes the problem
with jspC. I agree that there's a strong case to be made for moving
DefaultJarScanner to org.apache.tomcat but doing so introduces a lot
of dependencies from that package to
org.apache.tomcat.util.res.StringManager
org.apache.juli.logging.LogFactory
org.apache.catalina.startup.Constants
I could resolve these but the results would probably not be consistent
with whatever policy tomcat has on dependencies. However if this
would be helpful I'll be happy to supply a patch.
BTW I really appreciate that the classes formerly in org.apache got
moved to org.apache.tomcat
many thanks
david jencks
>
> Mark
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Problem using maven jspc plugin with tomcat 7 and jstl
Posted by Mark Thomas <ma...@apache.org>.
On 13/12/2009 09:50, David Jencks wrote:
> 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.
Your analysis looks spot on to me.
> 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.
Yep, it's a bug.
> 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.
The motivation behind the original change was to:
- make TLD handling consistent between Jasper and Tomcat (there are some
edge case anomalies in 6.0.x)
- reduce code duplication (there is still a lot of duplication between
TldLocationCache and o.a.c.startup.TldConfig)
Something to keep in mind is that Jasper should not have any
dependencies on Tomcat. At the moment, there are a few shared interfaces
in o.a.tomcat but no implementation.
The options I can think of off-hand are:
- refactor the DefaultJarScanner to o.a.tomcat (or a sub-package) and
add it to the tomcat-api.jar (maybe rename the jar)
- copy the DefaultJarScanner to the o.a.jasper package
The second option is the simplest but I like the first as it provides a
basis for removing some of the other duplication (eg around TLDs)
between Tomcat core and Jasper.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org