Exception while unmarshalling Integer with an element bigger than 32-bit

[Brent Putman]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20120604/b0897dfc/attachment-0001.html