[xsd-users] Custom DOMLSParser
Carlos Wong
carloswong54 at gmail.com
Thu Jul 7 08:50:20 EDT 2022
Hi all,
I have found the following issue, describing that `serializeGrammars` does
not work between 32 and 64 bit systems.
https://issues.apache.org/jira/browse/XERCESC-1959
Therefore, we will move forward without the embedded schema solution.
Thank you,
Carlos
On Tue, Jul 5, 2022 at 6:25 PM Carlos Wong <carloswong54 at gmail.com> wrote:
> Just an update.
>
> I was able to make the generated embedded schema work for both x86_64 and
> ARM platforms.
>
> This was accomplished by passing the “-m32” option to gcc for xerces and
> the driver executable.
>
> Effectively making the driver executable a 32-bit binary, which is not
> ideal for our use case.
>
> Is there a way to make the embedded schema work for both x86_64 and ARM
> platforms, such that the executable remains a 64-bit binary?
>
> Best regards,
>
> Carlos
>
> On Jul 5, 2022, at 11:02 AM, Carlos Wong <carloswong54 at gmail.com> wrote:
>
> 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