Thanks, Nigel. I (most likely) will have a peek once we are past the 1.3 GA release.
Regards Werner N Perkins wrote: > Hi Werner, > > Many thanks for the quick response. > As requested, I have created a Jira issue to cover this (CASTOR-2640). > > The attachment contains a simple example that illustrates the issue. > Please see the readme for further details. > > Regards, > Nigel > > 2009/2/5 Werner Guttmann <[email protected]>: >> Hi Nigel, >> >> what you are describing below should work out of the box. I know that >> you are probably over-simplifying, but I need something to look at in >> detail. >> >> Would you mid creating a new Jira issue at >> >> http://jira.codehaus.org/browse/CASTOR >> >> and attch all files for me (us) to be able to reply the issue at hand. >> >> Thanks in advance >> Werner >> >> N Perkins wrote: >>> Hi, >>> >>> I would be grateful if anyone has any advice regarding the following issue. >>> >>> When using XML code generated classes, I am able to unmarshal a >>> document containing an element that is an extension of the target >>> type. However, the resulting object has the runtime type of the >>> target (base) type, and so any extended values are unavailable. >>> >>> To illustrate, a simple example follows. >>> The schema defines a base ProductType, an extension ShirtType, and >>> dictates that an inventory has a product: >>> >>> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema";> >>> <xsd:complexType name="InventoryType"> >>> <xsd:sequence> >>> <xsd:element name="product" type="ProductType"/> >>> </xsd:sequence> >>> </xsd:complexType> >>> >>> <xsd:complexType name="ProductType"> >>> <xsd:sequence> >>> <xsd:element name="number" type="xsd:integer"/> >>> <xsd:element name="name" type="xsd:string"/> >>> </xsd:sequence> >>> </xsd:complexType> >>> >>> <xsd:complexType name="ShirtType"> >>> <xsd:complexContent> >>> <xsd:extension base="ProductType"> >>> <xsd:sequence> >>> <xsd:element name="size" type="xsd:integer"/> >>> <xsd:element name="color" type="xsd:string"/> >>> </xsd:sequence> >>> </xsd:extension> >>> </xsd:complexContent> >>> </xsd:complexType> >>> >>> <xsd:element name="inventory" type="InventoryType"/> >>> </xsd:schema> >>> >>> The code generator defines abstract classes for the following complex types: >>> - InventoryType >>> - ProductType >>> - ShirtType (extends ProductType) >>> >>> The code generator defines the following element classes: >>> - Inventory >>> - Product >>> >>> Note that these classes do not cater for the instantiation of an >>> instance of ShirtType. >>> >>> In an instance document, a shirt can be substituted for the base >>> product type, with xsi:type indicating the substitution: >>> >>> <?xml version="1.0" encoding="UTF-8"?> >>> <inventory xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; >>> xsi:noNamespaceSchemaLocation="inventory.xsd"> >>> <product xsi:type="ShirtType"> >>> <number>999</number> >>> <name>Test Shirt</name> >>> <size>40</size> >>> <color>Blue</color> >>> </product> >>> </inventory> >>> >>> Invoking getProduct() on the Unmarshalled Inventory instance returns >>> an object with a runtime type of Product, resulting in a loss of type >>> information. Is there any way to have getProduct() return an instance >>> of ShirtType in this scenario? >>> >>> The above example is purely for illustrative purposes. The actual >>> problem domain involves a much more complicated schema, which is prone >>> to change, and outside of my control. My preferred approach, if >>> possible, is to rely solely on the generated classes, and to avoid >>> introducing custom mappings. >>> >>> Any thoughts would be greatly appreciated. >>> Regards, >>> Nigel >>> >>> --------------------------------------------------------------------- >>> To unsubscribe from this list, please visit: >>> >>> http://xircles.codehaus.org/manage_email >>> >>> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> >> > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
