tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <>
Subject Re: Tomcat 5.0.20 Issue
Date Wed, 24 Mar 2004 15:56:04 GMT
Jess Holle wrote:
> Jess Holle wrote:
>> Works just great in quick testing at least.
>> I'm still waiting for my precompilation script to return to determine 
>> whether Jasper still compiles everything it used to (and should have).
> Unfortunately, Tomcat 5.0.20 cannot compile 6 out our 985 JSP pages 
> (which Tomcat 5.0.19 compiled just fine).
> The issue can be traced directly to a single entry in the change log:
>    Add some intellignece to the compiler for generating code for
>    useBean action. Generate direct instantiation (use new) when
>    possible, use bean.instantiate when bean name is specified, and for
>    the case of invalid bean class, either issue a translation time
>    error (instead of javac error), or generate codes to throw
>    InstantiationException at runtime, depending on a new compiler
>    switch, errorOnUseBeanInvalidClassAttribute(defaulted to true) (kinman)
> There are several issues with this change:
>   1. The new logic assumes that the bean can be directly instantiated
>      /at compile time/ and throws a page compilation error when this is
>      not the case.
>          * There are beans that can be directly instantiated at run
>            time but not at compile time (e.g. upon precompilation). 
>            This was the case in all 6 of our failures.  [Examples as to
>            when this might occur include requirements for databases
>            being accessible, other servers running, etc, etc, for
>            successful bean instantiation.]
>          * The error occurs in such a way that a partial Java source
>            file is written, so later attempts to recompile the page
>            (when the runtime environment is duplicated) also fail
>            unless the partial Java source file is first deleted.
>   2. I note the errorOnUseBeanInvalidClassAttribute setting but there
>      are issues here as well:
>          * The default value, true, breaks existing code.
>          * If errorOnUseBeanInvalidClassAttribute  is set to false:
>                o Instantiation of some (e.g. session or application
>                  scope) beans can be time and/or resource consuming. 
>                  Besides being an invalid test as to whether a bean can
>                  be directly instantiated, instantiating such beans
>                  during compilation can be costly.  [The combined time
>                  for precompiling all pages was longer in 5.0.20 with
>                  this behavior in place than when I removed it.]
>                o The new behavior will cause beans to be instantiated
>                  via Beans.instantiate() rather than directly
>                  instantiated when compile time direct instantiation
>                  fails.  This leads to a performance degradation
>                  whenever a bean has a runtime instantiation dependency.
>          * As best I can tell, errorOnUseBeanInvalidClassAttribute is
>            not accessible from / exposed via JspC main -- which I use
>            from my pre-compilation scripts for various reasons.
> Due to these issues I have reverted this change in Generator to the 
> 5.0.19 state (leaving the other valuable changes in this class intact).  
> Once I did so all 985 JSP pages compiled -- including the 6 that had 
> previously failed.
> I would urge that this change be reverted -- either in this release (or 
> an immediate 5.0.21 release) or immediately changed in HEAD for the next 
> release.

Well, your pages are invalid. Really, I don't see what's so mysterious: 
anything used in useBean must be a JavaBean.
This will not be fixed.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message