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 less than helpful. A very large step in improving this is
> by making the line number given by the stack trace match the line numbers of
> the JSP page. This currently 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.
Yes, debugging is a problem in the current jasper implementation. One
solution, as you mentioned, is to "hack" the class to include line numbers
that match the JSP file ( the line number is an annotation in the class ).
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 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
>
> - Chris.
>
> > -----Original Message-----
> > From: 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. 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("</html>"); %> and that is, it
> > is not more xml
> > compliant. (please tellme if I am wrong).
> > If the problem is the compilation time I can hardly
> > believe that we can
> > do something faster that a java compiler. Not because we dont have the
> > skill, but because there are groups working in this kind of
> > implementations.
> > We should be blindly proud to think out compiler would be faster than
> > theirs. Also, I consider that a waste of time.
> > Let me do some guessing. I know, I should be reading the
> > code, but I
> > have been realy overloaded for the last months. Lets see if I have
> > understood the problem.
> > Saving a file for compilation is slow. So we need a
> > faster solution.
> > But, why is it slow?
> > It sounds like we are saving the .java in file and then invoking a
> > javacc process. The new process needs loads the compiler
> > classes, compiles
> > them (?) and then compiles our .java source.
> > If we could have the compiler just loaded on our own
> > memory space, we
> > could invoke it saving the loading compiling (?) time. We
> > could also send
> > the .java 'file' in memory and expect the .class 'file' also
> > in memory.
> > Yes, may be we need some modifications in the compiler,
> > but as part of
> > the apache project we are at a good position for asking it an
> > having a good
> > answer.
> >
> > Chau,
> >
> > Gaston
> >
> > ps: sorry for doing so much guessing but next month I will
> > have much more
> > time.
> > ps
> >
>
>
> -----------------------------------------------------------------
> This e-mail is intended only for the addressee(s) named above. It
> may contain confidential or privileged information and if you are
> not the intended addressee you are not authorized to disclose,
> copy, distribute or place any reliance on it whatsoever and we
> request that you inform our postmaster ([EMAIL PROTECTED]) that
> you have received this e-mail. Any attachment(s) to this message
> has been checked for viruses, but please rely on your own virus
> checker and procedures. If you contact us by e-mail, we will
> store your name and address to facilitate communications.
> -----------------------------------------------------------------
>
