Can you try calling .clear() on the result of this
context.runScript(uri, output, isExport(), isInherit())
(and the other call).Maybe that'll help.
In all cases, this context is gc-ed shortly after, I believe... so I see no reasons for big leaks at the tag-cache level.
Also, maybe it would help to give more details where to go... I think this was reported about very long ago so maybe a distribution maven-1.0.2 or such should have this bug ?
paul
Le 24 janv. 05, à 12:35, Brett Porter a écrit :
Hi,
I did some testing and can confirm that the current site generation memory leak occurs here:
<j:file name="${outFile}" encoding="${outputencoding}" omitXmlDeclaration="true" outputMode="xml" prettyPrint="no"> --> <j:include uri="${stylesheet.toString()}"/> </j:file>
If I remove the include, nothing is leaked. So, while this is obviously a whole lot of additional Jelly (actually, its this: http://svn.apache.org/repos/asf/maven/maven-1/plugins/trunk/xdoc/src/ plugin-resources/site.jsl); it is just Jelly - nothing about Maven's context creation AFAICT.
j:include does a context.runScript(uri, output, isExport(), isInherit()); which is when the caching occurs, right?
So are there any further ideas about where the leak is? IS it the JSL used in site.jsl, the j:include itself, or something else? Do you need me to do more narrowing down within site.jsl or does someone have a hunch?
Thanks, Brett
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
