[WW-5126] use == instead of .equals in ModelDrivenInterceptor

[yasserzamani]

due to refreshing model regardless of potential overridden Object.equals

[coveralls]

Coverage increased (+0.003%) to 47.316% when pulling 5096637 on ww_5126_2_5 into 8a26c0d on struts-2-5-x.

[aleksandr-m]

@yasserzamani Can you explain why comparing with == is better in this context?

[yasserzamani]

Thanks for the review @aleksandr-m !

TBH I don't have a strong reason. I've asked reporter but no answer yet.

"Moreover the interceptor refresh process is based on call to the equals method and this method may have been redefined, in a JPA context for instance. The replacement is then not systematic and may not be done." he said. No user ever has asked for .equals so I guess .equals has been selected unintentionally and the reporter has found a valid case that shows that it should be ==. That was my reasoning.

[lukaszlenart]

I'm good with that change, yet not sure if this supposed to be introduced into 2.5.x branch - some users can depend on this behaviour (even false one) and minor updates (as 2.5.27 will be) shouldn't introduce backward incompatibility.

[yasserzamani]

I personally feel it's pretty unlikely that this change breaks someone whose intentionally is depend on .equals! but at bottom you know better 👍 please let me know

[lukaszlenart]

The case is that this is unknown till someone will report a problem after upgrading to 2.5.27, I rather would like to be careful and make such potentially breaking changes in 2.6.x. The other thing is the reporter was addressing inconsistency in documentation and he was able to overcome the issue with custom interceptor - which is perfectly fine solution.

[yasserzamani]

I agree @lukaszlenart 👍 I closed it and opened its master counterpart at #486