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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
