From carloswong54 at gmail.com Tue Jul 5 11:02:38 2022 From: carloswong54 at gmail.com (Carlos Wong) Date: Thu Jul 7 10:09:05 2022 Subject: [xsd-users] Custom DOMLSParser In-Reply-To: References: Message-ID: <84B1CF4C-AE4C-47BD-B401-DF0E4936C45C@gmail.com> 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 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 wrote: >> Carlos Wong 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 parser( >> new (manager) custom_dom_LS_parser_impl(0, manager, gramPool)); > >> On Wed, Jun 8, 2022 at 10:51 AM Boris Kolpackov wrote: >> Carlos Wong 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 parser( >> new (manager) custom_dom_LS_parser_impl(0, manager, gramPool)); From carloswong54 at gmail.com Tue Jul 5 18:25:16 2022 From: carloswong54 at gmail.com (Carlos Wong) Date: Thu Jul 7 10:09:06 2022 Subject: [xsd-users] Custom DOMLSParser In-Reply-To: <84B1CF4C-AE4C-47BD-B401-DF0E4936C45C@gmail.com> References: <84B1CF4C-AE4C-47BD-B401-DF0E4936C45C@gmail.com> Message-ID: 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 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 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 wrote: >>> Carlos Wong 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 parser( >>> new (manager) custom_dom_LS_parser_impl(0, manager, gramPool)); >> >>> On Wed, Jun 8, 2022 at 10:51 AM Boris Kolpackov wrote: >>> Carlos Wong 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 parser( >>> new (manager) custom_dom_LS_parser_impl(0, manager, gramPool)); From carloswong54 at gmail.com Thu Jul 7 08:50:20 2022 From: carloswong54 at gmail.com (Carlos Wong) Date: Thu Jul 7 10:09:06 2022 Subject: [xsd-users] Custom DOMLSParser In-Reply-To: References: <84B1CF4C-AE4C-47BD-B401-DF0E4936C45C@gmail.com> Message-ID: 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 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 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 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 > wrote: > >> Carlos Wong 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 parser( >> new (manager) custom_dom_LS_parser_impl(0, manager, gramPool)); > > > On Wed, Jun 8, 2022 at 10:51 AM Boris Kolpackov > wrote: > >> Carlos Wong 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 parser( >> new (manager) custom_dom_LS_parser_impl(0, manager, gramPool)); >> > From boris at codesynthesis.com Thu Jul 7 10:26:32 2022 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Jul 7 10:21:54 2022 Subject: [xsd-users] Custom DOMLSParser In-Reply-To: <84B1CF4C-AE4C-47BD-B401-DF0E4936C45C@gmail.com> References: <84B1CF4C-AE4C-47BD-B401-DF0E4936C45C@gmail.com> Message-ID: Carlos Wong writes: > I am running into a new issue [...] Please don't send a new question by replying to an existing message. See posting guidelines, item #2 for details: https://codesynthesis.com/support/posting-guidelines.xhtml > where the embedded schema generated from xsdbin on a x86_64, does > not work on a ARM processor. The Xerces-C++ grammar serialization is pretty close to a memory dump and is therefore both Xerces-C++ version- and target-specific. In other words, you should only attempt to use a binary grammar that was serialized with the xsdbin tool built for the same target and with the same version of Xerces-C++. The easiest way to achieve this is to serialize the grammar when you build your application. Alternatively, you could pre-serialize and distribute a bunch of serialized grammars and then select the appropriate one during the build.