Sounds good to me. Maybe in the documentation we could list the
different cache classes that are bundled the commons code by default.
That way we could include a couple different implementations and have
the users choose from them depending upon usage (much like how the JRE
comes with different GC implementations). That would be ideal. :)

- Daryl.


-----Original Message-----
From: Felipe Leme [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, October 20, 2004 8:23 PM
To: Tag Libraries Developers List
Subject: RE: Memory Leak in ELEvaluator.java (standard v1.0.6)


On Wed, 2004-10-20 at 16:26, Daryl Beattie wrote:
> Also, do we want to worry about the fact that users of the standard 
> taglib have to set some magical (i.e. non-obvious) parameter that will

> make the difference between their system being slow due to 
> re-evaluating expressions or taking up huge amounts of memory? They 
> might not expect such a thing... It would be nicer if it was somewhat 
> self-managing, or at least set to a default value that works for 90% 
> of the users. (Maybe I am not in that 90%...)

I think the best solution would be provide some sort of SPI for the
ELEvaluatorCache, for instance, a Config based property that defines the
name of a class that would implement the cache (which in turn would be a
special cache interface or just a POJUM - Plain Old Java Util Map :-).
We could also pass other init-params to fine-tune that cache (and these
parameters would depend on the implementing class). Of course, we would
provide the default implementation that covers the 90% of the cases
(maybe even self-tunable :-) plus lot of documentations.

Actually, we could go one step further and extend this SPI in other
critical places (see for instance
http://issues.apache.org/bugzilla/show_bug.cgi?id=17700 ).

-- Felipe



---------------------------------------------------------------------
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]

Reply via email to