HARMONY-1884 was created.
Thanks,
2006/10/16, Alexei Zakharov <[EMAIL PROTECTED]>:
I am ok with this. :) Will file a JIRA soon.
Regards,
2006/10/16, Tim Ellison <[EMAIL PROTECTED]>:
> I'm fine with marking it as a non-bug difference, with the option to fix
> it if we find some compelling appl
I am ok with this. :) Will file a JIRA soon.
Regards,
2006/10/16, Tim Ellison <[EMAIL PROTECTED]>:
I'm fine with marking it as a non-bug difference, with the option to fix
it if we find some compelling application that relies on this non-spec
behavior. Is that weasely enough?
Regards,
Tim
Al
I'm fine with marking it as a non-bug difference, with the option to fix
it if we find some compelling application that relies on this non-spec
behavior. Is that weasely enough?
Regards,
Tim
Alexei Zakharov wrote:
> Hi Tim,
>
> <-- persuasion starts here
>
> Let me cite the spec describing des
Hi Tim,
<-- persuasion starts here
Let me cite the spec describing design patterns for properties,
JavaBeans spec v1.01-A (Aug 8, 1997), page 55:
---
8.3 Design Patterns for Properties
8.3.1 Simple properties
By default, we use design patterns to locate properties by looking for
methods of the
That is strange behavior, since as you point out it does not set a
parametrized value, however, I wonder if there is some assumption that
the setFoo() method may be a mutator anyway, e.g. setDefaults() or
something like that? Just guessing.
In this case it may be safer to follow the RI -- but I'm
Hi all,
Let me disturb you with another boring "RI inconsistency in beans"
–type of message. :) It seems I found a bug in RI. In
java.beans.EventHandler. I think RI incorrectly determines properties
here. According to spec, common sense and even the RI's implementation
of java.beans.Introspector
