Jasper Bug, or just a rule I wasn't aware of?

[Jeff <li...@skubick.com>]

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 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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Jasper Bug, or just a rule I wasn't aware of?

["Craig R. McClanahan" <cr...@apache.org>]

On Fri, 20 Sep 2002, Jeff wrote:

> Date: Fri, 20 Sep 2002 13:01:50 -0400
> From: Jeff <li...@skubick.com>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: tomcat-user@jakarta.apache.org
> 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:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>