[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