Daryl Beattie wrote: >Okay, I will create one when I have some time and send it to you folks. > > > Thanks. Please attach it to the bug report >However, the test is only testing JSTL 1.0; for JSTL 1.1, it's actually >testing the JSP container that is evaluating the expressions. Maybe we >should send the test over to the various JSP container implementors so >that they can test their evaluation mechanisms? > > > That's a good point. I agree. What's the best way of sending this to JSP container implementors? Is there an e-mail alias for JSP container ? IMO, at the very least we should test with Tomcat -Dhiru >- Daryl. > > > > >>-----Original Message----- >>From: Dhiru Pandey [mailto:Dhiru.Pandey@Sun.COM] >>Sent: Wednesday, February 23, 2005 9:16 PM >>To: Tag Libraries Developers List >>Subject: Re: Memory Leak in ELEvaluator (cont'd...) >> >> >>Daryl, >> >>It would be great to have a full example attached to the bug >>report. This way we can test it with JSTL 1.1 and future >>releases to may sure that this is not a bug going forward. >> >>Thanks, >>-Dhiru >> >>Daryl Beattie wrote: >> >> >> >>>Oops, I was wrong! >>>The example I gave won't work; it'll cache the three expressions: >>> >>>"!empty param.rand" >>>"param.rand" >>>"empty param.rand" >>> >>>And the cache will never grow. >>>So to give a proper example, I would need some Java code >>> >>> >>(for example a >> >> >>>custom tag) which writes out code to a self-refreshing JSP like this: >>> >>>Code inside RandomTag.java: >>>public int doEnd() throws JspException { >>> print(""); >>>} >>> >>>Should I bother to compile a full example? Does anybody require it? >>> >>>- Daryl. >>> >>> >>> >>> >>> >>> >>>>-----Original Message----- >>>>From: Daryl Beattie [mailto:darylb@date.com] >>>>Sent: Wednesday, February 23, 2005 11:51 AM >>>>To: 'Tag Libraries Developers List' >>>>Subject: RE: Memory Leak in ELEvaluator (cont'd...) >>>> >>>> >>>>Please see below: >>>> >>>> >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: Felipe Leme [mailto:jakartalists1@felipeal.net] >>>>>Sent: Sunday, February 20, 2005 8:14 PM >>>>>To: Tag Libraries Developers List >>>>>Subject: RE: Memory Leak in ELEvaluator (cont'd...) >>>>> >>>>> >>>>>On Fri, 2005-02-18 at 19:35, Daryl Beattie wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> It is not used anymore? I thought the JSTL expression >>>>>> >>>>>> >>>>>> >>>>>> >>>>>language and >>>>> >>>>> >>>>> >>>>> >>>>>>the JSP expression language were two different languages; >>>>>> >>>>>> >>>>>> >>>>>> >>>>>They're basically the same, except by a few differences (for >>>>>instance, JSP 2.0's EL has functions; JSTL 1.0's doesn't). >>>>> >>>>> >>>>> >>>>> >>>> Okay, that's cool. >>>> >>>> >>>> >>>> >>>> >>>>>>if so, how could the JSTL delegate evaluation to the JSP? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>On JSP 2.0, the EL is evaluated by the JSP container, not the tag >>>>>handlers. So, if the error still exists on JSTL 1.1, it should be >>>>>fixed on the web server (for instance, on Jakarta Commons >>>>> >>>>> >>EL in the >> >> >>>>>case of Tomcat-based servers). >>>>> >>>>> >>>>> >>>>> >>>> Understood. So I don't suppose anybody knows of such a >>>>problem with Tomcat or Jetty? >>>> >>>> >>>> >>>> >>>> >>>>>> No, I have not tried with JSTL 1.1; we are still using >>>>>> >>>>>> >>>>>> >>>>>> >>>>>my hacked >>>>> >>>>> >>>>> >>>>> >>>>>>version of 1.0.6. Is a migration to 1.1 a big change? Where >>>>>> >>>>>> >>>>>> >>>>>> >>>>>can I get >>>>> >>>>> >>>>> >>>>> >>>>>>a changelog for the JSTL to help in my estimation of how >>>>>> >>>>>> >>much work >> >> >>>>>>this would be? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>There are 2 majors changes you need to do in order to migrate: >>>>>- use a JSP 2.0 compatible web container (like Tomcat 5.x) >>>>>- change the URL for the taglibs (for instance, >>>>>http://java.sun.com/jsp/jstl/core instead of >>>>> >>>>> >>>>> >>>>> >>>>http://java.sun.com/jstl/core). >>>> >>>> That doesn't sound too bad, though it might require an >>>> >>>> >>upgrade of the >> >> >>>>servlet container (currently Jetty 4.19). I would have to upgrade >>>>to Jetty 5.0+ to solve the problem -- and even then there's >>>> >>>> >>no telling >> >> >>>>how Jetty handles the expression evaluation. >>>> I will look into this and get back to you... >>>> >>>> >>>> >>>> >>>> >>>>>>like this; .... The >>>>>> >>>>>> >>>>>> >>>>>> >>>>specific test I >>>> >>>> >>>> >>>> >>>>>>used to measure the leak was with our proprietary code >>>>>> >>>>>> >>>>>> >>>>>> >>>>that I cannot >>>> >>>> >>>> >>>> >>>> >>>>>>provide to people outside the company I work for >>>>>> >>>>>> >>>>>> >>>>>> >>>>(sorry...). I can >>>> >>>> >>>> >>>> >>>>>>retest any >>>>>> >>>>>> >>>>>> >>>>>> >>>>>What about creating a similar test case, with generic code (not >>>>> >>>>> >>>>> >>>>> >>>>proprietary to your company)? >>>> >>>> I could, yes.... Though it would simply be something like: >>>> >>>>test.jsp: >>>><%@taglib uri="http://java.sun.com/jstl/core" prefix="c"%> >>>> >>>> >>>> >>>> >>>> random: >>>value="${param.rand}"/> >>>> random: NONE >>>> >>>> >>>> >>>> --I actually compiled this JSP and tested it by >>>> >>>> >>deploying to my root >> >> >>>>context. It does what is expected; evaluates 3 random >>>> >>>> >>expressions each >> >> >>>>time it loads. With the expressions being cached and never expired >>>> >>>> >>>>from that cache under JSTL 1.0, this should indicate a leak just by >>> >>> >>>>watching the size of the cache grow indefinitely. >>>> I have code in my admin-tool that graphs the size of the >>>>expression evaluation cache, so I can provide graphical test >>>>results for >>>>any fixed that are provided. However, I suggest using a >>>>profiler to get >>>>results. >>>> Thanks again for your help. >>>> >>>>Sincerely, >>>> >>>> Daryl. >>>> >>>> >>>>------------------------------------------------------------ >>>> >>>> >>--------- >> >> >>>>To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org >>>>For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org >>>> >>>> >>>> >>>> >>>> >>>--------------------------------------------------------------------- >>>To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org >>>For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org >>> >>> >>> >>> >>> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org >>For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org >> >> >> > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org >For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org > > >