Re: streaming document output

Rolf,

The iterator based code worked fine for our use case and we can stream a 
dynamic document. Yay! Sometime this week I am going to integrate this 
into another  system which has the potential to stream lots of data; at 
that point I'll be able to determine that memory consumption remains modest.

So -- this is excellent. I'll use the jar you sent me for now and watch 
for the next release.

Thanks again,

Pat

On 04/12/2013 03:07 PM, Rolf Lear wrote:
> See attached. - Jar, and the two files I changed (just in case).
>
> Please try it... it is iterator-only, passes my tests (except one which
> I have updated now because this code produces a better result in one
> extreme use case....)
>
> Rolf
>
> On 12/04/2013 12:04 PM, Patrick Dowler wrote:
>>
>> Sure, email me the build and we cna try it out pretty easily.
>>
>> thanks Rolf!!
>>
>> Pat
>>
>> On 04/11/2013 07:25 PM, Rolf Lear wrote:
>>> OK, that means I have had to alter the more complicated
>>> AbstractFormattedWalker class.
>>>
>>> I have a test build I would like you to run. Is this an option? Can I
>>> email it to you? It passes all my JUnit tests, and uses just an iterator
>>> for all the output.
>>>
>>> Thanks
>>>
>>> Rolf
>>>
>>> On 11/04/2013 4:28 PM, Patrick Dowler wrote:
>>>>
>>>> We normally use Format.getPrettyFormat()
>>>>
>>>> Patrick
>>>>
>>>> On 04/11/2013 11:30 AM, Rolf Lear wrote:
>>>>> Oh, are you using 'raw' output, or are you making it 'pretty' or other
>>>>> format?
>>>>>
>>>>> Rolf
>>>>>
>>>>> On 11/04/2013 1:29 PM, Patrick Dowler wrote:
>>>>>>
>>>>>> We have a few web services that send XML documents in the response.
>>>>>> The documents can be large and when they are there is always one spot
>>>>>> where there is an arbitrarily long list of child elements.
>>>>>>
>>>>>> With jdom1 we had implemented a subclass of Element for the element
>>>>>> with the long list of child elements and then had the iterator over
>>>>>> that list dynamically generate the children. Since the XMLOutputter
>>>>>> used indexed access rather than the iterator, we also had to subclass
>>>>>> it and override the list access. That works fine at the time.
>>>>>>
>>>>>> No we are porting to jdom2 and I see that the outputter still uses
>>>>>> indexed access; that is a shame given all the comments in the code
>>>>>> about how the iterator is generally better than having to call size()
>>>>>> on the lists. It would be really nice and enable people to implement
>>>>>> customisations if jdom2 used the iterators rather than the indexing
>>>>>> throughout the codebase. Is that a lot of work?
>>>>>>
>>>>>> The further problem we have right now is that XMLOutputter is
>>>>>> final so
>>>>>> we can't trivially port our jdom1 code. Is implementing a custom
>>>>>> XMLOutputProcessor the right place to do that? The change we'd be
>>>>>> making is to change it to use iterators... is that something that
>>>>>> should go into the core library?
>>>>>>
>>>>>> For XMLOutputProcessor, I am looking specifically at these methods:
>>>>>>
>>>>>> process(Writer,Format,Element)
>>>>>> process(Writer,Format,List)
>>>>>>
>>>>>> Is that the place to change to iterators?
>>>>>>
>>>>>>
>>>>>
>>>>> .
>>>>>
>>>>
>>>
>>> .
>>>
>>
>

-- 

Patrick Dowler
Canadian Astronomy Data Centre
National Research Council Canada
5071 West Saanich Road
Victoria, BC V9A 2L9

250-363-0044 (office) 250-363-0045 (fax)
_______________________________________________
To control your jdom-interest membership:
http://www.jdom.org/mailman/options/jdom-interest/[email protected]