Re: Memory leak in ELEvaluator: approaches and alternatives

Interesting difference... from the previous patches.

So there's the addition of the LRUMap and its baggage. Definitely
better than depending on Collections, I'm very sure we don't want to
add a dependency to Standard and to EL, and presumably we can't go to
a 1.4 dependency, so no LinkedHashMap for us.

I'm tempted to refactor things so all the interfaces aren't there,
flatten it all into a single package and make it tighter. On the one
hand that will make it harder to bring bugfixes over, but on the other
hand it will do a lot to lowering the window that adding this opens to
the API. Refactoring is best done after the first bit goes in. We
should also add a "Contains code from Commons Collections".

Evaluator.java adds a bit where it always bypasses the cache when
calling validate. I guess that makes sense and doesn't hurt to do.

ELEvaluator.java is again where all the fun is. BypassCache becomes a
full on property so that Evaluator can turn it off. It also adds a
pageContext to allow the configuration to be set.

Looks good - I'll look into committing it tomorrow night, unless
anyone sees a reason not to.

Hen

On 9/26/07, Bjorn Townsend <[email protected]> wrote:
>
> I've gone ahead and created a patch for 1.1 and attached it to the
> issue:
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=31789
>
> Unit tests pass nicely.
>
> Thanks,
> Bjorn
>
> On Sep 26, 2007, at 12:06 AM  September 26, Henri Yandell wrote:
>
> >
> >> * Is there any interest in adopting this solution for 1.1 given that
> >> (from my reading of the code) it could be dropped into place fairly
> >> readily and is less complex than Henri's proposed API solution?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>