Actually sometime back we migrated to 1.1 but later we found that 0.9.x was
performing better than 1.1 on heavy loads. later we never got time to
evaluate the higher versions because of the tight delivery schedules.
Thanks,
sudhir.
On Fri, Nov 28, 2008 at 2:16 PM, Werner Guttmann <[EMAIL PROTECTED]>wrote:
> You are welcome. Can I ask you one question, though ? How come you are
> (still) trying to use Castor 0.9.x ?
>
> Werner
>
> Sudhir M wrote:
> > Hi Werner,
> > Thank you very much for a quick response. Actually I was trying out this
> > with castor0.9.x which isn't generating the additional methods required.
> > After migrating to 1.2 its working as you mentioned. This really helped
> us
> > in our project where we use drools which is supporting collections not
> > arrays for some specific constructs.
> >
> > Best Regards.
> > Sudhir.
> >
> >
> > On Fri, Nov 28, 2008 at 12:14 AM, Werner Guttmann
> > <[EMAIL PROTECTED]>wrote:
> >
> >> Hi Sudhir,
> >>
> >> you are correct in that the standard return type for collection
> >> properties is array based. But when you setting the following property
> >> in your builder properties
> >>
> >> # Enables generation of extra methods for collection fields, such as
> >> get/set by
> >> # reference and set as copy. Extra methods are in addition to the usual
> >> # collection get/set methods. Set this to true if you want your code to
> be
> >> # more compatible with Castor JDO.
> >> # False by default.
> >> #
> >> org.exolab.castor.builder.extraCollectionMethods=true
> >>
> >> you'll see that additional methods will be generated, such as (in my
> case):
> >>
> >> /**
> >> * Method getChildAsReference.Returns a reference to
> >> * '_childList'. No type checking is performed on any
> >> * modifications to the Vector.
> >> *
> >> * @return a reference to the Vector backing this class
> >> */
> >> public java.util.Vector<java.lang.String> getChildAsReference(
> >> ) {
> >> return this._childList;
> >> }
> >>
> >> and
> >>
> >> /**
> >> * Sets the value of '_childList' by setting it to the given
> >> * Vector. No type checking is performed.
> >> * @deprecated
> >> *
> >> * @param childVector the Vector to set.
> >> */
> >> public void setChildAsReference(
> >> final java.util.Vector<java.lang.String> childVector) {
> >> this._childList = childVector;
> >> }
> >>
> >> If you are not seeing these additional methods, it might be that you are
> >> mis-configuring the builder property file.
> >>
> >> Regards
> >> Werner
> >>
> >> Sudhir M wrote:
> >>> Hi,
> >>> We have a requirement to use collections in the source generated by
> >> castor.
> >>> The getter and setter method returns an array and takes an array as
> >> input.
> >>> Is there a way to change it to take a collection and return a
> collection.
> >>>
> >>> for example:
> >>>
> >>> Order has items with maxOccurs as unbounded.
> >>>
> >>> The code is generated as private java.util.Vector itemsList; but the
> >> getter
> >>> and setter methods returns Items[] and takes Items[] as input. Can we
> >>> generate the code use java.util.List instead of arrays. I have tried
> >> using
> >>> the property org.exolab.castor.builder.extraCollectionMethods=true. It
> >>> generates some additional methods to operate the list but the getter
> and
> >>> setter still uses array.
> >>>
> >>> Any help in this regard is highly appreciated.
> >>>
> >>> Thanks,
> >>> sudhir.
> >>>
> >> ---------------------------------------------------------------------
> >> 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
>
>
>
