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

Rickard, 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 / ob

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 > > read. > > I'm working on a refactoring of

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 to > read. I'm working on a refactor

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

Rickard Öberg wrote: > > [EMAIL PROTECTED] wrote: > > > > 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 pool without > > > > synchronization ). > > > > > > That is one solution, but what do you do with t

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

[EMAIL PROTECTED] wrote: > > > 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 pool without > > > synchronization ). > > > > That is one solution, but what do you do with the pool after page > > request? > >

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

Rickard, Can you please send in some complete examples? Also, did you run the tests with and without tag pooling enabled on the same version of tomcat? (By adding removing TagPoolManagerInterceptor.) My experience has been that if the jsp uses many tags, then pooling is a big performance gain

Re: Jasper performance/3.3 tag pooling

Hi Rickard, Could you send a small page ( and the taglibs ) and the test conditions ? Most tests I run show a (significant) improvement in performance. 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 pool witho

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

Re: Jasper performance

: Carlos Gaston Alvarez [mailto:[EMAIL PROTECTED]] > > Sent: 17 May 2001 12:51 > > To: [EMAIL PROTECTED] > > Subject: RE: Jasper performance > > > > > > I dont know if I really understood. You (some) are > > thinking to compile a > > jsp using xslt

Re: Jasper performance

On Thu, 17 May 2001, Geir Magnusson Jr. wrote: > Really? I was told that it was a complete myth - that *no one* has to > debug the Java code - they just debug the JSP code. My JSP experience > occurred a few years agoe, and I remember bewildering error messages - > however, I just assumed that

RE: Jasper performance

to wait a bit for the implementation - I'm still fighting > > with cleaning and merging the runtime. > > > > Costin > > > > > > > > > > > > > > > > - Chris. > > > > > > > -Original Message- >

RE: Jasper performance

On Thu, 17 May 2001, Craig R. McClanahan wrote: > > > On Thu, 17 May 2001 [EMAIL PROTECTED] wrote: > > > > > There is another solution - to generate the map ( java line number -> > > JSP source line number). This is exactly how the .class annotation works, > > mapping bytecode to java source n

RE: Jasper performance

y is not the case because of the intermediate > >step of a java file. It would be beneficial to compile JSP > straight to Java, > >complete with debugging information included in the class file. > > > >- Chris. > > > > > -----Original Message- > > > Fr

RE: Jasper performance

On Thu, 17 May 2001, Paulo Gaspar wrote: > > ... > > XSLT is not perfect - neither is HTTP or HTML or any other standard. But > > because Apache and many other organizations are implementing and using it > > - I think they'll be around for a while :-) > > > > Costin > > Costin, > > You are

Re: Jasper performance

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 > by making the line number given by the st

Re: Jasper performance

on 5/17/01 12:23 AM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > On Thu, 17 May 2001, 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 le

Re: Jasper performance

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 points. I am a new Velocity user and I

Re: Jasper performance

on 5/17/01 8:01 AM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > Ok Chris. Now I undertand. > Working with JSP when I found that type of mistakes I went to see the .java > generated. There I matched the line number so I could see which was the bad > code. Then I had to go to the jsp to fix it

RE: Jasper performance

On Thu, 17 May 2001 [EMAIL PROTECTED] wrote: > > There is another solution - to generate the map ( java line number -> > JSP source line number). This is exactly how the .class annotation works, > mapping bytecode to java source number. And will allow you to see both > informations, and it's qu

RE: Jasper performance

x27;s quite clean. > > I'm not an expert in debugging, but that sound like a reasonable solution. > You'll have to wait a bit for the implementation - I'm still fighting > with cleaning and merging the runtime. > > Costin > > > > > &g

RE: Jasper performance

Hi Carlos, On Thu, 17 May 2001, Carlos Gaston Alvarez wrote: > I dont know if I really understood. You (some) are thinking to compile a > jsp using xslt. I didnt know that that was possible. I mean, can a jsp be > loaded as a dom object? I think that it cannot because a nice guy can write >

