Hi Werner,
thank you for your answer.
First: no I haven't used the code generator. The hibernate POJOs were
generated via HibernateTools generator. I tried to do the mapping manually.
Today I tried the Ant-task to generate the POJOs via the xsd. But that
results in a huge pille of Java files and there are some problems with the
enum parts of the domains (we use many custom data types in the xsd). Also
there might still a problem with Java5 compliance (found this:
http://permalink.gmane.org/gmane.comp.java.castor.user/9718 and tried to
replace the mentioned jars - and switched to the latest 1.3.3-RC1 - but the
problem with "bad version number" still exists). I switched to a sample
project with JDK6 for the code generation and at least that problem was
gone.
I thought setting "generateMapping" will generate the mapping-xml as well.
But it doesn't... So I tried to the MappingTool to write the gen_mapping.xml
afterwards. That results in "No enum const class
org.exolab.castor.mapping.xml.types.BindXmlNodeType.attribute" ... so.. I
don't see light at the end of the tunnel :(
I just wanna know how to collect the different types of elements within the
list definition. An ordered list with leadProject, leadSs, coProject, coSs
elements (or a generic type like a HashMap) would be sufficient. With the
correct order I can re-create my target domain with the proper
values/elements.
The separation via DTO <> domain objects make sense. In fact I did it that
way previously for another implementation (but with a very easy/flat
message/domain). But it doesn't solve the very first problem getting the
right mapping instruction for castor (I failed generating it via the tools
as mentioned above).
Any other hints how to capture the list elements properly?

Cheers,
Philipp


Werner Guttmann-6 wrote:
> 
> Hi,
> 
> assuming that you are using Castor's code generator to generate Java 
> code from the XML schema definitions (correct me if I am wrong here), 
> you'll get a batch of Java POJOs that more or less mirror the structures 
> defined in your schema.
> 
> Given that you've got some complexity in there (uses of choices and 
> sequences and a mix thereof); I'd suggest that you keep things separated 
> from your domain model. If the XML schema was e.g. part of a WADL 
> definition, specifying the payload of various REST resources, I'd treat 
> the generated Java classes as DTOs only, and internally map them to a 
> model POJO that I'd use (amongst other things) to persist to a database 
> using Hibernate.
> 
> Given that there's always a gap between e.g. the XML schema 
> specification and your requirements with regards to persistence (domain 
> model in general), I am always in favour of keeping things apart and 
> live with the minor overhead of having to convert/map between DTOs and 
> domain classes.
> 
> Does this make sense ?
> 
> Kind Regards
> Werner
> 
> On 18.06.2012 16:45, rednix wrote:
>>
>> Hi,
>>
>> I'm struggling with a mapping/unmarshalling of a XML which contains a
>> sequence with an optional element.
>>
>> Here is the XSD part for the list:
>>
>>          <xs:element name="relations" maxOccurs="1" minOccurs="0"
>> type="relationsType">
>>          </xs:element>
>>
>>      <xs:complexType name="relationsType">
>>              <xs:annotation>
>>                      <xs:documentation xml:lang="en">Either a set of  a lead 
>> project and a
>> lead-sourcing scope or a set of cosourced projects with an optional
>> sourcing
>> scope.</xs:documentation>
>>              </xs:annotation>
>>              <xs:choice minOccurs="1" maxOccurs="1">
>>                      <xs:sequence minOccurs="1" maxOccurs="1">
>>                              <xs:element name="leadProject" 
>> type="projectType" minOccurs="1"
>> maxOccurs="1"/>
>>                              <xs:element name="leadSs" maxOccurs="1" 
>> minOccurs="1"
>> type="ssRefType"/>
>>                      </xs:sequence>
>>                      <xs:sequence maxOccurs="500" minOccurs="1">
>>                              <xs:element name="coProject" maxOccurs="1" 
>> minOccurs="1"
>> type="projectType">
>>                              <xs:annotation>
>>                                      <xs:documentation 
>> xml:lang="en">CoProject (short for co-sourced
>> project) names and identifies a co-sourced project.</xs:documentation>
>>                              </xs:annotation>
>>                              </xs:element>
>>                              <xs:element name="coSs" maxOccurs="1" 
>> minOccurs="0" type="ssRefType">
>>                              </xs:element>
>>                      </xs:sequence>
>>              </xs:choice>
>>      </xs:complexType>
>>
>> The element coSs is optional and may occur 0 or 1 times.
>> Here is a snippet of the corresponding XML:
>>
>> <sourcingScope>
>>      <relations>
>>          <coProject name="&gt;project &quot;full&quot; name&lt;"
>> short="project short name" id="PROJ_ID"/>
>>          <coSs number="9876-12" id="54987321"/>
>>
>>          <coProject name="blubberbla" short="blubberbla short name"
>> id="blubber_bla"/>
>>              
>>          <coProject name="CoSourced01Vu" short="MVP 02 w/ VU"
>> id="PROJ_ID_01"/>
>>          <coSs number="9999-99" id="12345678"/>
>>      </relations>
>> </sourcingScope>
>>
>>
>> I want coProject and coSs be coupled together on the Java side in one
>> object
>> in the list. The coupling is defined by the order of the elements. So the
>> first obj in the list would have PROJ_ID and 54987321; second only
>> blubber_bla without a coSs info and the third processed like the 1st one.
>> The thing with the lead choice is an additional case (then there are no
>> co-elements and exactly two lead elements).
>>
>> The Java list element (which is actually a hibernate domain object) looks
>> like this:
>>
>> public class VuRelation implements java.io.Serializable {
>>
>>      private Long id; // internal id
>>      private SourcingScope sourcingScope; // ref to parent
>>
>>      // set for lead-sourcing
>>      private String leadVuId;
>>      private String leadVuNr;
>>
>>      private String leadProjectId;
>>      private String leadProjectShortName;
>>      private String leadProjectName;
>>
>>      // set for co-sourcing
>>      private String coVuId;
>>      private String coVuNr;
>>
>>      private String coProjectId;
>>      private String coProjectShortName;
>>      private String coProjectName;
>>
>> ... and linked in the main object like this:
>>
>> public class SourcingScope implements java.io.Serializable {
>>      private Set<VuRelation> relations = new HashSet<VuRelation>();
>> }
>>
>>
>> How should the castor mapping look like for this case? How can I "tell"
>> castor to encapsulate certain elements on the same hierarchy xml level
>> into
>> one object (combined with optional elements)?
>>
>> Any help is appreciated!
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
> 
>     http://xircles.codehaus.org/manage_email
> 
> 
> 
> 

-- 
View this message in context: 
http://old.nabble.com/Unmarshalling-sequence-with-optional-elements-tp34030528p34049799.html
Sent from the Castor - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply via email to