Hi Alex, there's two options to go about this.
a) Try it against SVN trunk to see whether - since the 1.3 release - an issue has been found and fixed related to hexBinaries. As the same time, you might want to browse our Jira, too. b) Provide us with a small (sic!) test case that shows the problem at hand. Regards Werner Heggart, Alex wrote: > Hi all, > > I've been helping out a colleague who is using Castor 1.3 to read xml > files provided by a business partner. The xml schema defines an element > of type xs:hexBinary for MD5 hashes they are providing to us. We can see > the hashes in the xml file as a 32 character hex string (eg > 9E107D9D372BB6826BD81D3542A419D6). When we unmarshal these using Castor > we seem to be getting bogus values. When we try to display the > unmarshalled bytes as a hex string for our consumption we it is nothing > like the value in the xml document. As well, we are getting 24 bytes > produced by Castor when I would assume we should be getting 16 for the > 128 bit hash. > > I've never used the xs:hexBinary type before so I may be > misunderstanding its intention and use. We could switch to using fixed > length strings in the schema however it is provided by a business > partner and of course these things take time. Also, I'm guessing they > used hexBinary in the first place for the 'free' validation it provides. > > If it helps I'm doing this in Windows XP, using JDK 1.5u19 and 1.6u7. > > Cheers, > > Alex Heggart > Software Engineer > Security Solutions & Services > Aerospace > Thales Australia > > > > DISCLAIMER:--------------------------------------------------------------------------- > This e-mail transmission and any documents, files and previous e-mail messages > attached to it are private and confidential. They may contain proprietary or > copyright > material or information that is subject to legal professional privilege. They > are for > the use of the intended recipient only. Any unauthorised viewing, use, > disclosure, > copying, alteration, storage or distribution of, or reliance on, this message > is > strictly prohibited. No part may be reproduced, adapted or transmitted > without the > written permission of the owner. If you have received this transmission in > error, or > are not an authorised recipient, please immediately notify the sender by > return email, > delete this message and all copies from your e-mail system, and destroy any > printed > copies. Receipt by anyone other than the intended recipient should not be > deemed a > waiver of any privilege or protection. Thales Australia does not warrant or > represent > that this e-mail or any documents, files and previous e-mail messages > attached are > error or virus free. > -------------------------------------------------------------------------------------- > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
