You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Jess Holle <je...@ptc.com> on 2004/03/24 16:50:43 UTC
Tomcat 5.0.20 Issue
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.
--
Jess Holle
Re: Tomcat 5.0.20 Issue
Posted by Jess Holle <je...@ptc.com>.
Remy Maucherat wrote:
> 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.
Did I miss something?
Are JavaBean default constructors required to succeed in any/all
environments?
Specifically are they required to succeed at compile time when none of
the runtime requirements they have are met?
This seems somewhat odd to say the least.
That said, I did not author any of the beans in question and could
certainly give the authors of said beans hell for their transgressions
*IF* I have sufficient proof that what they're doing is completely wrong.
Overall, however, the change in 5.0.20 still seems questionable -- at
least with respect to the many other details (e.g. that the default
causes new failures, that the compiler flag is not accessible via
JspC.main(), etc...)
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tomcat 5.0.20 Issue
Posted by Remy Maucherat <re...@apache.org>.
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.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tomcat 5's service.bat, etc.
Posted by Jess Holle <je...@ptc.com>.
Bill Barker wrote:
>>The service.bat and tomcat.exe in Tomcat 5 have a number of issues as I
>>see it:
>>
>> 1. The new tomcat.exe (aka procrun) does not seem to reliably route
>> stdout and stderr to the specified files.
>> * Compare JavaService (aka Tomcat 4.1.x's tomcat.exe) stdout
>> and stderr treatment to procrun's. JavaService captures all
>> the startup stdout as well as System.out.println's, etc.
>> procrun does not.
>>
>>
>Procrun works fine with --Java=java. Yes, it needs work
>for --Java=c:\path\to\jvm.dll (known issue, with outstanding BZ entry :).
>
>
Hmmm....
--Java=pathToJvmDll did not work at all for me -- service failed to
install and other errors. [W2K with latest service packs and Java 2
v1.4.2_04.]
--Java=java worked but lost most of the stdout and stderr output --
including all the startup output. It did seem to start up faster than
JavaService...
>> 2. Tomcat 5 does not include any documentation on how to use procrun
>> (or even that tomcat.exe is procrun).
>> 3. I have not managed to get procrun to target the "server" JVM (as
>> opposed to the client) in any reliable fashion.
>> * With JavaService this was achieved by targeting the
>> appropriate jvm.dll. The procrun docs say the same thing is
>> possible, but this does not work.
>>
>>
>
>This works fine for me with either --Java=java -JavaOptions=-server#... or
>with --Java=c:\path\to\server\jvm.dll.
>
>
I was actually referring to the latter approach, which as I said did not
work for me.
I did not honestly trust the first approach -- I guess I should have....
>> 4. service.bat does not route as many arguments to procrun as what I
>> for one route to JavaService -- and thus it provides less
>> flexibility (especially with no documentation).
>> * For JavaService I provide heap sizing, etc, parameters, as
>> this is critical to any real use of Tomcat.
>> * Having built in support for passing JPDA debug args to the
>> JVM is also a must.
>>
>>
>So edit the service.bat file :). As usual, patches are always welcome ;-).
>
>
The fact that you have to replace all spaces with #'s and shovel all
JAVA_OPTS or CATALINA_OPTS into a single argument makes it more
difficult to just pass in and concatenate portions of the command line.
With JavaService, one can do:
set javaMemArgs=...
set debugArgs=...
set javaPropArgs=...
set javaArgs=%javaMemArgs% %debugArgs% %javaPropArgs%
JavaService.exe -install %serviceName% %jvmDllArg% %javaArgs%
%startArgs% %stopArgs% %stdioArgs% %currDirArgs%
In other words, one can flexibly and easily insert additional
arguments. With procrun, I have to worry about replacing some spaces
with #'s, properly escaping quotes, etc, within the aggregate argument
containing all the Java arguments, etc.
Essentially this makes it harder to have a one-size fits (most) all script.
>> 5. service.bat does not provide any default handling of tools.jar.
>> * By default the resulting service can't compile JSP pages.
>>
>>Overall, service.bat and procrun feel like they're not ready for
>>production use -- which is fine as long as that's understood by the user
>>community.
>>
>>
I should clarify that another reason for this was a number of crashes I
had just installing and removing my service with procrun.
--
Jess Holle
Re: Tomcat 5's service.bat, etc.
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Jess Holle" <je...@ptc.com>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Wednesday, March 24, 2004 11:18 AM
Subject: Tomcat 5's service.bat, etc.
> The service.bat and tomcat.exe in Tomcat 5 have a number of issues as I
> see it:
>
> 1. The new tomcat.exe (aka procrun) does not seem to reliably route
> stdout and stderr to the specified files.
> * Compare JavaService (aka Tomcat 4.1.x's tomcat.exe) stdout
> and stderr treatment to procrun's. JavaService captures all
> the startup stdout as well as System.out.println's, etc.
> procrun does not.
Procrun works fine with --Java=java. Yes, it needs work
for --Java=c:\path\to\jvm.dll (known issue, with outstanding BZ entry :).
> 2. Tomcat 5 does not include any documentation on how to use procrun
> (or even that tomcat.exe is procrun).
> 3. I have not managed to get procrun to target the "server" JVM (as
> opposed to the client) in any reliable fashion.
> * With JavaService this was achieved by targeting the
> appropriate jvm.dll. The procrun docs say the same thing is
> possible, but this does not work.
This works fine for me with either --Java=java -JavaOptions=-server#... or
with --Java=c:\path\to\server\jvm.dll.
> 4. service.bat does not route as many arguments to procrun as what I
> for one route to JavaService -- and thus it provides less
> flexibility (especially with no documentation).
> * For JavaService I provide heap sizing, etc, parameters, as
> this is critical to any real use of Tomcat.
> * Having built in support for passing JPDA debug args to the
> JVM is also a must.
So edit the service.bat file :). As usual, patches are always welcome ;-).
> 5. service.bat does not provide any default handling of tools.jar.
> * By default the resulting service can't compile JSP pages.
>
> Overall, service.bat and procrun feel like they're not ready for
> production use -- which is fine as long as that's understood by the user
> community.
>
> Personally, JavaService and an Ant script to produce the right
> (enormous) command line for seem to do the trick nicely -- with Tomcat
> 4.1.x and 5.0.x.
>
Whatever makes you happy ;-).
> --
> Jess Holle
>
>
Tomcat 5's service.bat, etc.
Posted by Jess Holle <je...@ptc.com>.
The service.bat and tomcat.exe in Tomcat 5 have a number of issues as I
see it:
1. The new tomcat.exe (aka procrun) does not seem to reliably route
stdout and stderr to the specified files.
* Compare JavaService (aka Tomcat 4.1.x's tomcat.exe) stdout
and stderr treatment to procrun's. JavaService captures all
the startup stdout as well as System.out.println's, etc.
procrun does not.
2. Tomcat 5 does not include any documentation on how to use procrun
(or even that tomcat.exe is procrun).
3. I have not managed to get procrun to target the "server" JVM (as
opposed to the client) in any reliable fashion.
* With JavaService this was achieved by targeting the
appropriate jvm.dll. The procrun docs say the same thing is
possible, but this does not work.
4. service.bat does not route as many arguments to procrun as what I
for one route to JavaService -- and thus it provides less
flexibility (especially with no documentation).
* For JavaService I provide heap sizing, etc, parameters, as
this is critical to any real use of Tomcat.
* Having built in support for passing JPDA debug args to the
JVM is also a must.
5. service.bat does not provide any default handling of tools.jar.
* By default the resulting service can't compile JSP pages.
Overall, service.bat and procrun feel like they're not ready for
production use -- which is fine as long as that's understood by the user
community.
Personally, JavaService and an Ant script to produce the right
(enormous) command line for seem to do the trick nicely -- with Tomcat
4.1.x and 5.0.x.
--
Jess Holle
Re: Tomcat 5.0.20 Issue
Posted by Jess Holle <je...@ptc.com>.
P.S. Nothing in the quoted spec segments implies that the JSP compiler
should attempt to actually *instantiate* beans at compile time or expect
that that should work.
--
Jess Holle
Jess Holle wrote:
> Based on the given bug id, I would propose a different implementation
> than that found in 5.0.20.
>
> Specifically I would suggest that Generator:
>
> 1. Try to load the given class.
> 2. Look up its default (no-args) constructor via reflection. [This
> is the key part, look up the constructor but don't call it!]
> 3. If a public no-args constructor IS found, then code should be
> generated to use it to directly instantiate the bean.
> 4. If a public no-args constructor is NOT found, then a page error
> should be generated and Beans.instantiate() should be used if
> errorOnUseBeanInvalidClassAttribute is set to false.
>
> This should be more efficient, avoid breaking pages using beans with
> non-trivial environmental constraints for successful construction, and
> follow the letter of the spec better as I see it.
>
> --
> Jess Holle
>
> Tim Funk wrote:
>
>> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26444
>>
>> -Tim
>>
>> Jess Holle wrote:
>>
>>> Jess Holle wrote:
>>>
>>> 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)
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>>
>>
>
Re: Tomcat 5.0.20 Issue
Posted by Jess Holle <je...@ptc.com>.
Based on the given bug id, I would propose a different implementation
than that found in 5.0.20.
Specifically I would suggest that Generator:
1. Try to load the given class.
2. Look up its default (no-args) constructor via reflection. [This
is the key part, look up the constructor but don't call it!]
3. If a public no-args constructor IS found, then code should be
generated to use it to directly instantiate the bean.
4. If a public no-args constructor is NOT found, then a page error
should be generated and Beans.instantiate() should be used if
errorOnUseBeanInvalidClassAttribute is set to false.
This should be more efficient, avoid breaking pages using beans with
non-trivial environmental constraints for successful construction, and
follow the letter of the spec better as I see it.
--
Jess Holle
Tim Funk wrote:
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26444
>
> -Tim
>
> Jess Holle wrote:
>
>> Jess Holle wrote:
>>
>> 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)
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
Re: Tomcat 5.0.20 Issue
Posted by Tim Funk <fu...@joedog.org>.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26444
-Tim
Jess Holle wrote:
> Jess Holle wrote:
>
> 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)
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org