Just to make it clear, here is what I have observed: 1. Private setters worked for any class in which they were declared but not for any child classes that extended the parent.
2. Protected setters worked for the class they were declared in as well as for child classes in the same package as the parent class. They did not work for child classes in a different (from parent class) package. 3. Public setters work everywhere as expected. Denis -----Original Message----- From: Clinton Begin [mailto:[EMAIL PROTECTED] Sent: Monday, May 12, 2008 1:24 PM To: [email protected] Subject: Re: Problem exposing protected setters for iBatis Waitaminute... maybe I didn't read the earlier threads as well as I should have... Are you saying protected members don't work, but PRIVATE members do!? If so, that is completely screwy! :-) I'll write some tests tonight to see if I can figure out what's going on. Clinton On Mon, May 12, 2008 at 10:39 AM, Kezerashvili, Denis <[EMAIL PROTECTED]> wrote: > > > Private field should do just fine for my purposes, no special handling in > the setter. > Thank you for the quick response to this issue. > > Denis > > > > ________________________________ > From: Brandon Goodin [mailto:[EMAIL PROTECTED] > Sent: Monday, May 12, 2008 12:31 PM > > > To: [email protected] > Subject: Re: Problem exposing protected setters for iBatis > > > > It looks like we have a fix on the way. Is there special logic that is used > in your private setter? If not, I would opt to just ditch the private setter > and set directly to the instance variable once the fix is in to iBATIS. Once > the fix is in iBATIS will set to the private variable if it does not find a > setter. > > Brandon > > > On Mon, May 12, 2008 at 11:25 AM, Kezerashvili, Denis > <[EMAIL PROTECTED]> wrote: > > > > > > > The property is actually private, the setter is protected. > > It is protected so that it's available in the classes extending the parent > class. > > For example, Entity has setId() method defined. User class extends Entity > and therefore has setId() available. > > Honestly, I would prefer the setter to be private in Entity, but that was > causing a problem when iBATIS was persisting classes in the same package for > the classes extending Entity. For child classes of Entity outside of its > package no access modifier other than public worked. > > I guess if the fix can make use of private setters in the parent class it > would be a perfect solution, which actually does not seem unreasonable to > me. > > > > > > ________________________________ > From: Nathan Maves [mailto:[EMAIL PROTECTED] > > Sent: Monday, May 12, 2008 12:08 PM > > > > > > > > To: [email protected] > > Subject: Re: Problem exposing protected setters for iBatis > > > > > > > > > > > > Can I ask what the point of labeling the property as protected is in your > case? > > > > > > > > > > On Mon, May 12, 2008 at 8:54 AM, Clinton Begin <[EMAIL PROTECTED]> > wrote: > > > > > I think I've confirmed this bug visually. It looks like a change went > > > in quite some time ago that stopped this from working. I'll write a > > > few unit tests and see if we can get a fix into the next minor beta. > > > We have to re-release anyway, due to a JDK 1.4 incompatibility in the > > > most recent beta. > > > > > > Clinton > > > > > > > > > > > > > > > On Mon, May 12, 2008 at 7:53 AM, Kezerashvili, Denis > > > <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > Thank you Koka for the link. > > > > > > > > I am actually well aware of the fact that iBATIS uses reflection to > call > > > > setters. And yes it works fine with private setters. It also works > fine with > > > > protected setters for the child classes in the same package. So if you > have > > > > User class extending Entity class that has a protected void setId(); > it will > > > > work for User class in iBATIS. > > > > The problem arises when your User class is NOT in the same package as > your > > > > Entity class. Apparently the reflection calls are made on User class > and for > > > > some reason it has no access to the setId() method inherited from the > Entity > > > > class. If the reflection call was made on Entity instead it would've > worked, > > > > but I do not think iBATIS is doing that. Or maybe it can do that, but > it has > > > > to be configured somehow to make reflection calls on the parent class. > > > > > > > > Does anybody know how to do that, or if it's even possible? > > > > > > > > Any input would be greatly appreciated > > > > > > > > > > > > ________________________________ > > > > From: Nicholoz Koka Kiknadze [mailto:[EMAIL PROTECTED] > > > > Sent: Friday, May 09, 2008 6:05 PM > > > > To: [email protected] > > > > Subject: Re: Problem exposing protected setters for iBatis > > > > > > > > > > > > Well, here's thread discussing same problem, and it seems private > setId() > > > > should work > > > > > > > > http://www.mail-archive.com/[email protected]/msg08629.html > > > > > > > > > > > > >
