tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Roth <Mark.R...@Sun.COM>
Subject Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java
Date Mon, 02 Feb 2004 23:26:36 GMT
Okay, I took a look at the patch and the bug report and I think I know 
what's going on now.  Please let me know if I do not understand the 
scenario correctly.

It seems there are some JSP 1.2 pages that misuse <jsp:useBean> by doing 
one of the following:

   1. The class attribute is used for a Java type that cannot
      be instantiated as a JavaBean.
   2. Type or class specifies a type that cannot be found.

There are some cases where pages can get away with (1) if the container 
decides to flag this as a runtime error.  These pages are invalid but 
the container never calls them on it because the objects already exist 
in some scope.  This is probably less likely with (2), but still 
possible (e.g. if the <jsp:useBean> never gets executed at all).

It would be nice to get a translation error in this case so that you 
realize your page is invalid.  However, the JSP 1.2 specification (on 
which Tomcat 4.x is based) does not allow for a translation error - it 
requires that a runtime exception must be thrown.

In JSP 2.0 (on which Tomcat 5.x is based), a number of JSP container 
vendors complained about this and wanted the freedom to throw a 
translation error in this case.  Doing so is better for the page author 
(since they know up front their page is invalid) and better for the 
container (since doing a 'new' is MUCH more efficient than doing a call 
to Beans.instantiate()).  So, we added a provision to allow containers 
to optionally produce a translation error on these invalid pages.

One unfortunate side-effect is that some pages that used to compile in 
Tomcat 4 will no longer compile in Tomcat 5.  But it's important to 
realize that these pages are invalid in both specs.  It's just that 
Tomcat 4 was not allowed to cause an error at translation time.  It had 
to wait until runtime to do so.

So where does this leave us with respect to this patch?  Tomcat 5 is 
free to exhibit either behavior.  It can throw a translation error or a 
runtime error for these invalid pages.  In my opinion, it is much better 
for both the page author and the container if we produce a 
translation-time error.  The page author knows their page is invalid 
right away (without having to exercise the code path), and the container 
can gain the performance benefits associated with doing a 'new' call 
directly (instead of Beans.instantiate()).

So it's your call, but if I had a vote I'd say stick with Kin-Man's patch.

Hope this helps.

---
Mark Roth, Java Software
JSP 2.0 Co-Specification Lead
Sun Microsystems, Inc.



Remy Maucherat wrote:
> Kin-Man Chung wrote:
> 
>> Agreed that the spec can be clearer.  :-)
>>
>> This has been discussed by the Spec expert group, and bullet .2 was added
>> because some vendors wanted it.  I'll check with the spec lead for a
>> clarification.
> 
> 
> Ok.
> 
>> Also agreed that this breaks backward compatibility; but it not really 
>> too
>> bad.  I think a lot of users would rather have the error at compilation
>> time than at runtime.  What can you do with an instantiation error at
>> runtime?
> 
> 
> Nothing, but some don't care: they never intended their page to be 
> called without the right attribute in the right scope, so the case where 
> their "JavaBean" is instantiated never happens.
> 
>> If we are really concern about BC, then we can add another compilation
>> option to revert to old behavior.  I really don't like another switch, 
>> but
>> if it'll make people happy...
> 
> 
> No new switch, please ;) So we have to decide one or the other.
> So do you want me to revert the patch ?
> 
> Rémy
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message