Your test for bad beans is much weaker than what it is now. For instance,
you do not catch the case where the bean class is abstract.
However, I am sympathetic to your view on this. If I can be convinced that
we have covered all checks that we can do without too much trouble, I'll
fix Jasper.
-Kin-man
> Date: Tue, 30 Mar 2004 08:30:05 -0600
> From: Jess Holle <[EMAIL PROTECTED]>
> Subject: Re: Tomcat 5.0.20 Issue
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> X-OriginalArrivalTime: 30 Mar 2004 14:30:06.0040 (UTC)
FILETIME=[7EEF4580:01C41663]
>
> Kin-Man Chung wrote:
>
> >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.
> >
> >
> 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.
>
> >If you have ideas about how to modify Generator that works better, please
> >submit a patch, and I'll see if it can be incorporated.
> >
> >
> I 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:
>
> 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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
