DO NOT REPLY [Bug 33650] - Jasper performance for multiple files processing

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 33650] - Jasper performance for multiple files processing

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 33650] - Jasper performance for multiple files processing

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 33650] - Jasper performance for multiple files processing

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 33650] - Jasper performance for multiple files processing

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 33650] - Jasper performance for multiple files processing

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 33650] - Jasper performance for multiple files processing

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 33650] - Jasper performance for multiple files processing

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 33650] - Jasper performance for multiple files processing

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 33650] - Jasper performance for multiple files processing

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 33650] - Jasper performance for multiple files processing

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 33650] - Jasper performance for multiple files processing

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 33650] - Jasper performance for multiple files processing

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 33650] - Jasper performance for multiple files processing

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 33650] - Jasper performance for multiple files processing

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 33650] - Jasper performance for multiple files processing

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 33650] - Jasper performance for multiple files processing

t] [edit] > > modified Options targeted at jasper performance improvement > > You should submit patches in diff format ("cvs diff"). It's too difficult to > evaluate the patch when you just post the entire modified file. Thank you. I will replace the format. --

DO NOT REPLY [Bug 33650] - Jasper performance for multiple files processing

gzilla/show_bug.cgi?id=33650 --- Additional Comments From [EMAIL PROTECTED] 2005-08-19 22:55 --- (In reply to comment #17) > Created an attachment (id=16121) --> (http://issues.apache.org/bugzilla/attachment.cgi?id=16121&action=view) [edit] > modified Options targeted at

DO NOT REPLY [Bug 33650] - Jasper performance for multiple files processing

gzilla/show_bug.cgi?id=33650 --- Additional Comments From [EMAIL PROTECTED] 2005-08-19 22:38 --- Created an attachment (id=16124) --> (http://issues.apache.org/bugzilla/attachment.cgi?id=16124&action=view) modified TagLibraryInfoImpl targeted at jasper performance improvement

DO NOT REPLY [Bug 33650] - Jasper performance for multiple files processing

gzilla/show_bug.cgi?id=33650 --- Additional Comments From [EMAIL PROTECTED] 2005-08-19 22:37 --- Created an attachment (id=16123) --> (http://issues.apache.org/bugzilla/attachment.cgi?id=16123&action=view) modified EmbeddedServletOptions targeted at jasper performance improvement

DO NOT REPLY [Bug 33650] - Jasper performance for multiple files processing

gzilla/show_bug.cgi?id=33650 --- Additional Comments From [EMAIL PROTECTED] 2005-08-19 22:32 --- Created an attachment (id=16122) --> (http://issues.apache.org/bugzilla/attachment.cgi?id=16122&action=view) modified JspC targeted at jasper performance improvement -- Configure

DO NOT REPLY [Bug 33650] - Jasper performance for multiple files processing

gzilla/show_bug.cgi?id=33650 --- Additional Comments From [EMAIL PROTECTED] 2005-08-19 22:25 --- Created an attachment (id=16121) --> (http://issues.apache.org/bugzilla/attachment.cgi?id=16121&action=view) modified Options targeted at jasper performance improvement -- Configure

DO NOT REPLY [Bug 33650] - Jasper performance for multiple files processing

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 33650] - Jasper performance for multiple files processing

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 33650] - Jasper performance for multiple files processing

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 33650] - Jasper performance for multiple files processing

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 33650] - Jasper performance for multiple files processing

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 33650] - Jasper performance for multiple files processing

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 33650] - Jasper performance for multiple files processing

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 33650] - Jasper performance for multiple files processing

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 33650] - Jasper performance for multiple files processing

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 33650] - Jasper performance for multiple files processing

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 33650] - Jasper performance for multiple files processing

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 33650] - Jasper performance for multiple files processing

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 33650] - Jasper performance for multiple files processing

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 33650] - Jasper performance for multiple files processing

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 33650] - Jasper performance for multiple files processing

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 33650] - Jasper performance for multiple files processing

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 33650] New: - Jasper performance for multiple files processing

