How about writing down a unit-test for this, maybe with a foreach
around ?
Also, this could serve as a basis for the lifecycle explanation...
paul
Le 28 juin 05, à 02:23, Hans Gilde a écrit :
Paul, I believe that you are correct, which is why I'm worried. I went
through various scenarios with the caching patch and thought that there
would be absolutely no change whatsoever to the functionality. This is
why I
was a little freaked out when Brett reported the difference in Maven.
Honestly, I still can't see how the current code would produce
behavior that
is any different from the old code. For example, let's say that we
have this
snippet:
<a attr1="${v}" attr2="foo">
<b attr3="bar" />
</a>
Let's say that the Tags bound to a and b extend TagSupport. In this
case,
they should have all their attribute setters called each time they are
run.
I can't find the case where, for instance, on the second run, the tag a
would somehow not have both setters called.
-----Original Message-----
From: Paul Libbrecht [mailto:[EMAIL PROTECTED]
Sent: Monday, June 27, 2005 4:32 AM
To: Jakarta Commons Developers List
Subject: Re: [jelly] SOLVED: Maven issue with Hans memory leak patch
Kristofer,
I understand it's quite an issue to be surprised of caching now... but
before committing anything, I'd like to write down a kind lifecycle of
a tag which would let everyone understand when a tag is created, when
it's set, and when its doTag method is called.
I only spent ten minutes re-reading TagScript and seem to see the
setters are called again at every TagScript's run... but I may have
read too quickly.
paul
Le 24 juin 05, à 16:29, Kristofer Eriksson a écrit :
Just TagSupport
-----Original Message-----
From: Paul Libbrecht [mailto:[EMAIL PROTECTED]
Sent: Freitag, 24. Juni 2005 16:26
To: Jakarta Commons Developers List
Subject: Re: [jelly] SOLVED: Maven issue with Hans memory leak patch
Which tag-class are you subclassing ?
paul
Le 24 juin 05, à 15:33, Kristofer Eriksson a écrit :
Hi Paul,
many thx for the quick answer.
In my case, yes I do expect the setters to be called at every new
run.
Setters receiving an expression would solve my problem, or always
specifying all attributes, even "empty" ones (<mylib:mytag
attr1="foo"
attr2="" />) but then all scripts (and I have loads) needs to be
modified.
I believe there would be useful though, not only for me but in
general, to have some way to disable caching per tag or (preferably)
some sort of "re-run-setters" method that is called on every run as
you suggested. Either solution would solve my problem.
Regards
/Kristofer Eriksson
-----Original Message-----
From: Paul Libbrecht [mailto:[EMAIL PROTECTED]
Sent: Freitag, 24. Juni 2005 14:14
To: Jakarta Commons Developers List
Subject: Re: [jelly] SOLVED: Maven issue with Hans memory leak patch
Since a bit earlier than the patch, indeed, caching has been
activated
by default and caching disablement has been removed. This was needed
at
least by some jelly:define tags, as far as I could tell.
Can you give more details ?
- Do you expect the setters to be called at every new run ?
- Would you have enough if having a method accessible such as
"re-run-setters"?
- Alternatively, would you be happy with overall cache-disablement
(at
your own risks) ?
- Finally, did you not find a possibility to have setters receive
expressions which, then, get re-evaluated each time needed ? I would
believe this would be the best practice.
thanks
paul
Le 24 juin 05, à 13:38, Kristofer Eriksson a écrit :
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.
Kind Regards
/Kristofer Eriksson
--------------------------------------------------------------------
-
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]
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
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]
