tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Problem using maven jspc plugin with tomcat 7 and jstl
Date Mon, 14 Dec 2009 03:58:03 GMT

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


Mime
View raw message