commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Carman <ja...@carmanconsulting.com>
Subject Re: [lang] Advise needed for broken reflectionEquals in WebLogic 10.3.5
Date Thu, 28 Jul 2011 10:37:05 GMT
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 <cancrinus_b@schiphol.nl> 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: 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
>
>

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


Mime
View raw message