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)