gzilla/show_bug.cgi?id=33650 Summary: Jasper performance for multiple files processing Product: Tomcat 5 Version: 5.0.30 Platform: PC OS/Version: Windows XP Status: NEW Severity: enhancement Priority: P2 Com

Jasper performance query (circa 3.1 code)

I'm using Jasper in Weblogic from tomcat 3.1 (ish, we've patched a couple of things too). While profiling some of my JSP's, I see the JspRuntimeLibrary.introspectHelper consuming between 40-70% of the time, and a large %age of the object creation. Drilling down, most of the time is the line (which

Re: Jasper performance/3.3 tag pooling

>I agree. I spent some time last week looking at possible >optimizations. The general ideas were: > >- pool tag handler objects per application. This could >still be turned on/off at runtime via module and is >already available. > >- cache (re-use) handlers per page - i.e. only get the handler >

Re: Jasper performance/3.3 tag pooling

Hey Mel, I'll use this as a chance to explain some thoughts I've recently had on tag pooling. Maybe you and others have comments. Mel Martinez wrote: > > Hi folks! > > I'm still overwhelmed with other priorities (new job, > house-hunting, moving, etc.) to be able to help again, > but I manag

Re: Jasper performance/3.3 tag pooling

Hi folks! I'm still overwhelmed with other priorities (new job, house-hunting, moving, etc.) to be able to help again, but I managed over the last day or so to get caught up with the list (for the most part - skipped some major threads along the way). On tag-pooling: I am +1 on implementing a t

Re: Jasper performance/3.3 tag pooling

> Thanks for sending the test application. I've been using monthlist.jsp while > testing rendered then hand bashed code. After some preliminary bashing :) > I think it will be possible to call all setters (except runtime expressions) > only once per run of the page. Also, we can create / obtain

Re: Jasper performance/3.3 tag pooling

was faster for you, but any tag related optimizations we can make should help other tag users (me and my day job included). If you send a new jar, I'll test it out and let you know. -casey Rickard Öberg wrote: > > [EMAIL PROTECTED] wrote: > > > Jasper performance is a high priority thing

RE: Jasper performance/3.3 tag pooling (XSLT)

Hi Costin, > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, May 23, 2001 10:20 AM > > ... > > I'm working on a refactoring of jasper, and "easy to read" is a big > priority. It's moving a bit slower than I expected - now I'm back on > planning s

Re: Jasper performance/3.3 tag pooling

[EMAIL PROTECTED] wrote: > > Jasper performance is a high priority thing for us (nr 1. on our "system > > performance fixing" list actually), so if possible, absolutely. I can't > > say I've delved that far into Jasper yet though. It was a bit hard to >

Re: Jasper performance/3.3 tag pooling

I think the changes will be too big to add before the 3.3 freeze. I like your alternative and will start bashing the jsp->java files to get something optimal before changing the jasper34 generator code. I'll let you know when I have something that looks interesting so that it can be discussed b

Re: Jasper performance/3.3 tag pooling

Casey, We hope to freeze 3.3 for a release in the next weeks. If you feel the changes are reasonably small and will not create problems - you can still do it. What about: 1. We copy the code from 3.3 as it is in jasper34 area ( except that we rename the package ). 2. We make sure it builds a

Re: Jasper performance/3.3 tag pooling

Costin & Craig, I agree with both of you. The optimizations that Craig mentioned are exactly the ones that I was hoping to add. Yes, the least fun part will probably be adding to the existing generator code. But, until a new generating architecture is in place, I think it would be good to go

Re: Jasper performance/3.3 tag pooling

On Wed, 23 May 2001, Craig R. McClanahan wrote: > I know Costin loves evolutionary change :-), and it's certainly a valid > approach to Jasper. > > But there is also another approach we should consider - a green-field > recoding of at least some of the major components (conforming to an > agreed

