I'm not arguing with the overall intent of your change. Rather I believe that calling the constructor during compilation is wasteful and improper as the environment *can* differ between compilation and runtime. Also, the fact that a failure to compile in this fashion generates a partial Java source means that once a compilation fails due to an environmental issue it will continue to fail even when the environment is corrected (e.g. when another server comes back up). That's certainly not appropriate.I think your only valid point is the one about the need to make errorOnUseBeanInvalidClassAttribute be switchable from Jspc main, but we are not bundling jspc scripts anymore, so I didn't feel there is a need for it. Anyway, its value can be set with an ant task.
Otherwise, Jasper behaves the same as before when errorOnUseBeanInvalidClassAttribute is set to false. Well, maybe it take more time to compile, but that's a compile-time vs. runt-time tradeoff that all compilers make.
The ideas behind the fix, both in the Jasper and the JSP 2.0 spec, is
to allow the Jasper to generate faster code and to catch as much
errors as possible at compile time. For the embedded compilations, the
comile environment is the same as the runitme (request time) environment,
so there is no problem. For Jspc compilations, you'll just need to make
sure that they are the same, otherwise you'll need to set
errorOnUseBeanInvalidClassAttribute to false there.
If you have ideas about how to modify Generator that works better, pleaseI must profess ignorance as to how to submit an official patch (e.g. how to generate one), but here's a diff with Generator.java version 1.230 from CVS of what I'm suggesting:
submit a patch, and I'll see if it can be incorporated.
22a23
> *import java.lang.reflect.Constructor;*
1224c1225,1226
< bean.newInstance();
---
> // Next line will throw exception if
public no-args constructor cannot be found
> *Constructor constructor =
bean.getConstructor( new Class[] {} );
*Essentially, I'm suggesting we check for the existence of the default constructor, but don't call it. That takes the same amount of real code (2 more lines thanks to my import and gratuitous comment) and avoids (1) actually constructing the bean during compilation and (2) making any unnecessary assumptions about compilation vs. runtime environmental conditions.
Applying this diff to Generator.java addresses my issue and I believe is an overall improvement and better aligned with the JSP specification. I would greatly appreciate it if this could be incorporated into the Jasper/Tomcat source stream.
-- Jess Holle [EMAIL PROTECTED]
