Mark Roth wrote:
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.

Thanks for the explanations :)


Rémy


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to