Your patch files remove all the changes that have been made recently (last couple of days) to Castor XML. So you may want to update your version before generating the diffs so that those changes are not lost by anyone who applies your patch.
I was current for a moment, but something with the unmarshaller you commited made my application complain about the <xml> tag and I didn't investigate further.
I'll make the patch work against the cvs without breaking anything...
Also, why do you need to "lazy-load" "all" the variables in the Marshaller? Most, if not all, those variables need to be initialized immediately upon the first call to marshal an Object instance, so I don't necessarily see the need for not initializing them upfront. Did you do some performance tests before making those changes? If so, can you share those tests with us and the results of those tests.
"Problem" was that not all the variables was needed with my usage-pattern for the Marshaller and they shouldn't be initialized if not necessary.
One variable that I sure didn't use was _processingInstructions and I refactored some PI-code in "public void marshal(Object object)" into it's own method handleProcessingInstructions().
Another example is _topLevelAtts and AttributeSetImpl creates another instance of List. _topLevelAtts is only instanciated if any items is added to it.
I don't have any numbers from performance test, I just noticed all theses unecessary instances in the profiler. It was a simple business to encapsulate the variables in the excellent Eclipse-IDE.
I'm using Castor with a webapp and every request is at minumum creating one Marshaller-instance so with many page-requests I'm sure it's a gain with "lazy"-loading.
Thanks again for your efforts on the project.
Happy to give something back, trying at least ;-)
Stein
----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