RE: Jasper performance

z [mailto:[EMAIL PROTECTED]] > > Sent: 17 May 2001 12:51 > > To: [EMAIL PROTECTED] > > Subject: RE: Jasper performance > > > > > > I dont know if I really understood. You (some) are > > thinking to compile a > > jsp using xslt. I didnt know that t

RE: Jasper performance

[EMAIL PROTECTED] > Subject: RE: Jasper performance > > > I agree with you, So I'll suggest you Forte IE, which has a great > debugger. > that allow you to trace exception form the stack to the class, > then to the > original source code. > > It also allow b

RE: Jasper performance

Answer inline: > -Original Message- > From: Christopher Kirk [mailto:[EMAIL PROTECTED]] > Sent: Thursday, May 17, 2001 3:17 PM > > >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

RE: Jasper performance

;ll have to wait a bit for the implementation - I'm still fighting with cleaning and merging the runtime. Costin > > - Chris. > > > -Original Message- > > From: Carlos Gaston Alvarez [mailto:[EMAIL PROTECTED]] > > Sent: 17 May 2001 12:51 > > To: [E

RE: Jasper performance

answer inline... > -Original Message- > From: Carlos Gaston Alvarez [mailto:[EMAIL PROTECTED]] > Sent: Thursday, May 17, 2001 1:51 PM > > I don't know if I really understood. You (some) are thinking > to compile a > jsp using xslt. I didnt know that that was possible. I mean, can a js

RE: Jasper performance

te with debugging information included in the class file. > >- Chris. > > > -Original Message- > > From: Carlos Gaston Alvarez [mailto:[EMAIL PROTECTED]] > > Sent: 17 May 2001 12:51 > > To: [EMAIL PROTECTED] > > Subject: RE: Jasper performance > >

Re: Jasper performance

At 08:35 PM 5/16/01, Jon wrote: >Also, there is a reason for the #foreach... > > Jon, I agree with most of your points. I am a new Velocity user and I am very impressed by its combination of power and simplicity. Reading/writing XSLT

RE: Jasper performance

ston Alvarez [mailto:[EMAIL PROTECTED]] > Sent: 17 May 2001 12:51 > To: [EMAIL PROTECTED] > Subject: RE: Jasper performance > > > I dont know if I really understood. You (some) are > thinking to compile a > jsp using xslt. I didnt know that that was possible. I mean, >

RE: Jasper performance

I dont know if I really understood. You (some) are thinking to compile a jsp using xslt. I didnt know that that was possible. I mean, can a jsp be loaded as a dom object? I think that it cannot because a nice guy can write some code like <% out.writeln(""); %> and that is, it is not more xml c

RE: Jasper performance

> ... > XSLT is not perfect - neither is HTTP or HTML or any other standard. But > because Apache and many other organizations are implementing and using it > - I think they'll be around for a while :-) > > Costin Costin, You are still missing the point (as I wrote in my previous post on t

Re: Jasper performance

on 5/16/01 7:06 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > On Wed, 16 May 2001, Jon Stevens wrote: > >> on 5/16/01 4:02 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: >> >>> Yet another template generation language ??? #foreach ??? >> >> Costin, what rock have you been sleeping u

Re: Jasper performance

On Wed, 16 May 2001, Jon Stevens wrote: > "may"? Do you have empirical evidence of that or did you pull that out of > your ass? I guess that concludes our discussion. Costin > > >, and may > > end up saving the javac in some cases - which would be a significant speed > > improvement. >

Re: Jasper performance

On Wed, 16 May 2001, Jon Stevens wrote: > on 5/16/01 4:02 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > > > Yet another template generation language ??? #foreach ??? > > Costin, what rock have you been sleeping under for the last 5 years? > Velocity is simply a cleaner implementation of

Re: Jasper performance

on 5/16/01 3:28 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > And I tried to explain: the xslt transformation is not significant > compared with the javac compilation ( it may add 5-10% extra ) "may"? Do you have empirical evidence of that or did you pull that out of your ass? >, and ma

