Hi Werner,
thank you very much for your input.
the approach using two mapping files with one set of classes works.
a simple unit test would look as follows (where 'getRootNsUri' determines the
namespace of the document element; ergo the targetnamespace):
public void testCastorMapping() throws Exception
{
String[] filenames = new String[] {"oldbrand.xml", "newbrand.xml"};
for (String filename : filenames)
{
String _mapping = "newbrandmapping.xml";
if ("http://www.oldbrand.com/a".equals(getRootNsUri(filename)))
_mapping = "oldbrandmapping.xml";
Mapping mapping = new Mapping();
mapping.loadMapping(getClass().getClassLoader().getResource(_mapping));
Unmarshaller unmarshaller = new Unmarshaller(mapping);
Object a = unmarshaller.unmarshal(new
InputStreamReader(getClass().getClassLoader().getResourceAsStream(filename)));
assertTrue(a instanceof com.example.app.entities.neutral.A);
}
}
however, this approach pushes the complexity towards the creation of business
objects. hopefully we can reuse parts of the originally generated classes.
regards, reinhard!
-----Ursprüngliche Nachricht-----
Von: Werner Guttmann [mailto:[email protected]]
Gesendet: Mo 26.04.2010 13:10
An: [email protected]
Cc: Reinhard Weiss
Betreff: Re: [castor-user] how to handle similar xml schemas with different
targetnamespaces as one?
Hello Reinhard,
On 23.04.2010 15:23, Reinhard Weiss wrote:
>
> hi,
>
> after a brand relaunch, some of our public xml schemas have to be
> 'relaunched' as well. and yeah, let's publish them both in parallel
> for compatibility reasons.
>
> so in addition to something not as simple as
>
> <xs:schema xmlns:xs="..." targetNamespace="http://www.oldbrand.com/a";
> xmlns:a="http://www.oldbrand.com/a";> <xs:element name="A">
> <xs:complexType> <xs:sequence> <xs:element name="Child"
> type="a:CustomType"/> </xs:sequence> </xs:complexType> </xs:element>
> ... <xs:schema>
>
> there will also be a version
>
> <xs:schema xmlns:xs="..." targetNamespace="http://www.newbrand.com/a";
> xmlns:a="http://www.newbrand.com/a";> <xs:element name="A">
> <xs:complexType> <xs:sequence> <xs:element name="Child"
> type="a:CustomType"/> </xs:sequence> </xs:complexType> </xs:element>
> ... <xs:schema>
>
>
> so far so good.
>
> we are using castor 1.0.5 (we won't upgrade to the hottest castor
> release until it's absolutely necessary) and we generate the
> corresponding objects with the castor sourcecode generator using a
> simple binding file. until now all that is done for one schema only.
> in the business logic we use the static unmarshal method of
> unmarshaller.
>
> i am not sure, how i can handle the second schema preferably on
> 'castor level', without having to double not so little business code
> instead. i want to bind the 'newbrand' schema to the exact same
> classes that where generated for the 'oldbrand' schema, without
> losing the validation features of castor for either of them.
This is simply not possible. When you have two identical
(structure-wise) XML schemas, there's no way you could have one set of
classes for both schemas.
If I were you, I'd generate a second set of classes under a new package,
and start using them.
But maybe I am not understanding your environment fully.
> i am afraid that won't work easily, because generating classes also
> freezes the respective namespace in a field of the classdescriptor. i
> think, i needed a list of acceptable namespaces...
Sorry, but Castor is a XML data binding tool. And binding simply means
binding XML to Java POJOs, with no additional flexibility. Your
requirement would basically contradict one of Castor's main contracts.
> what i have tried without success so far is: * using the
> 'org.exolab.castor.builder.nspackages' property specifying the same
> package for both targetnamespaces it does not work, because the
> latter generation run simply overrides the classes generated during
> the first run. * setting a custom 'xmlclassdescriptorresolverimpl'
> that overrides the 'resolveByXMLName' method on an unmarshaller
> instance it seems to be called never, however.
>
> further, i could think of dropping the code generation and using two
> similar xml mapping files instead - one mapping file for each of the
> schemas binding to the same set of handwritten business object
> classes.
Within one JVM (make that a class loader), this is not an option either.
You cannot map one class to more than one XML artefact. You will have to
address this versioning issue (a fairly standard one, so to say) at a
different level.
> ok, this one's odd. i have no idea, whether i am close to a solution
> or it's not supported anyway. however, does anyone have an idea how
> to deal with the problem? thanks and regards,
>
> Reinhard
Kind Regards
Werner
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
<<winmail.dat>>
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
