Exception while unmarshalling Integer with an element biggerthan 32-bit

[Maxime Gregoire]

Hello,
 
Thanks a lot Brent for the fix proposal. I implemented it on my side,
XSIntegerCustom, using a Long instead of Integer and it works perfectly.
Until a solution is integrated into the official release, I will use
that custom version. After reading all your messages regarding this
issue, is there a plan for a fix on the 2.x branch or are you waiting
for 3.x release? Other than having to fix some unit tests, doing the fix
was really trouble free.
 
Anyway, thanks again!
 
Maxime
 
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net]
On Behalf Of Brent Putman
Sent: June-04-12 11:36 PM
To: users at shibboleth.net
Subject: Re: Exception while unmarshalling Integer with an element
biggerthan 32-bit
 


On 6/4/12 10:20 AM, Maxime Gregoire wrote: 
 
I started getting this since the provider sending me an encrypted
assertion added a new claim to the assertion that is based on the
http://www.w3.org/2001/XMLSchema#integer format. The value used for this
claim is 2535285330239773, which is a 64-bit value. Since
XSIntegerUnmarshaller tries to convert the received value into an
Integer using Integer.valueOf("2535285330239773"), I do get the
exception (2535285330239773 > 32-bit value).


Yes, that (unfortunately) makes sense.



 
I went to see what http://www.w3.org/2001/XMLSchema has to say about
#integer. Section 3.3.13 says that the value space of integer is the
infinite set. It specifically calls out that the value can be infinite,
so I'm guessing that sending a value bigger than 32-bit using #integer
is valid. Is there a reason why something received with #integer does
not fallback to a bigger format (Long) if the conversion fails because
of busting the size of a 32-bit value?
 


Well, given the way the API is currently, which exposes the value as a
java.lang.Integer, it can't really just fall back to using a Long or
something.  There wouldn't be any way to return (or set) the long
integer value since it's using Integer in the interface.

Also, if XMLSchema does define xsd:integer as having an infinite value
domain as you say, then using java.lang.Long wouldn't really be any more
correct, it would just put off the problem until even bigger numbers are
used (although if we're really lucky maybe that won't be until the heat
death of the universe).

I hate to even go there, but if the value space is infinite, seems like
in the future we might have to consider using another integer
representation capable of representing arbitrarily large integers.
java.math.BigInteger seems like overkill, but perhaps there is another
library with a simply class that might help us.  Or maybe just using
Long would be "good enough", even if not strictly speaking correct.




As it is almost impossible for me to change the
http://www.w3.org/2001/XMLSchema#integer type sent from the third-party
assertion provider, is there a way to fix this issue? Could it be a
problem on the OpenSAML/XMLTooling side?
 


Yes, I think this is a legitimate issue with OpenSAML.   I doubt we can
really fix this in v2.  Such a breaking API change would have to wait
until v3.

One workaround, though, might be for you to simply supply and register
an alternate XMLObject provider for xsd:integer that uses Long instead
of Integer.   This would actually be pretty simple, just copy and modify
the existing (and very simple) XSInteger* classes into your own package
namespace, and then just register them at runtime in the OpenSAML
Configuration singleton, replacing the ones we supply.  As long as you
control the calling code and can modify it to deal with the new object
exposing Long instead of Integer on its getter and setter, I *think*
that would work for you.

______________________________________________________________________
This email has been scanned by the MessageLabs
______________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20120615/a519c992/attachment-0001.html