Re: Jasper performance

on 5/16/01 4:02 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > Yet another template generation language ??? #foreach ??? Costin, what rock have you been sleeping under for the last 5 years? Velocity is simply a cleaner implementation of WebMacro. It isn't "YATGL". Also, there is a reason

Re: Jasper performance

On Wed, 16 May 2001, Jon Stevens wrote: > p.s. Over in Turbine land, we have a lot of experience with the dynamic > generation of Java code and have found that using Texen has been a most > favorable experience. It would be most humorous to me to see Velocity used > to generate .java files from .

Re: Jasper performance

On Wed, 16 May 2001, Jon Stevens wrote: > Costin, > > Once again, you impress me with your inability to understand a word of what > I'm talking about. So, let me close this discussion with this: No problem, I'm not that good at explaining either. > If the speed of generating a .java file (or

Re: Jasper performance

on 5/16/01 1:11 AM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > The code generation stage is not significant - compared with the javac > compilation. Some people are even using XSLT at runtime ( not that this is > a good idea ) - so I doubt it'll have such a significant impact on > developme

Re: Jasper performance

On Tue, 15 May 2001, Jon Stevens wrote: > Currently Jasper output's Java code from within Java code. This is about as > fast as you are going to get because there is no intermediate transformation > step going on, just conditional output of String data entirely within Java. > While this is very f

RE: Jasper performance

> Now, people are suggesting using something like XSLT to transform the .jsp > XML/XHTML file into a .java file. Because you are introducing the > XSLT layer > into things, that will have a negative impact on the transformation > performance (I'm not certain how much, but I am pretty much > certai

RE: Jasper performance

; To: [EMAIL PROTECTED] > Subject: Re: Jasper performance > > > I would like to propose that the new Jasper require jdk 1.2. > The current version of jasper can be used by those who have jdk 1.1.x. > Then we don't have to worry about jumping through hoops trying to > get

RE: Jasper performance

ps: I am adding also usage options. - Original Message - From: Glenn Nielsen <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, May 15, 2001 6:49 AM Subject: Re: Jasper performance > Jasper performance has already been identified as an area needing > improvemen

RE: Jasper performance

Have you said a Meg of html !!! Those are the test cases I need. Chau, Gaston - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, May 15, 2001 12:41 PM Subject: Re: Jasper performance We use Jasper (from a 3.1 build!) in another contai

Re: Jasper performance

on 5/15/01 8:32 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: >>> +1 for the generator. >> >> Considerations on the generator: >> >> This will slow development down even further doing the transformation step. > > What ? Using JDK1.2 instead of JDK1.1 ? > > I doubt it, but thanks for worr

Re: Jasper performance

On Tue, 15 May 2001, Jon Stevens wrote: > on 5/15/01 7:05 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > > > On Tue, 15 May 2001, Glenn Nielsen wrote: > > > >> I would like to propose that the new Jasper require jdk 1.2. > >> The current version of jasper can be used by those who have jdk

Re: Jasper performance

on 5/15/01 7:05 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > On Tue, 15 May 2001, Glenn Nielsen wrote: > >> I would like to propose that the new Jasper require jdk 1.2. >> The current version of jasper can be used by those who have jdk 1.1.x. >> Then we don't have to worry about jumping

Re: Jasper performance

On Tue, 15 May 2001, Glenn Nielsen wrote: > I would like to propose that the new Jasper require jdk 1.2. > The current version of jasper can be used by those who have jdk 1.1.x. > Then we don't have to worry about jumping through hoops trying to > get the new jasper to run both in 1.1 and 1.2, pl

Re: Jasper performance

on 5/15/01 2:05 PM, "Rickard Öberg" <[EMAIL PROTECTED]> wrote: > Somehow I'm not surprised by this comment ;-) Well, if you know you have something better than JSP, then why not help educate people about it? I'm not forcing it down your throat, I'm just telling you that we have an alternative so

  1   2   >