tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Danno Ferrin" <>
Subject Re: Incorrect code for custom actions [Was: Re: 3.2 beta status update]
Date Mon, 03 Jul 2000 06:24:20 GMT
Here is a quick fix that should solve the problem in a single threaded
environment.  And you are right on about the race conditions, where multiple
paralell compilations could cause a race, but there is a lock in JspServlet
where it locks on "this" that solves most races, but in the case where a
pool of servlet instances services the JspServlet there could be a
colission.  IIRC such pooling is not barred by the spec, (and there are
other ways to induce that race) so synching on  TagGeneratorBase.class in
lines 178-183 of .../jasper/compiler/ should end that race, it
appears to me to be the best gate point around the JspParseEventListener
class, which is the only class to use instances of TagGeneratorBase
sub-classes and classes.  A better long-term solution would be to move the
services provided by those static classes into the JspCompliationContext
class (which would require an API change which instantly makes it a 3.3

But I digress, here is a patch you can try.

RCS file:
retrieving revision 1.14
diff -U3 -r1.14
---      2000/06/14 22:51:52     1.14
+++      2000/07/03 05:46:16
@@ -199,11 +199,13 @@
                    String attrName = attributes[i].getName();
                    Method m = tc.getSetterMethod(attrName);

-                   if (m == null)
+                   if (m == null) {
+                       tagEnd();
                        throw new CompileException
                            (start, Constants.getString
                              new Object[] { attrName }));
+                   }

----- Original Message -----
From: "Hans Bergsten" <>
To: <>
Sent: Sunday, July 02, 2000 9:56 PM
Subject: Incorrect code for custom actions [Was: Re: 3.2 beta status update]

> Hans Bergsten wrote:
> > [...]
> > I've tested the 3.2 beta with two tag libraries that were working fine
> > Tomcat 3.1, using JDK 1.3 and JDK 1.2.2 on Windows NT. I noticed the
> > following problems:
> > [...]
> > 3) Incorrect code generated for some custom actions.
> Okay, I believe I have tracked down this problem now. But since the code
> generating the JSP implementation class is far from obvious, I would
> if someone who's familiar with the code can confirm my findings.
> The problem occurs in this scenario. First, the generation of the JSP
> implementation
> class for one page fails, due to a missing setter method for a custom
> attribute. This results in a CompileException being thrown by the
> TagBeginGenerator
> generateSetters() method. This is the expected behavior.
> After this failure, though, processing of *any* page containing a custom
> results in invalid code being generated. Example:
>   com.ora.jsp.tags.counter.IncrementCounterTag
_jspx_th_ora_incrementCounter_0 =
>     new com.ora.jsp.tags.counter.IncrementCounterTag();
>   _jspx_th_ora_incrementCounter_0.setPageContext(pageContext);
>   _jspx_th_ora_incrementCounter_0.setParent(_jspx_th_iob_dbStore_0);
> The _jspx_th_iob_dbStore_0 variable refers to the tag handler in the first
> i.e. the one with the missing setter method; it's not defined at all in
> page.
> The reason is that the state of a static variable in TagGeneratorBase is
>     static private Stack tagHandlerStack = new Stack();
> This Stack seems to be intended to hold the nesting hierarchy for action
> elements within a page. I have not traced through all code, but it seems
> if the code generation goes well, the state of the Stack is maintained by
> equal number of push() and pop() calls, but if the code generation fails,
> is left on the Stack.
> I can't understand why this is a static variable; making it a regular
> variable should solve the problem since a new instance of TagGeneratorBase
> created for each page. Having it as a static probably means that there are
> multi-threading issues as well, even though I haven't run into them yet.
> There's one more static in this class:
>     static private Hashtable tagVarNumbers = new Hashtable();
> I'm not sure how it's used, but it can probably cause similar problems.
> My suggestion is to simple make both these variables regular instance
> If I'm missing something, please let me know.
> Hans
> --
> Hans Bergsten
> Gefion Software
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message