On Fri, 20 Sep 2002, Jeff wrote:
> Date: Fri, 20 Sep 2002 13:01:50 -0400
> From: Jeff <[EMAIL PROTECTED]>
> Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Jasper Bug, or just a rule I wasn't aware of?
>
> Is there an official rule against creating a BodyTag-implementing class like
> the following example, or did I just find a bug in Jasper/Tomcat/elsewhere?
>
The former. Tag properties need to follow JavaBeans design patterns, and
overloading the setResult() method like this is not allowed.
Craig
> <!-- the tld specifies that "result" is a mandatory attribute of type
> String, and the "meltdown" tag's handler class is MeltdownTag -->
> <mytag:meltdown result="boom"/>
>
> public class MeltdownTag implements BodyTag {
> ...
> private String sound;
> private FooObject result;
> ...
> public void setResult(String result) { sound = result; }
> public void setResult(FooObject result) {this.result = result; }
> ...
> }
>
> In other words, the String object that represents the "result" attribute in
> the class itself is named "sound", but the "set" method is named properly.
> However, there's an unrelated object of another type named "result" whose
> own set method overloads setResult().
>
> I believe that, strictly speaking, what I did was legal, but Jasper didn't
> like it at all, and apparently became convinced that the "result"
> attribute -- though explicitly specfied as a String object in the .tld
> file -- represented the key to a FooObject in a properties file somewhere
> and kept trying to call setResult(FooObject) instead of setResult(String)
> and threw an exception when the nonexistent property it was looking for
> wasn't found.
>
> Apparently the introspection mechanism decided that the presence of an
> instance variable named "result" (of any type) along with an overloaded
> setMethod() accommodating it took precedence over the fact that I explicitly
> told it (via .tld) that it was a String and there was a setMethod whose
> signature was a String.
>
> I'll admit that I haven't really spent lots of time exploring the nuts and
> bolts of introspection (up to now, it pretty much just worked as expected
> and I never paid much attention to it), but I'm inclined to think I found a
> bug, simply because one might reasonably expect introspection to take the
> obvious path ("Hmmm. The attribute is named 'result', and I was told it's a
> String. Yep, there's a method in the handler class named 'setResult' that
> takes a String, so I'll go ahead and use it") if there is one before trying
> to deconstruct the programmer's motives to find a more complicated execution
> path ("Hmmm. Yeah, I know it's a String and there's an obvious setMethod I
> can use, but that's too easy... Hey, wait a second, here's an instance
> variable named 'result' that also has a setResult method. It's the wrong
> type, but maybe if I massage this attribute String a bit, I can find a way
> to use THAT setResult instead...")
>
> Anybody's thoughts? Did I do something that's explicitly forbidden, or did I
> just have the misfortune of tripping over a bug?
>
>
>
> --
> 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]>
