commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cancrinus, Bas" <cancrinu...@schiphol.nl>
Subject RE: [lang] Advise needed for broken reflectionEquals in WebLogic 10.3.5
Date Thu, 28 Jul 2011 08:45:19 GMT
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: paulus.benedictus@gmail.com [mailto:paulus.benedictus@gmail.com] 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 <GGregory@seagullsoftware.com> 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: paulus.benedictus@gmail.com [mailto:paulus.benedictus@gmail.com]
> 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 <cancrinus_b@schiphol.nl> 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: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org


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: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org


Mime
View raw message