[xsd-users] Custom DOMLSParser

Carlos Wong carloswong54 at gmail.com
Tue Jul 5 11:02:38 EDT 2022


Hi all,

I am running into a new issue where the embedded schema generated from xsdbin on a x86_64, does not work on a ARM processor. It produces the following error:

“unable to load schema: InputStream read ‘0’ is less than required ‘8192’”

If I generate the embedded schema from an ARM cross-compiled xsdbin, everything works fine on my ARM platform, but ceases to work on my x86 platform.

Is anyone aware of a way to make the embedded schema work on both ARM and x86_64?

Thank you,

Carlos

> On Jun 8, 2022, at 11:02 AM, Carlos Wong <carloswong54 at gmail.com> wrote:
> 
> 
> Hi Boris,
> 
> Thank you for the prompt response.
> 
> It turns out my issue was resolved by calling the DOMLSParserImpl constructor from the initialization list.
> 
> I was calling it directly from the constructor body.
> 
> I will give your suggestion to directly create a custom_dom_LS_parser_impl a shot.
> 
> Thanks again,
> 
> Carlos
> 
>> On Wed, Jun 8, 2022 at 10:51 AM Boris Kolpackov <boris at codesynthesis.com> wrote:
>> Carlos Wong <carloswong54 at gmail.com> writes:
>> 
>> > But I can only either make the embedded binary representation work or my
>> > customer error handler. I have run out of ideas, please any feedback and/or
>> > suggestions would be greatly appreciated.
>> 
>> I tried to follow your code and AFAICS, here is what happens: you call
>> DOMImplementationRegistry::getDOMImplementation() which returns some
>> Xerces-provided instance of DOMImplementation. Then you cast it (with
>> a C-style cast) to your custom_dom_implementation_impl type, even though
>> it's not. Then you call createLSParser(), which (probably) ends up
>> calling Xerces' original implementation and you get Xerces' original
>> DOMLSParserImpl. Or you call createCustomLSParser(), which is wrong,
>> but by the looks of it, it should return you an instance of your
>> custom_dom_LS_parser_impl (because it's not a virtual function and
>> you don't reference any data member).
>> 
>> Why don't you get rid of all this DOMImplementation stuff and create
>> an instance of your custom_dom_LS_parser_impl directly:
>> 
>> xml::dom::auto_ptr<custom_dom_LS_parser_impl> parser(
>>   new (manager) custom_dom_LS_parser_impl(0, manager, gramPool));
> 
>> On Wed, Jun 8, 2022 at 10:51 AM Boris Kolpackov <boris at codesynthesis.com> wrote:
>> Carlos Wong <carloswong54 at gmail.com> writes:
>> 
>> > But I can only either make the embedded binary representation work or my
>> > customer error handler. I have run out of ideas, please any feedback and/or
>> > suggestions would be greatly appreciated.
>> 
>> I tried to follow your code and AFAICS, here is what happens: you call
>> DOMImplementationRegistry::getDOMImplementation() which returns some
>> Xerces-provided instance of DOMImplementation. Then you cast it (with
>> a C-style cast) to your custom_dom_implementation_impl type, even though
>> it's not. Then you call createLSParser(), which (probably) ends up
>> calling Xerces' original implementation and you get Xerces' original
>> DOMLSParserImpl. Or you call createCustomLSParser(), which is wrong,
>> but by the looks of it, it should return you an instance of your
>> custom_dom_LS_parser_impl (because it's not a virtual function and
>> you don't reference any data member).
>> 
>> Why don't you get rid of all this DOMImplementation stuff and create
>> an instance of your custom_dom_LS_parser_impl directly:
>> 
>> xml::dom::auto_ptr<custom_dom_LS_parser_impl> parser(
>>   new (manager) custom_dom_LS_parser_impl(0, manager, gramPool));


More information about the xsd-users mailing list