Re: Jasper performance/3.3 tag pooling

On Wed, 23 May 2001 [EMAIL PROTECTED] wrote: > On Wed, 23 May 2001, Casey Lucas wrote: > > > > > btw, If i start tinkering, should I work with jasper34 or the 3.3 stuff? > > Difficult question... > > The problem with jasper34 is that it doesn't work yet ( the one in > proposals/jasper34 - I

Re: Jasper performance/3.3 tag pooling

On Wed, 23 May 2001, Casey Lucas wrote: > > btw, If i start tinkering, should I work with jasper34 or the 3.3 stuff? Difficult question... The problem with jasper34 is that it doesn't work yet ( the one in proposals/jasper34 - I still have to move it in the new repository ). Mea culpa - I trie

Re: Jasper performance/3.3 tag pooling

On Wed, 23 May 2001, Rickard Öberg wrote: > Jasper performance is a high priority thing for us (nr 1. on our "system > performance fixing" list actually), so if possible, absolutely. I can't > say I've delved that far into Jasper yet though. It was a bit hard

Re: Jasper performance/3.3 tag pooling

Glenn Nielsen wrote: [snip] > > I just had an idea (dangerous things) regarding tag pooling optimizations. > > When Jasper translates a page it should be able to generate information > about which tag handler classes it needs, and for each tag handler, the > profile of the attribute/value pa

Re: Jasper performance/3.3 tag pooling

Glenn Nielsen wrote: > I just had an idea (dangerous things) regarding tag pooling optimizations. > > When Jasper translates a page it should be able to generate information > about which tag handler classes it needs, and for each tag handler, the > profile of the attribute/value pairs. At runti

Re: Jasper performance/3.3 tag pooling

ces..? The only way to really know > is for the page to do its thing, and pull the tags from the global pool. > And then you're in "synch" land again. > > Do you understand now? I realize the above is a bit fuzzy... > > > > I hope that Costin will be able to reproduce

Re: Jasper performance/3.3 tag pooling

[EMAIL PROTECTED] wrote: > But in tomcat 3.3 we do a different trick - the thread pool is maintaining > a "local storage" for each thread, and it's passing it to the worker. > > The only synchronization in tomcat is in getting a thread from the thread > pool - besides that we shouldn't need anyth

Re: Jasper performance/3.3 tag pooling

