anging the
functionality of some tag libraries and possibly dynamic tags.
-Original Message-
From: Paul Libbrecht [mailto:[EMAIL PROTECTED]
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
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
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 si
ldren, never need caching.
-Original Message-
From: Paul Libbrecht [mailto:[EMAIL PROTECTED]
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 add
Original Message-
From: Paul Libbrecht [mailto:[EMAIL PROTECTED]
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 commi
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())
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
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 n
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,
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
Th
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)
A
is to put
together the list of proposed API changes and hash out where this is going
next.
-Original Message-
From: Paul Libbrecht [mailto:[EMAIL PROTECTED]
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!
Got it, thanks. I was the one who accidentally removed isCacheTags(), sorry.
-Original Message-
From: peter royal [mailto:[EMAIL PROTECTED]
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
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 earli
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
gs somehow sharing the
same map that caches Tag objects?
-Original Message-
From: peter royal [mailto:[EMAIL PROTECTED]
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
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
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
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'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, Test
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
"doesNe
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.
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:
Second call:
The
24 matches
Mail list logo
