Hi,
if such issues arise; I'd clearly like to hear about them. Just to give
you an idea: a few days before 1.3RC1 has been made available, a user
reported an (unrelated) issue through which we came to realize that we
had a minor bug with descriptor caching, which unfortunately carried
quite a huge performance penalty when using a mapping file with a high
percentage of unmapped fields.
Without such issues being reported, it won't be possible at all to
a) spot such issues
b) repair/fix them.
Regards
Werner
Sudhir M wrote:
> 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
>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