hope that Costin will be able to reproduce what I found. > > I hope not :-) > > Again - thanks for doing the tests and checking the code, and hope to see > more contributions and maybe few patches :-) Jasper performance is a high priority thing for us (nr 1. on our "system perfor

Re: Jasper performance/3.3 tag pooling

On Tue, 22 May 2001, Rickard Öberg wrote: > > Hash lookup is done once per jsp page - when the jsp page is first run. > > After that, it's basically a synchronized push / pop pair on all subsequent > > runs of the page. In the future we can even get rid of the synch by using > > thread local sto

Re: Jasper performance/3.3 tag pooling

On Tue, 22 May 2001, Rickard Öberg wrote: > Hi! > > [EMAIL PROTECTED] wrote: > > Could you send a small page ( and the taglibs ) and the test conditions ? > > I have sent taglib+page and test conditions to Costin. Thanks, I'll try to add it to the tests dir. > > > We know the pool is synchro

Re: Jasper performance/3.3 tag pooling

Casey Lucas wrote: > Also, did you run the > tests with and without tag pooling enabled on the same version of > tomcat? (By adding removing TagPoolManagerInterceptor.) Yes. The only thing changed between the runs was the TPMI flag. > > This is a bad design. Basically, any gains you get from re

Re: Jasper performance/3.3 tag pooling

Hi! [EMAIL PROTECTED] wrote: > Could you send a small page ( and the taglibs ) and the test conditions ? I have sent taglib+page and test conditions to Costin. > We know the pool is synchronized and that may create problems under heavy > load, and we know how to fix this ( by using a per/thread

Re: Jasper performance/3.3 tag pooling

gain. See comments below. Rickard Öberg wrote: > > Hi! > > Ok, so now I've tested the Jasper performance with the 3.3 tag pooling > fix. The test was performed with a medium complexity page using lots of > iterative custom tags in a hierarchical fashion (i.e. tags within tag

Re: Jasper performance/3.3 tag pooling

to the VM where the allocation and GC will be free ( so far most do synchronize on object allocation ). Costin On Mon, 21 May 2001, Rickard Öberg wrote: > Hi! > > Ok, so now I've tested the Jasper performance with the 3.3 tag pooling > fix. The test was performed with a medium

Jasper performance/3.3 tag pooling

Hi! Ok, so now I've tested the Jasper performance with the 3.3 tag pooling fix. The test was performed with a medium complexity page using lots of iterative custom tags in a hierarchical fashion (i.e. tags within tags). Results: The page ran slower, and above all the response time v

RE: Jasper performance

> -Original Message- > From: Eduardo Pelegri-Llopart [mailto:[EMAIL PROTECTED]] > Sent: Saturday, May 19, 2001 12:01 AM > > (sorry for the response lag, unfortunatly I don't read tomcat very > frequently) > >... > > * Using XSTL for templating... > > Like Jon and some others, I think th

Re: Jasper performance - JMX

on 5/18/01 10:48 AM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > On Fri, 18 May 2001, Jon Stevens wrote: > >> Correct, however some bright monkey decided to add <% %> into the JSP >> specification. So, if you disable that, you are breaking the specification. >> In other words, it is a bad d

Re: Jasper performance - JMX

On Fri, 18 May 2001, Jon Stevens wrote: > Correct, however some bright monkey decided to add <% %> into the JSP > specification. So, if you disable that, you are breaking the specification. > In other words, it is a bad design in the first place. That is the point. Not using <% %> doesn't brake

Re: Jasper performance

on 5/18/01 4:55 PM, "Eduardo Pelegri-Llopart" <[EMAIL PROTECTED]> wrote: > Sorry, Jon, we disagree. TagLibraryValidators *are* part of the JSP 1.2 > specification. Go back and read what I wrote again. I'm not saying that TagLibraryValidators aren't part of the specification. > They are quite f

Re: Jasper performance

Sorry, Jon, we disagree. TagLibraryValidators *are* part of the JSP 1.2 specification. They are quite flexible and one of the simplest uses is to express that some tags cannot appear. Scriptlets are exposed as jsp:scriptlet tags. - eduard/o Jon Stevens wrote: > > on 5/18/01 3:01 PM,

Re: Jasper performance

on 5/18/01 3:01 PM, "Eduardo Pelegri-Llopart" <[EMAIL PROTECTED]> wrote: > I didn't see any follow-up clarifying this but apologies if I missed it. > > JSP 1.2 has the notion of a TagLibraryValidator that is associated with > a tag library. This can be used to portably validate different > asse

Re: Jasper performance

(sorry for the response lag, unfortunatly I don't read tomcat very frequently) Hi Jon. > The problem with taglibs is that there is no restriction on the > ability to put Java code in the page. It is part of the JSP > specification to be able to do that. Sure, you can disable it (as > Costin said

Re: Jasper performance - JMX

on 5/18/01 3:40 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > The key point is that you have to disable any user code in order to have > this to work. Only applications that do not use any user code ( beans, > servlets, utils ) will work. > > Same is true for almost any templating system

Re: Jasper performance - JMX

On Fri, 18 May 2001, Jon Stevens wrote: > on 5/18/01 1:04 AM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > > > I doubt too many installations of Velocity are set up to disallow user > > code - it's not too much you can do. It'll be secure - probably because > > nobody will care to use such a

Re: Jasper performance - JMX

on 5/18/01 1:04 AM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > I doubt too many installations of Velocity are set up to disallow user > code - it's not too much you can do. It'll be secure - probably because > nobody will care to use such a thing :-) And if you allow any user code - > all t

Re: Jasper performance

on 5/18/01 6:50 AM, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote: > Definitely. Agreed. There is no silver bullet. > > I guess the point is that you remove a little of the risk, as a designer > can't > > <% while(true); %> > > (although as JSP compilers get better, I am sure this stuff ca

Re: Jasper performance

on 5/18/01 1:37 AM, "Paulo Gaspar" <[EMAIL PROTECTED]> wrote: >> All Velocity has is a #foreach. This is a fully functional >> looping construct >> that prevents you from screwing things up and still gets the job done. > > On the #foreach and DoS issues, I would use "makes it harder" instead > o

RE: Jasper performance

: Friday, May 18, 2001 11:44 AM To: [EMAIL PROTECTED] Subject: RE: Jasper performance It isn't concurrent. -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]] Sent: Friday, May 18, 2001 10:52 AM To: [EMAIL PROTECTED] Subject: Re: Jasper performance Jef Newsom

RE: Jasper performance

It isn't concurrent. -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]] Sent: Friday, May 18, 2001 10:52 AM To: [EMAIL PROTECTED] Subject: Re: Jasper performance Jef Newsom wrote: > > Velocity does do a lot to minimize the risk you mention, but while we

Re: Jasper performance

--- > From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]] > Sent: Friday, May 18, 2001 8:50 AM > To: [EMAIL PROTECTED] > Subject: Re: Jasper performance > > Dennis Doubleday wrote: > > > > At 07:51 AM 5/18/01, Geir wrote: > > > > >Those aren't

RE: Jasper performance - JMX

> > BTW, I am not the first person talking about JMX in this list. > > JMX is great - I like it a lot, it can be added easily by a module - but I > don't think it's a big priority for now. After 3.3 is released we can > discuss new features as add-on modules ( I have a few ). > > Costin > On prio

RE: Jasper performance

lement($string.clone()); #end -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]] Sent: Friday, May 18, 2001 8:50 AM To: [EMAIL PROTECTED] Subject: Re: Jasper performance Dennis Doubleday wrote: > > At 07:51 AM 5/18/01, Geir wrote: > > >Those aren

RE: Jasper performance - JMX

On Fri, 18 May 2001, Paulo Gaspar wrote: > In the case of DoS, I don't believe a bit on "trusted tags" and such > stuff. Why monitoring the tags at all if "while(true)" is so easy. > > I mean, the front door is wide open, why care about that little > window? Well, what I said was "trusted tags"

Re: Jasper performance

Dennis Doubleday wrote: > > At 07:51 AM 5/18/01, Geir wrote: > > >Those aren't comparable, 'Velocity templates' and 'general purpose > >servlet container', because Velocity is just a template tool - you still > >need the servlet and servlet container. > > That was exactly my point when I said V

Re: Jasper performance

At 07:51 AM 5/18/01, Geir wrote: >Those aren't comparable, 'Velocity templates' and 'general purpose >servlet container', because Velocity is just a template tool - you still >need the servlet and servlet container. That was exactly my point when I said Velocity doesn't really do anything to pr

Re: Jasper performance

Glenn Nielsen wrote: > > Jon Stevens wrote: > > > There is no amount of security that will prevent someone from putting that > > into their JSP page other than disabling the ability to put scriptlets into > > things. If you do that, then you are simply where you should have been in > > the first

Re: Jasper performance

Jon Stevens wrote: > > on 5/17/01 12:47 PM, "Glenn Nielsen" <[EMAIL PROTECTED]> wrote: > > > But now that both Tomcat 3.2 and Tomcat 4 support the Java SecurityManager > > you can control security at the container level regardless of whether someone > > is using the CFM servlet, velocity, CoCoon

RE: Jasper performance - JMX

In the case of DoS, I don't believe a bit on "trusted tags" and such stuff. Why monitoring the tags at all if "while(true)" is so easy. I mean, the front door is wide open, why care about that little window? The only way to close everything is by monitoring the Servlets and allow setting some li

RE: Jasper performance

> All Velocity has is a #foreach. This is a fully functional > looping construct > that prevents you from screwing things up and still gets the job done. On the #foreach and DoS issues, I would use "makes it harder" instead of "prevents" in . But it also makes "much harder" to mix logic and p

RE: Jasper performance

Ok, I missed the end users. Chau, Gaston - Original Message - From: Jon Stevens <[EMAIL PROTECTED]> To: tomcat-dev <[EMAIL PROTECTED]> Sent: Thursday, May 17, 2001 1:26 PM Subject: Re: Jasper performance > on 5/17/01 8:01 AM, "[EMAIL PROTECTED]" <[EMAIL

Re: Jasper performance

On Thu, 17 May 2001, Glenn Nielsen wrote: > > I guess he's refering to DOS attacks ( like a while(true); in java code > > or allocating lots of memory ). > > You won't have much of a templating language if you don't allow some > sort of looping. Kind of hard to restrict that. True, but if you

Re: Jasper performance

on 5/17/01 2:41 PM, "Nick Bauman" <[EMAIL PROTECTED]> wrote: >> Yea, JSP protects you from "memory leaks" and "System Crashes". Yea >> Right. Oh yea, and ASP is "lacking" customizable tags...as if >> customizable tags is a good thing > > Jihad! > > If we're going to open that debate, then why u

Re: Jasper performance

on 5/17/01 5:21 PM, "Glenn Nielsen" <[EMAIL PROTECTED]> wrote: > You won't have much of a templating language if you don't allow some > sort of looping. Kind of hard to restrict that. All Velocity has is a #foreach. This is a fully functional looping construct that prevents you from screwing th

Re: Jasper performance

on 5/17/01 12:47 PM, "Glenn Nielsen" <[EMAIL PROTECTED]> wrote: > But now that both Tomcat 3.2 and Tomcat 4 support the Java SecurityManager > you can control security at the container level regardless of whether someone > is using the CFM servlet, velocity, CoCoon, JSP, etc. Not true.

Re: Jasper performance

[EMAIL PROTECTED] wrote: > > On Thu, 17 May 2001, Glenn Nielsen wrote: > > > > This is the approach that Tea uses as well as > > > the general idea behind taglibs. The problem with taglibs is that there is > > > no restriction on the ability to put Java code in the pa

Re: Jasper performance

On Thu, 17 May 2001, Glenn Nielsen wrote: > > This is the approach that Tea uses as well as > > the general idea behind taglibs. The problem with taglibs is that there is > > no restriction on the ability to put Java code in the page. It is part of > > the JSP specific

Re: Jasper performance

> Yea, JSP protects you from "memory leaks" and "System Crashes". Yea > Right. Oh yea, and ASP is "lacking" customizable tags...as if > customizable tags is a good thing Jihad! If we're going to open that debate, then why use Java at all? After all, the computer scientist will tell you with C/C+

Re: Jasper performance

"Geir Magnusson Jr." wrote: > > Christopher Kirk wrote: > > > > >From my view, the problem with JSP->Java->Class isn't performance its > > debugging. JSP is hard to work with when you make a mistake, very often the > > error message is less than helpful. A very large step in improving this is > >

Re: Jasper performance

Jon Stevens wrote: > > on 5/17/01 6:46 AM, "Dennis Doubleday" <[EMAIL PROTECTED]> wrote: > > > At 08:35 PM 5/16/01, Jon wrote: > > > >> Also, there is a reason for the #foreach... > >> > >> > > > > Jon, > > > > I agree with most of your

  1   2   >