I've seen that.... mmmh.... so we should "just revert to not-caching"
(by default) then test and change the ones that need caching, correct ?
Right, now, I "just did this" (it's just a few lines of code) and...
well... I have, simply in core... the following tests failing:
TestChooseTag, TestForEachTag, TestInvokeStaticTag, TestInvokeTag,
TestNewTag, TestSwitchTag, TestJelly
And they all succeed if I change JellyContext.cacheTags to true.
Moreover I remember that jelly:define was my major goal when making
always caching...
Should I really commit that and then hunt individual failures with such
a method as "TagScript.doCacheMe"?
Wouldn't a method "Tag.reset()" make more sense ?
thanks
paul
Le 21 juil. 05, à 11:12, peter royal a écrit :
Since not caching tags was the default previously, I think we should
revert to that (The difference between revisions 136360 and 136390 in
svn).
It would be re-introducing JellyContext.isCacheTags(), but keeping the
memory leak fix (iirc, that was only removed because we thought we
could fix the memory leak by moving tag caching in the JellyContext?)
I just committed a unit test that illustrates the problem. Any
solution that doesn't require modification of the unit test is fine
with me (as I believe it represents the assumptions that Tag authors
have made, and it would be very onerous to make all users validate
their applications to determine where caching is *not* needed).
-pete
--
peter royal
---------------------------------------------------------------------
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]
