Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Mime-Version: 1.0 (Apple Message framework v622)
In-Reply-To: <4819F1B2A1DF9E4688D69213B9566444066673@srvexch01.tecit.intra>
References: <4819F1B2A1DF9E4688D69213B9566444066673@srvexch01.tecit.intra>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: <241520c48d8b391bf7b18bbacaab90ee@activemath.org>
Content-Transfer-Encoding: quoted-printable
From: Paul Libbrecht <paul@activemath.org>
Subject: Re: [jelly] SOLVED: Maven issue with Hans memory leak patch
Date: Mon, 27 Jun 2005 10:32:29 +0200
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>

Kristofer,

I understand it's quite an issue to be surprised of caching now... but=20=

before committing anything, I'd like to write down a kind lifecycle of=20=

a tag which would let everyone understand when a tag is created, when=20
it's set, and when its doTag method is called.

I only spent ten minutes re-reading TagScript and seem to see the=20
setters are called again at every TagScript's run... but I may have=20
read too quickly.

paul


Le 24 juin 05, =E0 16:29, Kristofer Eriksson a =E9crit :

> 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, =E0 15:33, Kristofer Eriksson a =E9crit :
>
>> 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=3D"foo"
>> attr2=3D"" />) 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=20=

>> 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, =E0 13:38, Kristofer Eriksson a =E9crit :
>>> 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=3D"foo" attr2=3D"boo" />
>>> Second call: <mylib:mytag attr1=3D"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