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: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
