--- 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 agai
On Wed, Mar 5, 2008 at 10:53 PM, Dale Newfield <[EMAIL PROTECTED]> wrote:
> Chris Pratt wrote:
> >
>
> >
>
> Was that case typo (CurrentMember instead of currentMember) introduced
> in transcription? I would assume it would not have produced "true" if
> it were in your code...
>
Yup, it was
Chris Pratt wrote:
Was that case typo (CurrentMember instead of currentMember) introduced
in transcription? I would assume it would not have produced "true" if
it were in your code...
-Dale
-
To unsubscribe, e-mail: [EM
--- 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
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 test.
>
> OGNL actually checks for isAssignableFro
--- 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
--
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 test.
OGNL actually checks for isAssignableFrom; if either class isAssignableFrom
the other it checks for Compa
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
http://jira
--- 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 test.
OGNL actually checks for isAssignableFrom; if either class isAssignableFrom
the other it checks for Comparable and calls com
On Wed, Mar 5, 2008 at 9:56 PM, Dale Newfield <[EMAIL PROTECTED]> wrote:
> Chris Pratt wrote:
> >
>
> Just to be pedantic, can you also verify that:
>
>
>
> yields:
>
>
>
> ?
> All correctly implemented equals methods are symmetric, so in the event
> OGNL decides that neither of these ar
Chris Pratt wrote:
Just to be pedantic, can you also verify that:
yields:
?
All correctly implemented equals methods are symmetric, so in the event
OGNL decides that neither of these are null and that it should call the
equals() method, it could theoretically do so in either order. I
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:
it outputs the following:
Notice that the last statement (using the OGNL == operator) doesn't
return anything at all, whic
12 matches
Mail list logo
