If you're going to be enumerating the fields anyway, why not use an EqualsBuilder?
On Thu, Jul 28, 2011 at 4:45 AM, Cancrinus, Bas <[email protected]> wrote: > Thanks for sharing your thoughts! > > I reflected on this issue again and I think that the excludeFields array is > the root of my problem. Now you can only tell reflectionEquals which fields > to exclude, but you never know which non-transient, non-static, non-$ fields > are included at runtime. That makes the result of reflectionEquals > unpredictable. The only way to guarantee a consistent result would be to use > an includeFields array instead. > > I have to release tomorrow, so for now I decided to replace all occurrences > of reflectionEquals with the good old copy-paste logic. > I like the simplicity and elegance of reflectionEquals, so I hope that we can > work this out. > > Cheers, Bas > > -----Oorspronkelijk bericht----- > Van: [email protected] [mailto:[email protected]] Namens > Paul Benedict > Verzonden: woensdag 27 juli 2011 20:52 > Aan: Commons Users List > Onderwerp: Re: [lang] Advise needed for broken reflectionEquals in WebLogic > 10.3.5 > > +1 to that idea. > > On Wed, Jul 27, 2011 at 12:25 PM, Gary Gregory <[email protected]> > wrote: >> We might as well use an RE instead of a prefix. Next week someone will want >> to do something will fields that /end/ in "_" or whatnot. >> >> Gary >> >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] >> On Behalf Of Paul Benedict >> Sent: Wednesday, July 27, 2011 13:15 PM >> To: Commons Users List >> Subject: Re: [lang] Advise needed for broken reflectionEquals in >> WebLogic 10.3.5 >> >> ReflectionEquals uses actual fields, not methods, to build the string >> output. The underscore is actually a known convention by some Java >> programmers (I don't subscribe to it but projects like Apache Tapestry use >> underscore for ALL their fields). So I don't think underscore is suitable to >> be excluded. However, perhaps as an enhancement the builder could be >> configured with a list of prefixes to ignore. If that's what you want, >> please open up a JIRA issue for consideration. >> >> On Wed, Jul 27, 2011 at 11:49 AM, Cancrinus, Bas <[email protected]> >> wrote: >>> I'm currently migrating an EAR from WebLogic 10.3.3 to 10.3.5. While >>> testing I noticed that the following invocation returned false while I >>> expected true (lang 2.5): >>> >>> EqualsBuilder.reflectionEquals(Object lhs, Object rhs, String[] >>> excludeFields) >>> >>> I noticed in my debugger that my domain classes were extended by the >>> WebLogic JPA provider with the following field: >>> >>> protected org.eclipse.persistence.queries.FetchGroup >>> _persistence_fetchGroup >>> >>> EqualsBuilder.reflectionAppend() (lang 2.5-3.0) only ignores: >>> >>> - "$" in field names >>> >>> - static modifiers >>> >>> - transients (conditional) >>> >>> - and of course the excludeFields array >>> >>> The JPA extension field mentioned above doesn't fall into any of those >>> categories, so it is appended to the equals result. >>> >>> The easy way out for me would be to add this field to all reflectionEquals >>> excludeFields arrays, but I'm looking for a more sustainable way to do this. >>> >>> - What do you think about patching >>> EqualsBuilder.reflectionAppend() so that it ignores this field ( >>> f.startsWith("_") )? >>> >>> - Are there any other better ways to fix this issue? >>> >>> I appreciate any help very much! >>> >>> Have a nice day, >>> Bas >>> >>> >>> P: Please consider the environment before printing this e-mail >>> >>> ________________________________ >>> >>> This e-mail may contain confidential and privileged material. You are >>> requested not to disclose, copy or distribute any information thereof. If >>> you are not the intended recipient (or have received this e-mail in error) >>> please notify the sender immediately and delete this e-mail. We accept no >>> liability for damage related to data and/or documents which are >>> communicated by electronic mail. >>> >>> ________________________________ >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > P: Please consider the environment before printing this e-mail > > ________________________________ > > This e-mail may contain confidential and privileged material. You are > requested not to disclose, copy or distribute any information thereof. If you > are not the intended recipient (or have received this e-mail in error) please > notify the sender immediately and delete this e-mail. We accept no liability > for damage related to data and/or documents which are communicated by > electronic mail. > > ________________________________ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
