I'm talking about multiple binding files, e.g.:
<binding name="version1" package="com.example">
...
</binding>
<binding name="version2" package="com.example">
...
</binding>
Etc. Then when you invoke JiBX at runtime you specify "version1" or
"version2".
-Archie
On Thu, May 8, 2014 at 10:21 AM, Iacovella, Angelo <
angelo.iacove...@mckesson.com> wrote:
> What do you mean by isolated domains? Are you speaking of nesting
> mappings so they override global mappings? I can see how that would
> partially work but doesn’t do much for re-use of the nested mapping because
> of its inherent limited visibility.
>
>
>
>
>
> *From:* Archie Cobbs [mailto:arc...@dellroad.org]
> *Sent:* Thursday, May 08, 2014 11:04 AM
> *To:* JiBX users
> *Subject:* Re: [jibx-users] Multiple mappings for same element/class with
> different namespace i.e., map-as
>
>
>
> Not sure if this is a feasible option for you, but don't forget that you
> can create entirely separate binding domains by putting them under a
> different "binding" name, even for the same classes.
>
> So as a last resort you could create two "parallel universes" and try them
> both. Of course, these two bindings could use the same java classes and
> jibx XML files with just a few small changes.
>
> -Archie
>
>
>
> On Thu, May 8, 2014 at 9:03 AM, Iacovella, Angelo <
> angelo.iacove...@mckesson.com> wrote:
>
> Outside of going down the road of using the version aware binding facility
> to isolate contexts which I find only useful in the simplest scenarios –
> I’m trying to version using namespaces and ran into some significant
> limitations.
>
>
>
> - For this simple use case. CreateContract is the message for a
> new service. It uses a Contract canonical message as a child.
>
> - Originally, it was using version 1 of this and the mapping for
> Contract was not abstract and it worked fine – even though they had
> different namespaces.
>
> - But now we versioned the Contract canonical to V2 where we
> added an element that is required.
>
> - So I followed the convention to use multiple mappings for the
> same class by making them abstract whereby I should be able to explicitly
> tell JiBX which mapping to use via map-as.
>
> - But it looks like JiBX will not allow inclusion of a different
> namespace that the parent mapping. This is a big problem because we rely
> on namespaces for versioning schema canonical components.
>
> - The configuration below results in Error: Default namespace
> conflict on mapping reference; on structure element at… referencing the
> Contract child of CreateContract mapping.
>
>
>
> What I’m wondering is if anyone found a solution to this problem or if
> anyone knows of a suitable work-around. I can’t imagine that this problem
> hasn’t been run into before in any kind of complex solution requiring
> versioning with namespaces. Any suggestions much appreciated.
>
>
>
> <?xml version="1.0" encoding="UTF-8"?>
>
> <binding>
>
>
>
> <mapping name="CreateContract"
> class="com.mckesson.integration.message.contracting.CreateContract">
>
> <namespace uri="
> http://mhs.mckesson.com/contracting/schema/ContractServiceMessagesV1";
> default="elements"/>
>
> <structure name="Contract" field="contract" map-as="ContractV2"/>
>
> </mapping>
>
>
>
> <!—Version 1 of Contract canonical -->
>
> <mapping class="com.porticosys.domain.contracting.Contract"
> type-name="ContractV1" abstract="true">
>
> <namespace uri="
> http://mhs.mckesson.com/contracting/schema/ContractV2";
> default="elements"/>
>
> <value style="attribute" name="id" field="enterpriseId"
> usage="optional"/>
>
> </mapping>
>
>
>
> <!—Version 2 of Contract canonical -->
>
> <mapping class="com.porticosys.domain.contracting.Contract"
> type-name="ContractV2" abstract="true">
>
> <namespace uri="
> http://mhs.mckesson.com/contracting/schema/ContractV2";
> default="elements"/>
>
> <value style="attribute" name="id" field="enterpriseId"
> usage="optional"/>
>
> <value style="attribute" name="type" field="type"
> usage="required"/>
>
> </mapping>
>
>
>
> </binding>
>
>
>
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Is your legacy SCM system holding you back? Join Perforce May 7 to find
> out:
> • 3 signs your SCM is hindering your productivity
> • Requirements for releasing software faster
> • Expert tips and advice for migrating your SCM now
> http://p.sf.net/sfu/perforce
> _______________________________________________
> jibx-users mailing list
> jibx-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jibx-users
>
>
>
>
> --
>
> Archie L. Cobbs
>
>
> ------------------------------------------------------------------------------
> Is your legacy SCM system holding you back? Join Perforce May 7 to find
> out:
> • 3 signs your SCM is hindering your productivity
> • Requirements for releasing software faster
> • Expert tips and advice for migrating your SCM now
> http://p.sf.net/sfu/perforce
> _______________________________________________
> jibx-users mailing list
> jibx-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jibx-users
>
>
--
Archie L. Cobbs
------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
jibx-users mailing list
jibx-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jibx-users
