[xsd-users] Schemas defined across multiple DLLs and the static factory map instance

[Matthew.Hutchins at csiro.au]

Hi Boris,

Thanks, yes this works. I had to make a small change to your changed
code. Change "class" to "struct" and add a __declspec(dllimport) to the
import version (for both factory and serializer files):

#ifdef _MSC_VER

#ifdef XSD_TREE_EXPORT_MAP
      template struct __declspec (dllexport) type_serializer_plate<0,
char>;
#endif

#ifdef XSD_TREE_IMPORT_MAP
      extern template struct __declspec (dllimport)
type_serializer_plate<0, char>;
#endif

#endif



Matthew

 

-----Original Message-----
From: Boris Kolpackov [mailto:boris at codesynthesis.com] 
Sent: Wednesday, 18 June 2008 1:14 AM
To: Hutchins, Matthew (ICT Centre, ANU - Acton)
Cc: xsd-users at codesynthesis.com
Subject: Re: [xsd-users] Schemas defined across multiple DLLs and the
static factory map instance

Hi Matthew,

Matthew.Hutchins at csiro.au <Matthew.Hutchins at csiro.au> writes:

> The issue is that the XML reader in library A does not recognise the
> subclasses/elements from the other libraries.
> 
> The reason is that each DLL has its own unique instance of the static
> type_factory_map instance, so the elements from A are added to the
> factory map for A, the elements for B are added to the factory map for
> B, and so on.
> 
> There is a fix for this, but a change to the definition of
> type_factory_map would make it easier.
> 
> Code linked into each DLL can get access to the factory map instance
for
> its own DLL like this:
> 
>    return ::xsd::cxx::tree::type_factory_map_instance< 0, char > ();
> 
> Thus, a base class in library A can expose the factory map instance
for
> the A DLL, and classes in the other libraries can then see it. The
> register_element method can be used to manually add definitions.

This can definitely be done but there are a few drawbacks with this 
approach. First, it requires the user to manually call register_element
for each DLL but A. Second, because the maps in B, C, and D are not
used after the content is copied to A, it is somewhat wasteful.

I think there is a better fix that involves some MS C++ template/DLL
export voodoo. And if it works, then the necessary code can event be
generated automatically by the XSD compiler. The idea is to export
the static map variables in A and use them (import) in B, C, and
D. I've modified a few files in XSD 3.1.0 runtime library to test
this idea out. I would appreciate it if you could try it on your
application and let me know if it works (I tried the approach on
a simple test case and it seems to work; it is also used in a
couple of other libraries, notably ACE). Here is what needs to
be done:

1. Get the replacement files:

   http://www.codesynthesis.com/~boris/tmp/xsd-3.1.0-dll-maps.zip

2. Compile the A DLL with the XSD_TREE_EXPORT_MAP macro defined.

3. Compile the B, C, and D DLLs with the XSD_TREE_IMPORT_MAP macro
   defined.

If this works then I can go ahead and add a few compiler options to
generate this code automatically (which will also get rid of the
requirement to define XSD_TREE_*_MAP macros during compilation).

Thanks,
Boris