Hello all,
I'm working with a customer who is running into the bug described here:
http://issues.apache.org/bugzilla/show_bug.cgi?id=31789
As a result of which, I've been doing a lot of research into the
history of the problem as a lot of approaches have been suggested and
(possibly) discarded, as shown in the discussion thread on the issue:
http://servlets.com/archive/servlet/BrowseList?listName=taglibs-
dev&by=thread&from=76336
To summarize, the three possibilties for resolution raised in this
discussion were:
* To disable cacheing (quickly abandoned as the performance hit
turned out to be huge)
* To limit the size of the cache using a predetermined cacheing
strategy, either with LinkedHashMap or a LRUMap class borrowed from
Commons-Collections
* To create a custom cacheing API that would allow users to plug in
their own preferred cache
Now, I know Henri's been busy working on the pluggable cacheing API.
However, if I recall correctly from my discussions with him the new
API was not likely to be implemented fully as it seemed like overkill
for the problem. I'm inclined to agree with this assertion, as is the
customer I'm working with. What we're interested in, and what I
wonder if the community would be willing to adopt, is one of the set
strategies for limiting the size of the cache.
In the process of my research, I discovered that someone with commit
rights had in fact imported the LRUMap class from Commons-Collections
and, using it, patched the ELEvaluator class to do limited-size
cacheing, where the limit is user-defined. The code was committed to
the following branch:
http://svn.apache.org/repos/asf/jakarta/taglibs/proper/standard/
branches/STANDARD_1_0_BRANCH
And here's a link to the log message for the commit to the branch
showing the changes to ELEvaluator:
http://mail-archives.apache.org/mod_mbox/jakarta-taglibs-dev/
200410.mbox/[EMAIL PROTECTED]
This approach would solve my problem rather neatly, so I'm curious to
learn more about it. My questions for the community are thus:
* Does anyone know why this branch was abandoned?
* Does anyone know why the limited cache solution was not adopted,
despite the fact that it had already been implemented?
* 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?
* Or have I completely overlooked something and am barking up the
wrong tree?
I realize this is a terribly long email and I've asked a lot of
questions about ancient history; thank you for your patience and your
time.
Bjorn
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
