commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Libbrecht <p...@activemath.org>
Subject Re: [jelly] SOLVED: Maven issue with Hans memory leak patch
Date Mon, 27 Jun 2005 08:32:29 GMT
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:paul@activemath.org]
> 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:paul@activemath.org]
>> 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: 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
>>
>
>
> ---------------------------------------------------------------------
> 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


Mime
View raw message