|
»
»
Unmarshalling hexBinary elements seems to return bad data
|
View:
New views
10 Messages
—
Rating Filter:
Alert me
|
 |
Unmarshalling hexBinary elements seems to return bad data
by Heggart, Alex
::
Rate this Message:
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 |
|
|
Re: Unmarshalling hexBinary elements seems to return bad data
by Werner Guttmann-6
::
Rate this Message:
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 |
|
|
RE: Unmarshalling hexBinary elements seems to return bad data
by Heggart, Alex
::
Rate this Message:
Hi Werner,
I've also tested this against Castor 1.2 and the current trunk as of October 1st and the problem still occurs. I've also tried this with JAXB 2.1 provided with J2SE 6u7 and that works as expected, so I'm fairly sure the problem is with Castor. I've created a JIRA issue at http://jira.codehaus.org/browse/CASTOR-2841. I've also attached a small test case as a patch against the trunk to that issue. As a side note, I'm unable to find the issue related to hexBinary fixed recently in JIRA. Cheers, Alex -----Original Message----- From: Werner Guttmann [mailto:wguttmn@...] Sent: Monday, 5 October 2009 3:11 PM To: user@... Subject: Re: [castor-user] Unmarshalling hexBinary elements seems to return bad data 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 > > > > -------------- > 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 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 |
|
|
Re: Unmarshalling hexBinary elements seems to return bad data
by Werner Guttmann-6
::
Rate this Message:
Hi Alex,
I will have a look at this; I do remember, though, that there's an issue in our Jira that is related to the use of Java 6 and arrays. Cheers Werner Heggart, Alex wrote: > Hi Werner, > > I've also tested this against Castor 1.2 and the current trunk as of > October 1st and the problem still occurs. I've also tried this with JAXB > 2.1 provided with J2SE 6u7 and that works as expected, so I'm fairly > sure the problem is with Castor. > > I've created a JIRA issue at > http://jira.codehaus.org/browse/CASTOR-2841. > > I've also attached a small test case as a patch against the trunk to > that issue. > > As a side note, I'm unable to find the issue related to hexBinary fixed > recently in JIRA. > > Cheers, > > Alex > > -----Original Message----- > From: Werner Guttmann [mailto:wguttmn@...] > Sent: Monday, 5 October 2009 3:11 PM > To: user@... > Subject: Re: [castor-user] Unmarshalling hexBinary elements seems to > return bad data > > 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 > > > > > > 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 |
|
|
RE: Unmarshalling hexBinary elements seems to return bad data
by Heggart, Alex
::
Rate this Message:
Hi Werner,
Thanks for looking into this. Just note that I've also tested this with Java 5u19. Cheers, Alex Heggart -----Original Message----- From: Werner Guttmann [mailto:wguttmn@...] Sent: Friday, 9 October 2009 4:11 AM To: user@... Subject: Re: [castor-user] Unmarshalling hexBinary elements seems to return bad data Hi Alex, I will have a look at this; I do remember, though, that there's an issue in our Jira that is related to the use of Java 6 and arrays. Cheers Werner Heggart, Alex wrote: > Hi Werner, > > I've also tested this against Castor 1.2 and the current trunk as of > October 1st and the problem still occurs. I've also tried this with JAXB > 2.1 provided with J2SE 6u7 and that works as expected, so I'm fairly > sure the problem is with Castor. > > I've created a JIRA issue at > http://jira.codehaus.org/browse/CASTOR-2841. > > I've also attached a small test case as a patch against the trunk to > that issue. > > As a side note, I'm unable to find the issue related to hexBinary > recently in JIRA. > > Cheers, > > Alex > > -----Original Message----- > From: Werner Guttmann [mailto:wguttmn@...] > Sent: Monday, 5 October 2009 3:11 PM > To: user@... > Subject: Re: [castor-user] Unmarshalling hexBinary elements seems to > return bad data > > Hi Alex, > > there's two options to go about this. > > a) Try it against SVN trunk to see whether - since the 1.3 release - > 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 >> 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 >> >> >> >> > > -------------- >> 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 > 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 > > > > > > -------------- > 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 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 |
|
|
Re: Unmarshalling hexBinary elements seems to return bad data
by Werner Guttmann
::
Rate this Message:
And it still fails with Java 5.0 ?
Werner Heggart, Alex wrote: > Hi Werner, > > Thanks for looking into this. Just note that I've also tested this with > Java 5u19. > > Cheers, > > Alex Heggart > > -----Original Message----- > From: Werner Guttmann [mailto:wguttmn@...] > Sent: Friday, 9 October 2009 4:11 AM > To: user@... > Subject: Re: [castor-user] Unmarshalling hexBinary elements seems to > return bad data > > Hi Alex, > > I will have a look at this; I do remember, though, that there's an issue > in our Jira that is related to the use of Java 6 and arrays. > > Cheers > > Werner > > Heggart, Alex wrote: >> Hi Werner, >> >> I've also tested this against Castor 1.2 and the current trunk as of >> October 1st and the problem still occurs. I've also tried this with > JAXB >> 2.1 provided with J2SE 6u7 and that works as expected, so I'm fairly >> sure the problem is with Castor. >> >> I've created a JIRA issue at >> http://jira.codehaus.org/browse/CASTOR-2841. >> >> I've also attached a small test case as a patch against the trunk to >> that issue. >> >> As a side note, I'm unable to find the issue related to hexBinary > fixed >> recently in JIRA. >> >> Cheers, >> >> Alex >> >> -----Original Message----- >> From: Werner Guttmann [mailto:wguttmn@...] >> Sent: Monday, 5 October 2009 3:11 PM >> To: user@... >> Subject: Re: [castor-user] Unmarshalling hexBinary elements seems to >> return bad data >> >> 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 >> >> >> >> >> >> > 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 > > > > > > 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 |
|
|
Re: Unmarshalling hexBinary elements seems to return bad data
by Werner Guttmann-6
::
Rate this Message:
Btw, just to let you know that
http://jira.codehaus.org/browse/CASTOR cannot be accessed currently .. :-(. Cheers Werner Werner Guttmann wrote: > And it still fails with Java 5.0 ? > > Werner > > Heggart, Alex wrote: >> Hi Werner, >> >> Thanks for looking into this. Just note that I've also tested this with >> Java 5u19. >> >> Cheers, >> >> Alex Heggart >> >> -----Original Message----- >> From: Werner Guttmann [mailto:wguttmn@...] >> Sent: Friday, 9 October 2009 4:11 AM >> To: user@... >> Subject: Re: [castor-user] Unmarshalling hexBinary elements seems to >> return bad data >> >> Hi Alex, >> >> I will have a look at this; I do remember, though, that there's an issue >> in our Jira that is related to the use of Java 6 and arrays. >> >> Cheers >> >> Werner >> >> Heggart, Alex wrote: >>> Hi Werner, >>> >>> I've also tested this against Castor 1.2 and the current trunk as of >>> October 1st and the problem still occurs. I've also tried this with >> JAXB >>> 2.1 provided with J2SE 6u7 and that works as expected, so I'm fairly >>> sure the problem is with Castor. >>> >>> I've created a JIRA issue at >>> http://jira.codehaus.org/browse/CASTOR-2841. >>> >>> I've also attached a small test case as a patch against the trunk to >>> that issue. >>> >>> As a side note, I'm unable to find the issue related to hexBinary >> fixed >>> recently in JIRA. >>> >>> Cheers, >>> >>> Alex >>> >>> -----Original Message----- >>> From: Werner Guttmann [mailto:wguttmn@...] >>> Sent: Monday, 5 October 2009 3:11 PM >>> To: user@... >>> Subject: Re: [castor-user] Unmarshalling hexBinary elements seems to >>> return bad data >>> >>> 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 >>> >>> >>> >>> >>> >>> >> 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 >> >> >> >> >> >> 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 > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
RE: Unmarshalling hexBinary elements seems to return bad data
by Heggart, Alex
::
Rate this Message:
Yes it still fails under Java 5.0.
Alex Heggart -----Original Message----- From: Werner Guttmann [mailto:werner.guttmann@...] Sent: Friday, 9 October 2009 5:48 PM To: user@... Subject: Re: [castor-user] Unmarshalling hexBinary elements seems to return bad data And it still fails with Java 5.0 ? Werner Heggart, Alex wrote: > Hi Werner, > > Thanks for looking into this. Just note that I've also tested this with > Java 5u19. > > Cheers, > > Alex Heggart > > -----Original Message----- > From: Werner Guttmann [mailto:wguttmn@...] > Sent: Friday, 9 October 2009 4:11 AM > To: user@... > Subject: Re: [castor-user] Unmarshalling hexBinary elements seems to > return bad data > > Hi Alex, > > I will have a look at this; I do remember, though, that there's an > in our Jira that is related to the use of Java 6 and arrays. > > Cheers > > Werner > > Heggart, Alex wrote: >> Hi Werner, >> >> I've also tested this against Castor 1.2 and the current trunk as of >> October 1st and the problem still occurs. I've also tried this with > JAXB >> 2.1 provided with J2SE 6u7 and that works as expected, so I'm fairly >> sure the problem is with Castor. >> >> I've created a JIRA issue at >> http://jira.codehaus.org/browse/CASTOR-2841. >> >> I've also attached a small test case as a patch against the trunk to >> that issue. >> >> As a side note, I'm unable to find the issue related to hexBinary > fixed >> recently in JIRA. >> >> Cheers, >> >> Alex >> >> -----Original Message----- >> From: Werner Guttmann [mailto:wguttmn@...] >> Sent: Monday, 5 October 2009 3:11 PM >> To: user@... >> Subject: Re: [castor-user] Unmarshalling hexBinary elements seems to >> return bad data >> >> 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 >>> 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 >>> 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 >>> >>> >>> >>> > >> -------------- >>> This e-mail transmission and any documents, files and previous >> 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 >> >> >> >> >> >> > > -------------- >> 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 > 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 > > > > > > -------------- > 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 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 |
|
|
RE: Unmarshalling hexBinary elements seems to return bad data
by Heggart, Alex
::
Rate this Message:
Hi Werner,
I've found the problem and attached a patch to the CASTOR-2841 issue. I discovered that the unmarshalled binary data was Base64 decoded instead of HexBinary decoded which was why I was getting garbage data. I traced back to the UnmarshallHandler and found a missing logic check which caused Base64 decoding to be used when a hexBinary schema type was specified. I've rectified this and my test case now works. The patch is castor-2841-fix.patch and includes the test case I used to test. Could you please integrate this to the trunk. As a side note, you mentioned a problem with Java 6 arrays. I did a search and came across http://jira.codehaus.org/browse/CASTOR-1980. If this is the issue you speak of the problem isn't with Java 6 rather that Java 5 was being misused. If you read the bug report it says that to fix this problem you need to replace instances of classLoader.loadClass(className) with Class.forName(className, false, classLoader). This should be a simple fix in the UnmarshalHandler.java file. Cheers, Alex -----Original Message----- From: Heggart, Alex Sent: Monday, 12 October 2009 10:46 AM To: user@... Subject: RE: [castor-user] Unmarshalling hexBinary elements seems to return bad data Yes it still fails under Java 5.0. Alex Heggart -----Original Message----- From: Werner Guttmann [mailto:werner.guttmann@...] Sent: Friday, 9 October 2009 5:48 PM To: user@... Subject: Re: [castor-user] Unmarshalling hexBinary elements seems to return bad data And it still fails with Java 5.0 ? Werner Heggart, Alex wrote: > Hi Werner, > > Thanks for looking into this. Just note that I've also tested this with > Java 5u19. > > Cheers, > > Alex Heggart > > -----Original Message----- > From: Werner Guttmann [mailto:wguttmn@...] > Sent: Friday, 9 October 2009 4:11 AM > To: user@... > Subject: Re: [castor-user] Unmarshalling hexBinary elements seems to > return bad data > > Hi Alex, > > I will have a look at this; I do remember, though, that there's an > in our Jira that is related to the use of Java 6 and arrays. > > Cheers > > Werner > > Heggart, Alex wrote: >> Hi Werner, >> >> I've also tested this against Castor 1.2 and the current trunk as of >> October 1st and the problem still occurs. I've also tried this with > JAXB >> 2.1 provided with J2SE 6u7 and that works as expected, so I'm fairly >> sure the problem is with Castor. >> >> I've created a JIRA issue at >> http://jira.codehaus.org/browse/CASTOR-2841. >> >> I've also attached a small test case as a patch against the trunk to >> that issue. >> >> As a side note, I'm unable to find the issue related to hexBinary > fixed >> recently in JIRA. >> >> Cheers, >> >> Alex >> >> -----Original Message----- >> From: Werner Guttmann [mailto:wguttmn@...] >> Sent: Monday, 5 October 2009 3:11 PM >> To: user@... >> Subject: Re: [castor-user] Unmarshalling hexBinary elements seems to >> return bad data >> >> 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 >>> 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 >>> 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 >>> >>> >>> >>> > >> -------------- >>> This e-mail transmission and any documents, files and previous >> 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 >> >> >> >> >> >> > > -------------- >> 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 > 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 > > > > > > -------------- > 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 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 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. -------------------------------------------------------------------------------------- |
|
|
Re: Unmarshalling hexBinary elements seems to return bad data
by Werner Guttmann-6
::
Rate this Message:
Hi Alex,
Heggart, Alex wrote: > Hi Werner, > > I've found the problem and attached a patch to the CASTOR-2841 issue. > I discovered that the unmarshalled binary data was Base64 decoded > instead of HexBinary decoded which was why I was getting garbage > data. I traced back to the UnmarshallHandler and found a missing > logic check which caused Base64 decoding to be used when a hexBinary > schema type was specified. I've rectified this and my test case now > works. The patch is castor-2841-fix.patch and includes the test case > I used to test. Could you please integrate this to the trunk. suite. > As a side note, you mentioned a problem with Java 6 arrays. I did a > search and came across http://jira.codehaus.org/browse/CASTOR-1980. > If this is the issue you speak of the problem isn't with Java 6 > rather that Java 5 was being misused. If you read the bug report it > says that to fix this problem you need to replace instances of > classLoader.loadClass(className) with Class.forName(className, false, > classLoader). This should be a simple fix in the > UnmarshalHandler.java file. Yes, an no. I know there's this issue/problem as well, but I had a different issue in mind. > Cheers, Cheers > Alex Werner > > -----Original Message----- From: Heggart, Alex Sent: Monday, 12 > October 2009 10:46 AM To: user@... Subject: RE: > [castor-user] Unmarshalling hexBinary elements seems to return bad > data > > Yes it still fails under Java 5.0. > > Alex Heggart > > -----Original Message----- From: Werner Guttmann > [mailto:werner.guttmann@...] Sent: Friday, 9 October 2009 5:48 PM > To: user@... Subject: Re: [castor-user] > Unmarshalling hexBinary elements seems to return bad data > > And it still fails with Java 5.0 ? > > Werner > > Heggart, Alex wrote: >> Hi Werner, >> >> Thanks for looking into this. Just note that I've also tested this > with >> Java 5u19. >> >> Cheers, >> >> Alex Heggart >> >> -----Original Message----- From: Werner Guttmann >> [mailto:wguttmn@...] Sent: Friday, 9 October 2009 4:11 AM >> To: user@... Subject: Re: [castor-user] >> Unmarshalling hexBinary elements seems to return bad data >> >> Hi Alex, >> >> I will have a look at this; I do remember, though, that there's an > issue >> in our Jira that is related to the use of Java 6 and arrays. >> >> Cheers >> >> Werner >> >> Heggart, Alex wrote: >>> Hi Werner, >>> >>> I've also tested this against Castor 1.2 and the current trunk as >>> of October 1st and the problem still occurs. I've also tried this >>> with >> JAXB >>> 2.1 provided with J2SE 6u7 and that works as expected, so I'm >>> fairly sure the problem is with Castor. >>> >>> I've created a JIRA issue at >>> http://jira.codehaus.org/browse/CASTOR-2841. >>> >>> I've also attached a small test case as a patch against the trunk >>> to that issue. >>> >>> As a side note, I'm unable to find the issue related to hexBinary >>> >> fixed >>> recently in JIRA. >>> >>> Cheers, >>> >>> Alex >>> >>> -----Original Message----- From: Werner Guttmann >>> [mailto:wguttmn@...] Sent: Monday, 5 October 2009 3:11 >>> PM To: user@... Subject: Re: [castor-user] >>> Unmarshalling hexBinary elements seems to return bad data >>> >>> 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 >>> 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 >>> >>> >>> >>> >>> >>> > DISCLAIMER:------------------------------------------------------------- > >> -------------- >>> This e-mail transmission and any documents, files and previous >> 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 >> >> >> >> >> >> > DISCLAIMER:------------------------------------------------------------- > -------------- >> This e-mail transmission and any documents, files and previous > 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 > > > > > > 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 > > > > > > 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 |
| Free embeddable forum powered by Nabble | Forum Help |
