You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by peter royal <pr...@apache.org> on 2005/07/20 13:49:05 UTC
[jelly] 1.0-final problem wrt tag caching
On Jun 24, 2005, at 1:38 PM, Kristofer Eriksson wrote:
> Secondly, to add to the above topic, I see the change in cache
> behavior
> (since the patch?!?). When calling a Tag a second time attributes not
> specified will have values previously set, as mentioned by Brett.
>
> First call: <mylib:mytag attr1="foo" attr2="boo" />
> Second call: <mylib:mytag attr1="foo" />
>
> The second time mytag is called, attr2 will still have the value
> "boo",
> and not null or default value. My question is if this is the desired
> behavior, if not, can this be fixed somehow.
I have confirmed this behavior and it is a regression in the way the
memory leak patch is implemented. Trying to figure out how to fix it
now :)
-pete
--
peter royal -> proyal@pace2020.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [jelly] 1.0-final problem wrt tag caching
Posted by Hans Gilde <hg...@optonline.net>.
No, this is how it's always worked. It has to work this way in order to
support some of the more esoteric features of Jelly. I also tried to change
this when fixing the memory leak. As you discovered, it's currently stuck
this way. Wit can be fixed but, as I recall, it would mean changing the
functionality of some tag libraries and possibly dynamic tags.
-----Original Message-----
From: Paul Libbrecht [mailto:paul@activemath.org]
Sent: Tuesday, August 16, 2005 5:04 AM
To: Jakarta Commons Developers List
Subject: Re: [jelly] 1.0-final problem wrt tag caching
Just for me to be sure to understand... this is definitely a change
compared to pre-1.0, or ?
Can you maybe update the javadoc of setCacheTags/getCacheTags or should
we work on a page "lifecycle of a tag" ?
paul
Le 16 août 05, à 03:56, peter royal a écrit :
> On Aug 15, 2005, at 3:22 AM, Paul Libbrecht wrote:
>> At least a quick summary of caching would be that: if caching is
>> disabled, the tag object is renewed at the beginning of every new
>> run.
>> (where I understood disabled caching would imply the tag would
>> disappear much earlier).
>>
>> Maybe that's a simple formulation...
>
> That's exactly correct. On a per-thread basis, TagScript.run() results
> in a new Tag instance if caching is not enabled.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [jelly] 1.0-final problem wrt tag caching
Posted by Paul Libbrecht <pa...@activemath.org>.
Just for me to be sure to understand... this is definitely a change
compared to pre-1.0, or ?
Can you maybe update the javadoc of setCacheTags/getCacheTags or should
we work on a page "lifecycle of a tag" ?
paul
Le 16 août 05, à 03:56, peter royal a écrit :
> On Aug 15, 2005, at 3:22 AM, Paul Libbrecht wrote:
>> At least a quick summary of caching would be that: if caching is
>> disabled, the tag object is renewed at the beginning of every new
>> run.
>> (where I understood disabled caching would imply the tag would
>> disappear much earlier).
>>
>> Maybe that's a simple formulation...
>
> That's exactly correct. On a per-thread basis, TagScript.run() results
> in a new Tag instance if caching is not enabled.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [jelly] 1.0-final problem wrt tag caching
Posted by peter royal <pr...@apache.org>.
On Aug 15, 2005, at 3:22 AM, Paul Libbrecht wrote:
> At least a quick summary of caching would be that: if caching is
> disabled, the tag object is renewed at the beginning of every new run.
> (where I understood disabled caching would imply the tag would
> disappear much earlier).
>
> Maybe that's a simple formulation...
That's exactly correct. On a per-thread basis, TagScript.run()
results in a new Tag instance if caching is not enabled.
-pete
--
peter royal
Re: [jelly] 1.0-final problem wrt tag caching
Posted by Paul Libbrecht <pa...@activemath.org>.
At least a quick summary of caching would be that: if caching is
disabled, the tag object is renewed at the beginning of every new run.
(where I understood disabled caching would imply the tag would
disappear much earlier).
Maybe that's a simple formulation...
paul
Le 15 août 05, à 02:49, Hans Gilde a écrit :
> Yes, you're running into a fundamental problem: there's no difference
> between the "cache" and the mechanism that tags use to look up their
> parents.
>
> The interface solution will be a partial fix, because tags that are
> never
> looked up by their children, never need caching.
>
> -----Original Message-----
> From: Paul Libbrecht [mailto:paul@activemath.org]
> Sent: Saturday, August 13, 2005 6:31 PM
> To: Jakarta Commons Developers List
> Subject: Re: [jelly] 1.0-final problem wrt tag caching
>
> Indeed... it is running by me as well but I am fully puzzled.
> I had added, after your commit, in my version the following which I
> believed was innocent... it wasn't: In TagScript.java, replace
> Tag tag = (Tag) threadLocalTagCache.get(t);
>
> with
> Tag tag = null;
> if(context.isCacheTags())
> tag = (Tag) threadLocalTagCache.get(t);
> Indeed, otherwise, the tag is only cleared at the start of next run.
> Well, precisely this change made everything fail by me.
>
> I'll have to evaluate further for more tags-that-wish-caching but for
> now... fine!
>
> paul
>
> Le 13 août 05, à 18:25, peter royal a écrit :
>
>> On Aug 10, 2005, at 6:14 PM, Paul Libbrecht wrote:
>>> I'm annoyed... I don't obtain the same results as you do.
>>> With the default cacheTags value as false, I obtain only your test
>>> failing.
>>>
>>> With the default cacheTags value as true, I obtain many failed tests.
>>>
>>> Did you not say that with your commit, all jelly-core tests were
>>> passing ?
>>>
>>> If not then we really need to push the NeedCaching and RefusesCaching
>>> interfaces. Right ?
>>
>> yes, with the change I made, all the tests in jelly-core were passing.
>> can you give an example or two of a test that's failing for you?
>>
>> -pete
>>
>> --
>> peter royal
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [jelly] 1.0-final problem wrt tag caching
Posted by Hans Gilde <hg...@optonline.net>.
Yes, you're running into a fundamental problem: there's no difference
between the "cache" and the mechanism that tags use to look up their
parents.
The interface solution will be a partial fix, because tags that are never
looked up by their children, never need caching.
-----Original Message-----
From: Paul Libbrecht [mailto:paul@activemath.org]
Sent: Saturday, August 13, 2005 6:31 PM
To: Jakarta Commons Developers List
Subject: Re: [jelly] 1.0-final problem wrt tag caching
Indeed... it is running by me as well but I am fully puzzled.
I had added, after your commit, in my version the following which I
believed was innocent... it wasn't: In TagScript.java, replace
Tag tag = (Tag) threadLocalTagCache.get(t);
with
Tag tag = null;
if(context.isCacheTags())
tag = (Tag) threadLocalTagCache.get(t);
Indeed, otherwise, the tag is only cleared at the start of next run.
Well, precisely this change made everything fail by me.
I'll have to evaluate further for more tags-that-wish-caching but for
now... fine!
paul
Le 13 août 05, à 18:25, peter royal a écrit :
> On Aug 10, 2005, at 6:14 PM, Paul Libbrecht wrote:
>> I'm annoyed... I don't obtain the same results as you do.
>> With the default cacheTags value as false, I obtain only your test
>> failing.
>>
>> With the default cacheTags value as true, I obtain many failed tests.
>>
>> Did you not say that with your commit, all jelly-core tests were
>> passing ?
>>
>> If not then we really need to push the NeedCaching and RefusesCaching
>> interfaces. Right ?
>
> yes, with the change I made, all the tests in jelly-core were passing.
> can you give an example or two of a test that's failing for you?
>
> -pete
>
> --
> peter royal
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [jelly] 1.0-final problem wrt tag caching
Posted by Paul Libbrecht <pa...@activemath.org>.
Indeed... it is running by me as well but I am fully puzzled.
I had added, after your commit, in my version the following which I
believed was innocent... it wasn't: In TagScript.java, replace
Tag tag = (Tag) threadLocalTagCache.get(t);
with
Tag tag = null;
if(context.isCacheTags())
tag = (Tag) threadLocalTagCache.get(t);
Indeed, otherwise, the tag is only cleared at the start of next run.
Well, precisely this change made everything fail by me.
I'll have to evaluate further for more tags-that-wish-caching but for
now... fine!
paul
Le 13 août 05, à 18:25, peter royal a écrit :
> On Aug 10, 2005, at 6:14 PM, Paul Libbrecht wrote:
>> I'm annoyed... I don't obtain the same results as you do.
>> With the default cacheTags value as false, I obtain only your test
>> failing.
>>
>> With the default cacheTags value as true, I obtain many failed tests.
>>
>> Did you not say that with your commit, all jelly-core tests were
>> passing ?
>>
>> If not then we really need to push the NeedCaching and RefusesCaching
>> interfaces. Right ?
>
> yes, with the change I made, all the tests in jelly-core were passing.
> can you give an example or two of a test that's failing for you?
>
> -pete
>
> --
> peter royal
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [jelly] 1.0-final problem wrt tag caching
Posted by peter royal <pr...@apache.org>.
On Aug 10, 2005, at 6:14 PM, Paul Libbrecht wrote:
> I'm annoyed... I don't obtain the same results as you do.
> With the default cacheTags value as false, I obtain only your test
> failing.
>
> With the default cacheTags value as true, I obtain many failed tests.
>
> Did you not say that with your commit, all jelly-core tests were
> passing ?
>
> If not then we really need to push the NeedCaching and
> RefusesCaching interfaces. Right ?
yes, with the change I made, all the tests in jelly-core were
passing. can you give an example or two of a test that's failing for
you?
-pete
--
peter royal
Re: [jelly] 1.0-final problem wrt tag caching
Posted by Paul Libbrecht <pa...@activemath.org>.
Peter,
I'm annoyed... I don't obtain the same results as you do.
With the default cacheTags value as false, I obtain only your test
failing.
With the default cacheTags value as true, I obtain many failed tests.
Did you not say that with your commit, all jelly-core tests were
passing ?
If not then we really need to push the NeedCaching and RefusesCaching
interfaces. Right ?
paul
Le 4 août 05, à 03:27, peter royal a écrit :
> On Jul 23, 2005, at 4:12 PM, Paul Libbrecht wrote:
>> Two things that are particularly picky and for which we need some
>> form tag-caching:
>>
>> - define'd tags ?
>> - the swing:action tag.
>>
>> For the latter, things are particularly bad since you want to invoke
>> the action on the bean of a tag (a component, say, that you want to
>> change) without changing that component...
>>
>> But... I'll let you experiment.
>
> The unit tests for both of these taglibs passed with
> JellyContext.isCacheTags restored, so I've committed the change.
>
> I'd like to pursue the interface that means 'cache me' so we can move
> forward with caching :)
> -pete
>
> --
> peter royal
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [jelly] 1.0-final problem wrt tag caching
Posted by peter royal <pr...@apache.org>.
On Jul 23, 2005, at 4:12 PM, Paul Libbrecht wrote:
> Two things that are particularly picky and for which we need some
> form tag-caching:
>
> - define'd tags ?
> - the swing:action tag.
>
> For the latter, things are particularly bad since you want to
> invoke the action on the bean of a tag (a component, say, that you
> want to change) without changing that component...
>
> But... I'll let you experiment.
The unit tests for both of these taglibs passed with
JellyContext.isCacheTags restored, so I've committed the change.
I'd like to pursue the interface that means 'cache me' so we can move
forward with caching :)
-pete
--
peter royal
Re: [jelly] 1.0-final problem wrt tag caching
Posted by Paul Libbrecht <pa...@activemath.org>.
Two things that are particularly picky and for which we need some form
tag-caching:
- define'd tags ?
- the swing:action tag.
For the latter, things are particularly bad since you want to invoke
the action on the bean of a tag (a component, say, that you want to
change) without changing that component...
But... I'll let you experiment.
paul
Le 22 juil. 05, à 14:19, peter royal a écrit :
>> I'll do what you did and spend some time tomorrow looking at the
>> failures to see if we can have nirvana (no memory leak + exact
>> behavior semantics from when we had the leak).
>>
>
> k, i was able to get all the tests in core to pass, including the new
> one I added about the tag caching. i'm offline so i can't test all the
> taglibs since i don't have everything needed in my maven repo, but i'm
> pretty sure they'll be okay too. i'll verify when i'm back online
> prior to committing.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [jelly] 1.0-final problem wrt tag caching
Posted by peter royal <pr...@apache.org>.
On Jul 27, 2005, at 4:16 PM, Paul Libbrecht wrote:
> Maybe two simple steps:
> - introduce caching flag... compatible to earlier version.
> But without guarantees...
> - Introduce two flag interfaces:
> SingleUsageTag: needs to be recreated at every run
> StatefulTag: needs to be kept at every run
> The value of the cache flag should be used for tags that implement
> neither of them.
>
> If people agree we would, then, slowly mark tags that we know need
> one of the policies and people in an urge can apply SingleUsageTag
> to make sure the former policy is used. Moreover, several of the
> unit-tests should be run with and without setCacheTags.
>
> How does it sound ?
At first blush, good idea!
Just got home from apachecon + holiday, so i have some catching up to
do as well as looking at your last email about what the caching flag
might break.
A simpler implementation might just be to introduce a 'StatefulTag'
interface..
-pete
--
peter royal
Re: [jelly] 1.0-final problem wrt tag caching
Posted by Paul Libbrecht <pa...@activemath.org>.
Maybe two simple steps:
- introduce caching flag... compatible to earlier version.
But without guarantees...
- Introduce two flag interfaces:
SingleUsageTag: needs to be recreated at every run
StatefulTag: needs to be kept at every run
The value of the cache flag should be used for tags that implement
neither of them.
If people agree we would, then, slowly mark tags that we know need one
of the policies and people in an urge can apply SingleUsageTag to make
sure the former policy is used. Moreover, several of the unit-tests
should be run with and without setCacheTags.
How does it sound ?
paul
Le 27 juil. 05, à 03:22, Hans Gilde a écrit :
> I'm with you on the idea that tags should always be cached and should
> simply clear their state if desired. Either that, or they should never
> be cached. We could even pass the state Map in to the execute method
> along with the Context... or something like that. I'd say that the
> next step is to put together the list of proposed API changes and hash
> out where this is going
> next.
>
> -----Original Message-----
> From: Paul Libbrecht [mailto:paul@activemath.org]
> Sent: Tuesday, July 26, 2005 12:11 PM
> To: Jakarta Commons Developers List
> Subject: Re: [jelly] 1.0-final problem wrt tag caching
>
>
> Le 24 juil. 05, à 23:33, Hans Gilde a écrit :
>
>> Got it, thanks. I was the one who accidentally removed isCacheTags(),
>> sorry.
>
> By no means, I was the one and that is not so accidental.
> (I remember somewhat warning about it)
>
> Allow me to comment on the following, I think there's a deep issue
> here!
>> Previous behavior was for each call to TagScript.run() to use a new
>> tag instance.
>
> That is precisely a problem in several cases and tags should be "free
> to choose this".
>
> - I believe Swing's ActionTag cannot address its containing component
> if the tag is gone away.
>
> - I believe it is natural for the states of an http-client tag to be
> stored in the tag and not need a variable for this (e.g. for cookies)
>
> - I remember it was a problem in define-tags but cannot nail this down
> correctly now.
>
> I still believe that tags should, most of the time, be cached and would
> rather encourage end-do-tags-like clear of beans for things where it
> makes sense.
>
> What does ant do ? I think it also caches them.
>
> paul
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [jelly] 1.0-final problem wrt tag caching
Posted by Hans Gilde <hg...@optonline.net>.
I'm with you on the idea that tags should always be cached and should simply
clear their state if desired. Either that, or they should never be cached.
We could even pass the state Map in to the execute method along with the
Context... or something like that. I'd say that the next step is to put
together the list of proposed API changes and hash out where this is going
next.
-----Original Message-----
From: Paul Libbrecht [mailto:paul@activemath.org]
Sent: Tuesday, July 26, 2005 12:11 PM
To: Jakarta Commons Developers List
Subject: Re: [jelly] 1.0-final problem wrt tag caching
Le 24 juil. 05, à 23:33, Hans Gilde a écrit :
> Got it, thanks. I was the one who accidentally removed isCacheTags(),
> sorry.
By no means, I was the one and that is not so accidental.
(I remember somewhat warning about it)
Allow me to comment on the following, I think there's a deep issue here!
> Previous behavior was for each call to TagScript.run() to use a new
> tag instance.
That is precisely a problem in several cases and tags should be "free
to choose this".
- I believe Swing's ActionTag cannot address its containing component
if the tag is gone away.
- I believe it is natural for the states of an http-client tag to be
stored in the tag and not need a variable for this (e.g. for cookies)
- I remember it was a problem in define-tags but cannot nail this down
correctly now.
I still believe that tags should, most of the time, be cached and would
rather encourage end-do-tags-like clear of beans for things where it
makes sense.
What does ant do ? I think it also caches them.
paul
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [jelly] 1.0-final problem wrt tag caching
Posted by Paul Libbrecht <pa...@activemath.org>.
Le 24 juil. 05, à 23:33, Hans Gilde a écrit :
> Got it, thanks. I was the one who accidentally removed isCacheTags(),
> sorry.
By no means, I was the one and that is not so accidental.
(I remember somewhat warning about it)
Allow me to comment on the following, I think there's a deep issue here!
> Previous behavior was for each call to TagScript.run() to use a new
> tag instance.
That is precisely a problem in several cases and tags should be "free
to choose this".
- I believe Swing's ActionTag cannot address its containing component
if the tag is gone away.
- I believe it is natural for the states of an http-client tag to be
stored in the tag and not need a variable for this (e.g. for cookies)
- I remember it was a problem in define-tags but cannot nail this down
correctly now.
I still believe that tags should, most of the time, be cached and would
rather encourage end-do-tags-like clear of beans for things where it
makes sense.
What does ant do ? I think it also caches them.
paul
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [jelly] 1.0-final problem wrt tag caching
Posted by Hans Gilde <hg...@optonline.net>.
Got it, thanks. I was the one who accidentally removed isCacheTags(), sorry.
-----Original Message-----
From: peter royal [mailto:proyal@apache.org]
Sent: Sunday, July 24, 2005 4:28 PM
To: Jakarta Commons Developers List
Subject: Re: [jelly] 1.0-final problem wrt tag caching
On Jul 24, 2005, at 5:02 AM, Hans Gilde wrote:
> So I'm looking at your test, and it looks like one should expect this
> behavior (the test should always fail). Have you tried this test on a
> pre-leak-fix version of Jelly? I'm going to do so tomorrow.
Yes. This test mimics a regression from an earlier RC that I ran into
when upgrading Jelly in my application.
Previous behavior was for each call to TagScript.run() to use a new
tag instance.
> This isn't the same caching problem reported by other users. That
> problem is
> caused not by repeated invocation of the same script, but by
> something that
> is causing the same TagScript to be sued for two XML tags. This
> makes the
> second instance use the variables from the first instance.
When we fixed the ThreadLocal memory leak, JellyContext.isCacheTags()
was also removed. It is that function and the code in TagScript.run()
that checks it that I restored.
-pete
--
peter royal
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [jelly] 1.0-final problem wrt tag caching
Posted by peter royal <pr...@apache.org>.
On Jul 24, 2005, at 5:02 AM, Hans Gilde wrote:
> So I'm looking at your test, and it looks like one should expect this
> behavior (the test should always fail). Have you tried this test on a
> pre-leak-fix version of Jelly? I'm going to do so tomorrow.
Yes. This test mimics a regression from an earlier RC that I ran into
when upgrading Jelly in my application.
Previous behavior was for each call to TagScript.run() to use a new
tag instance.
> This isn't the same caching problem reported by other users. That
> problem is
> caused not by repeated invocation of the same script, but by
> something that
> is causing the same TagScript to be sued for two XML tags. This
> makes the
> second instance use the variables from the first instance.
When we fixed the ThreadLocal memory leak, JellyContext.isCacheTags()
was also removed. It is that function and the code in TagScript.run()
that checks it that I restored.
-pete
--
peter royal
RE: [jelly] 1.0-final problem wrt tag caching
Posted by Hans Gilde <hg...@optonline.net>.
So I'm looking at your test, and it looks like one should expect this
behavior (the test should always fail). Have you tried this test on a
pre-leak-fix version of Jelly? I'm going to do so tomorrow.
This isn't the same caching problem reported by other users. That problem is
caused not by repeated invocation of the same script, but by something that
is causing the same TagScript to be sued for two XML tags. This makes the
second instance use the variables from the first instance.
-----Original Message-----
From: peter royal [mailto:proyal@apache.org]
Sent: Friday, July 22, 2005 8:19 AM
To: Jakarta Commons Developers List
Subject: Re: [jelly] 1.0-final problem wrt tag caching
On Jul 22, 2005, at 1:34 AM, peter royal wrote:
> I'll do what you did and spend some time tomorrow looking at the
> failures to see if we can have nirvana (no memory leak + exact
> behavior semantics from when we had the leak).
>
k, i was able to get all the tests in core to pass, including the new
one I added about the tag caching. i'm offline so i can't test all
the taglibs since i don't have everything needed in my maven repo,
but i'm pretty sure they'll be okay too. i'll verify when i'm back
online prior to committing.
-pete
--
peter royal
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [jelly] 1.0-final problem wrt tag caching
Posted by peter royal <pr...@apache.org>.
On Jul 22, 2005, at 1:34 AM, peter royal wrote:
> I'll do what you did and spend some time tomorrow looking at the
> failures to see if we can have nirvana (no memory leak + exact
> behavior semantics from when we had the leak).
>
k, i was able to get all the tests in core to pass, including the new
one I added about the tag caching. i'm offline so i can't test all
the taglibs since i don't have everything needed in my maven repo,
but i'm pretty sure they'll be okay too. i'll verify when i'm back
online prior to committing.
-pete
--
peter royal
Re: [jelly] 1.0-final problem wrt tag caching
Posted by peter royal <pr...@apache.org>.
On Jul 21, 2005, at 8:40 PM, Paul Libbrecht wrote:
> 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 ?
>
potentially :)
> 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 ?
>
No, don't commit yet.
I'll do what you did and spend some time tomorrow looking at the
failures to see if we can have nirvana (no memory leak + exact
behavior semantics from when we had the leak).
-pete
--
peter royal
Re: [jelly] 1.0-final problem wrt tag caching
Posted by Paul Libbrecht <pa...@activemath.org>.
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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [jelly] 1.0-final problem wrt tag caching
Posted by Hans Gilde <hg...@optonline.net>.
Hiya, just getting to read this. To shed a little extra light here: You
aren't quite correct, caching tags is actually always the default. It's
needed for several tag libraries to work.
Now, the caching is supposed to be per-thread. Tags are cached in the
TagScript that instantiates the Tag object. The parser is supposed to create
one TagScript each time it finds an XML tag that is resolved by a
TagLibrary. There is supposed to be one TagScript instance per Tag, and per
XML tag.
The old code used a ThreadLocal to cache the tags. The memory leak was
caused by this ThreadLocal, all I did to fix it was to change from a
ThreadLocal to a WeakHashMap from a Thread to a Tag object. The map is local
to the TagScript. So, there should be a unique XML tag, a unique TagScript,
and so, a unique Map that caches the Tag objects .
What I cannot figure out is: why are multiple XML tags somehow sharing the
same map that caches Tag objects?
-----Original Message-----
From: peter royal [mailto:proyal@apache.org]
Sent: Thursday, July 21, 2005 5:13 AM
To: Jakarta Commons Developers List
Subject: Re: [jelly] 1.0-final problem wrt tag caching
On Jul 21, 2005, at 9:10 AM, Paul Libbrecht wrote:
> I am sorry I wasn't able to take this further yet.
> The idea was to introduce something like a reset() method on tags
> to ensure that nullity... but if you think we need to disable
> caching then we'll have to need a form of method like
> "doesNeedCaching" which would then cache in any cases. I know for
> example such things for Swing or Define tags (but not per-class).
>
> I still think Cache.reset() is better and Kristofer accept it as an
> alternative. Would you ?
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [jelly] 1.0-final problem wrt tag caching
Posted by peter royal <pr...@apache.org>.
On Jul 21, 2005, at 9:10 AM, Paul Libbrecht wrote:
> I am sorry I wasn't able to take this further yet.
> The idea was to introduce something like a reset() method on tags
> to ensure that nullity... but if you think we need to disable
> caching then we'll have to need a form of method like
> "doesNeedCaching" which would then cache in any cases. I know for
> example such things for Swing or Define tags (but not per-class).
>
> I still think Cache.reset() is better and Kristofer accept it as an
> alternative. Would you ?
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [jelly] 1.0-final problem wrt tag caching
Posted by Paul Libbrecht <pa...@activemath.org>.
Peter,
I am sorry I wasn't able to take this further yet.
The idea was to introduce something like a reset() method on tags to
ensure that nullity... but if you think we need to disable caching then
we'll have to need a form of method like "doesNeedCaching" which would
then cache in any cases. I know for example such things for Swing or
Define tags (but not per-class).
I still think Cache.reset() is better and Kristofer accept it as an
alternative. Would you ?
thanks
paul
Le 20 juil. 05, à 13:49, peter royal a écrit :
>> The second time mytag is called, attr2 will still have the value
>> "boo",
>> and not null or default value. My question is if this is the desired
>> behavior, if not, can this be fixed somehow.
>
> I have confirmed this behavior and it is a regression in the way the
> memory leak patch is implemented. Trying to figure out how to fix it
> now :)
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org