I am seeing some very unexpected behavior using OGNL in the Struts
tags. I have two objects that contain equivalent Name objects and
when I run the following code:
!-- Original: s:property value='%{originalMember.name}'/
(s:property value='%{originalMember.name.class.name}'/) --
!-- Current:
Chris Pratt wrote:
!-- Equals(): s:property
value='%{originalMember.name.equals(currentMember.name)}'/ --
Just to be pedantic, can you also verify that:
!-- Equals(): s:property
value='%{currentMember.name.equals(originalMember.name)}'/ --
yields:
!-- Equals(): true --
?
All correctly
On Wed, Mar 5, 2008 at 9:56 PM, Dale Newfield [EMAIL PROTECTED] wrote:
Chris Pratt wrote:
!-- Equals(): s:property
value='%{originalMember.name.equals(currentMember.name)}'/ --
Just to be pedantic, can you also verify that:
!-- Equals(): s:property
--- Chris Pratt [EMAIL PROTECTED] wrote:
Notice that the last statement (using the OGNL == operator) doesn't
return anything at all, which makes it useless in a s:if test.
OGNL actually checks for isAssignableFrom; if either class isAssignableFrom
the other it checks for Comparable and calls
Chris Pratt wrote:
I added some instrumentation and it appears that OGNL is not calling
the equals method when I use the == operator, only when I explicitly
call .equals().
Look! A clue!
I believe the jar file is ognl-2.6.11.jar
Yep:
http://jira.opensymphony.com/browse/OGNL-96
Dave Newton wrote:
--- Chris Pratt [EMAIL PROTECTED] wrote:
Notice that the last statement (using the OGNL == operator) doesn't
return anything at all, which makes it useless in a s:if test.
OGNL actually checks for isAssignableFrom; if either class isAssignableFrom
the other it checks for
--- Dale Newfield [EMAIL PROTECTED] wrote:
There's a chance those bugs were introduced between 2.6.11 and 2.7, but
I'm betting not.
Nope; it's in 2.6.9 at least. The behavior happens because of the
isAssignableFrom sequence I mentioned in my previous post.
Dave
On Wed, Mar 5, 2008 at 10:20 PM, Dave Newton [EMAIL PROTECTED] wrote:
--- Chris Pratt [EMAIL PROTECTED] wrote:
Notice that the last statement (using the OGNL == operator) doesn't
return anything at all, which makes it useless in a s:if test.
OGNL actually checks for isAssignableFrom; if
--- Dale Newfield [EMAIL PROTECTED] wrote:
...some of my models implement Comparable, but not nearly all. Not sure
how that slipped through...
Probably most of the time people aren't comparing entire objects, but simple
properties like Strings or numbery-things, so it hasn't come up until
Chris Pratt wrote:
!-- Equals(): s:property
value='%{originalMember.name.equals(currentMember.name)}'/ --
!-- Equals(): s:property
value='%{CurrentMember.name.equals(originalMember.name)}'/ --
Was that case typo (CurrentMember instead of currentMember) introduced
in transcription? I would
On Wed, Mar 5, 2008 at 10:53 PM, Dale Newfield [EMAIL PROTECTED] wrote:
Chris Pratt wrote:
!-- Equals(): s:property
value='%{originalMember.name.equals(currentMember.name)}'/ --
!-- Equals(): s:property
value='%{CurrentMember.name.equals(originalMember.name)}'/ --
Was that case
--- Chris Pratt [EMAIL PROTECTED] wrote:
Since they're both the same Class (though not the same instance) they
definitely should be assignable, but Name implements Cloneable and
Serializable, not Comparable so it shouldn't be calling compareTo.
You know, I'm looking at the OGNL source again
12 matches
Mail list logo
