Skip to Content.
Sympa Menu

mace-opensaml-users - Re: SAMLNameIdentifier.equals

Subject: OpenSAML user discussion

List archive

Re: SAMLNameIdentifier.equals


Chronological Thread 
  • From: Tom Scavo <>
  • To: Scott Cantor <>
  • Cc: Chad La Joie <>, OpenSAML <>
  • Subject: Re: SAMLNameIdentifier.equals
  • Date: Fri, 13 Jan 2006 12:03:33 -0500
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=KgPSmh4w+KQLm9LP4MP0KkQ9Gv4dvyj2MPeBwaLgFl+73FdZyfAShyH9qr2mfZiuZP6Ft75ZQ2GE0W/neTCURC+zVwN1pMR+2ZKAZLU+T40KweerRTLKREFTtStaNnnfwuN3FZCtjhWt4Dr6UYryDcpwKCQcUvfFaeNJiaUtjoE=

On 1/13/06, Scott Cantor
<>
wrote:
> > I understand why canonicalization must precede serialization (in
> > toStream) but I don't understand why toString is necessarily required
> > for comparison. You could compare the byte streams directly, right?
> > This is an implementation issue, but regardless, I think SAMLObject
> > needs an equals method.
>
> Sorry, I don't agree. Then I'd be deciding for all applications that the
> only definition of equality was canonical XML equivalence, which isn't true
> for your case, as you already noted.

A class is free (even encouraged) to override equals. Regardless of
whether or not there's an equals method in SAMLObject,
SAMLNameIdentifier would have to override it because of the Format
attribute. So in that sense it doesn't matter if you override
Object.equals in SAMLObject. On the other hand, by overriding equals
in SAMLObject, you provide a default method of comparison that most
likely works "as is" for most subclasses.

> What it should do is *block* the method. Maybe that's possible, but I don't
> know what other effects it has.

I'm not sure what you mean by "block". Every class has an equals
method, you can't escape that.

Tom



Archive powered by MHonArc 2.6.16.

Top of Page