I think it does. I took a closer look at the source generation code,
and noticed that it's hard-coded to create a setter that takes a Vector.
I changed CollectionInfo.createSetAsReferenceMethod() so that it creates
a setter that takes an List instead, which results in the desired
behavior:
public void setWidgets(Widget[] WidgetsArray)
public void setWidgets(java.util.List<Widget> WidgetsList)
public void setWidgetsList(java.util.List<Widget> WidgetsList)
Thanks,
Dhruva
-----Original Message-----
From: Werner Guttmann [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 15 November 2006 13:00
To: [email protected]
Subject: Re: [castor-user] Collection Issue with Source Generation from
Schema
Hi,
I just ran your sample XML schema fragment through the XML code
generator (against SVN trunk, which happens to be almost identical to
1.0.5), and got three methods generated as shown below:
public void setWidgets(java.lang.Object[] vWidgetsArray); public void
setWidgets(java.util.List<java.lang.Object> vWidgetsList); public void
setWidgetsList(java.util.Vector<java.lang.Object>
WidgetsVector);
Looking at the generated comments for the last setter, ...
/**
* Sets the value of '_widgetsList' by setting it to the given
* Vector. No type checking is performed.
*
* @param WidgetsVector the Vector to set.
*/
it is quite clear that this method is used to populate the content of
the List member from the Vector instance passed in.
In other words, the field info type ("j1" vs. "j2") would not have any
effect on the signature of this method.
Does this answer your question ?
Werner
Reddy, Dhruva wrote:
> Hello,
>
> We are using the source code generator to generate POJOs from XML
> schema, with Castor 1.0M4. We set the "type" flag on the generator to
> "j2", and the following properties:
>
> org.exolab.castor.builder.javaVersion = 5.0
> org.exolab.castor.builder.javaclassmapping = type
> org.exolab.castor.builder.primitivetowrapper = true
> org.exolab.castor.builder.extraCollectionMethods = true
> org.exolab.castor.builder.collections.reference.suffix = List
>
> I am running into problems with the collection methods themselves.
> Let's say I define a collection of widgets in the XSD:
>
> <xs:complexType name="GenClass">
> <xs:complexContent>
> <xs:extension base="BaseGen">
> <xs:sequence>
> <xs:element name="widgets" type="Widget" minOccurs="0"
> maxOccurs="unbounded" />
> </xs:sequence>
> </xs:extension>
> </xs:complexContent>
> </xs:complexType>
>
> This results in three setters:
>
> public void setWidgets(Widget[] vWidgetsArray)
> public void setWidgets(java.util.List<Widget> vWidgetsList)
> public void setWidgetsList(java.util.Vector<Widget>
> WidgetsVector)
>
> Previously, these setters were generated:
>
> public void setWidgets(Widget[] WidgetsArray)
> public void setWidgets(java.util.List widgetsCollection)
> public void setWidgetsList(java.util.List widgetsCollection)
>
> The issue is with setWidgetsList(). Because I set the "types" flag to
> "j2", I would expect that method to take a List, rather than a Vector,
> as it did with 1.0M4. Am I doing something wrong, have I encountered
> a bug, or is that the expected behavior? If it's the latter, is there
> any way to get the generator to create the method signature I need?
>
> Thanks,
> Dhruva
>
> ---------------------------------------------------------------------
> 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
