Hi again, Daniel,

So use a factory method to construct the item, and always return the 
same one.

  - Dennis

Krügler Daniel wrote:
> Hi Dennis,
>
> Thanks for your interest in this issue! 
>
> Actually we considered your proposed approach, but didn't try
> it out, because we *assumed*, that jibx would allocate a new item instance
> for each read item of the sequence. If this could be prevented, your
> proposal would be cleaner, I think. The prevention of that reallocation of
> items is important in our use cases, because each item usually contains
> a lot of sub items.
>
> Daniel
>
>   
>> Hi Daniel,
>>
>> That's interesting, I hadn't thought anyone would have this 
>> type of situation. But I don't understand the problem with 
>> using <collection>s. 
>> You can *define* something as a collection in JiBX binding 
>> terms without actually *having* a collection in your Java 
>> object; just define an add-method for the collection, which 
>> can throw away the processed items.
>>
>>   - Dennis
>>
>> Dennis M. Sosnoski
>> SOA, Web Services, and XML
>> Training and Consulting
>> http://www.sosnoski.com - http://www.sosnoski.co.nz Seattle, 
>> WA +1-425-296-6194 - Wellington, NZ +64-4-298-6117
>>
>>
>>
>> Krügler Daniel wrote:
>>     
>>> Hello!
>>>
>>> I wonder, why the structural attribute "allow-repeats" is 
>>>       
>> limited to unordered groups!
>>     
>>> Indeed, we use this attribute very often, because we have 
>>>       
>> the usecase 
>>     
>>> where a client program imports xml files (via jibx) which contain 
>>> large and ordered(!) sequences of the same item type each into the 
>>> same item representation (i.e. class) instance and use this item's 
>>> post-set method to transfer the instance to a server-side 
>>>       
>> database. We 
>>     
>>> *cannot* use collections here, because of its large memory 
>>>       
>> overhead in 
>>     
>>> our cases (The client itself doesn't need them). Our 
>>>       
>> solution leads to 
>>     
>>> a quite effective block-wise data transfer and our post-set 
>>>       
>> listener can use any caching strategy it likes, e.g. it can 
>> use a small buffer of only some item instances to cache them 
>> before sending the bunch to the server.
>>     
>>> The sole drawback is, that unordered reading is less 
>>>       
>> effective than ordered reading.
>>     
>>> Are there any chances to extend "allow-repeats" for ordered groups? 
>>> From my point of view this limitation seems rather 
>>>       
>> artificial, doesn't it?
>>     
>>> Greetings from Bremen,
>>>
>>> Daniel Krügler
>>>
>>>
>>> _______________________________________________
>>> jibx-users mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/jibx-users
>>>
>>>   
>>>       
>> _______________________________________________
>> jibx-users mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/jibx-users
>>
>>     
>
>
> _______________________________________________
> jibx-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/jibx-users
>
>   


_______________________________________________
jibx-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jibx-users

Reply via email to