The correct rule is to lookup the getter and use that to determine the setter. This is implemented correctly in some of the bean introspection classes, in some versions of the jdk. Since the bugs occur in different classes/methods in different versions of the jdk, it makes it hard to work around.
If the introspection was not so buggy, torque overloading of the setter would not be a problem. But having run into so many problems with this myself I would welcome a patch to conditionally remove the additional setter. It should not be difficult. properties defined in build.properties are available automatically within the templates, so it should not involve any java code. john mcnally On Mon, 2002-04-29 at 19:33, James A. Hillyerd wrote: > I am having a problem with Torque generated objects not fitting the > "Bean Pattern". > > My Object's primary key is a NumberKey called UserID. Torque generates > get/set methods for this NumberKey, but it also generates a set method > which accepts a String parameter. > > I don't know the complete rules for JavaBean accessor methods, but my > IDE (NetBeans) shows "UserID" as a write-only String value. The taglib > I am using to render this bean to the user, tells me it cannot access > the value for UserID because no method exists to retrieve it. > > Is there any reason for the set String method? It would be nice if it > was either removed, or could be disabled via Torque's build.properties. > > -james > > -- > [] James A. Hillyerd <[EMAIL PROTECTED]> - Java Software Engineer > [] PGP 1024D/D31BC40D F87B 7906 C0DA 32E8 B8F6 DE23 FBF6 4712 D31B C40D > > > -- > 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]>
