JSTL confused by overloading accessor methods
Hello,
I've just spent about eight hours trying to figure out a bug in my
web-app and it seems to have been caused by overloading a set method.
This occurred after I all at once added a new attribute and three
accessor methods to one of my java classes. When I referred to the
attributes in c:xxx tags I got errors that the value
'attributeName' was not found in an object of class It's the same
error you get from referring to an attribute that actually doesn't
exist.
The class I added these new attributes to is an abstract superclass
for all the java beans in my app. Here's what I added:
private Vector analyticalNotes = null;
public void setAnalyticalNotes(Vector analyticalNotes)
{ this.analyticalNotes = analyticalNotes; }
public Vector getAnalyticalNotes()
{ return analyticalNotes; }
public void setAnalyticalNotes( String sql )
{ do some jdbc stuff then setAnalyticalNotes with a new Vector }
Here is the JSTL code that was causing the error. The object was in
the request and I was able to access the analyticalNotes attribute
through jsp scripting.
c:out value=${ requestScope.termTestBean.analyticalNotes } / br /
I had to change the number of parameters in the signature of the
overloading method to stop the error. So here's what I now have and
everything is working now:
public void setAnalyticalNotes( String sql, Object
nullObjectNeverUsedInMethod )
I tried actually changing String to many other things but in the end
I had to add a new parameter. I can get by without a solution for
this but it seems a little weird.
I'm running Tomcat 4.1.12 on Java 1.3 on Mac OS X. I get the same
error with the JSTL 1.0.2 release AND with the nightly build. Any
ideas what's up with this?
Sincerely,
Travis McCauley
Tibetan and Himalayan Digital Library
University of Virginia
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JSTL confused by overloading accessor methods
On Thu, 9 Jan 2003, Travis McCauley wrote: I've just spent about eight hours trying to figure out a bug in my web-app and it seems to have been caused by overloading a set method. This is by design -- or at least the expected behavior. The JavaBeans introspector ignores overloaded methods when looking for properties. For a JavaBean property 'xxx' to exist (in the default case without BeanInfo classes), three things must be true: - A getXxx() method or setXxx() method must exist. - If they both exist, the return type of getXxx() must match the type of the formal parameter in setXxx(). That is, in TYPE getXxx() and void setXxx(TYPE x) 'TYPE' must be the same. - No more than one setXxx() method may exist. -- Shawn Bayern JSTL in Action http://www.manning.com/bayern -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tag Instantiation With JSP 1.2
Thanks Pierre, This helped alot, however I still had to clear out some data structures for this to work. I.e. some tags were doing database lookups and each iteration was appending the results. I just cleared the container before the lookup. This confused me still because I would have thought that said database container would be created each time the tag got instantiated since it was a data member. Perhaps there is no actual re-instantiation with enablePooling but rather just the lifecycle completed (i.e. doStartTag() - doEndTag )? Tony --- Pierre Delisle [EMAIL PROTECTED] wrote: Tag reuse is the default behavior for Jasper2 used in Tomcat 4.1.x. Check the docs at http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jasper-howto.html Configuration parameter enablePooling determines whether tag handler pooling is enabled. It defaults to true. The following references will give you better insight into tag-reuse and should help you fix the implementation of your tags so they can behave properly in containers that support tag-reuse. JSP 1.2: Great News for the JSP Community, Part 2 [Written by Hans Bergsten. Check the section on Tag handler life cycle and instance reuse] http://www.onjava.com/pub/a/onjava/2001/11/07/jsp12.html Taglib Developer Guidelines [Written by Shawn Bayern. You won't have any more problems with tag reuse if you follow these guidelines] http://jakarta.apache.org/taglibs/guidelines.html -- Pierre Tony Colson wrote: I have read various email trails and looked at the JSP 1.2 spec and am still unclear on something regarding custom tags: I recently upgraded to tomcat 4.1.18 which uses the JSP 1.2 spec and in the case custom:TagA custom:TagB / /custom:TagA where TagA re-evaluates the body several times, it seems that TagB only gets instantiated once and re-used. This doesn't seem right to me (even after reading the specs) especially since it worked with previous versions os tomcat using JSP 1.1. I would think that after the TagB.doEndTag() function the container would release() it and thus neccessitate the creation of a new TagB object on the next iteration. This is important to me because I have underlying data structures which are not behaving correctly because of this. Is this a bug? Are there ways to force it to always instantiate a new TagB? Are there alternate containers we can use? Thanks Tony __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
