Simon,

I updated the documentation, which is here:
http://www.eclipse.org/jetty/documentation/  I haven't updated the wiki for
jetty-7/8 as those versions are passing into history, although if I get a
spare minute I'll see what I can do.

BTW, you may want to get your product listed here in the Jetty Powered
pages: http://www.eclipse.org/jetty/powered/

Jan



On 31 May 2013 11:15, Simon Mills <[email protected]> wrote:

> Jan,
> thanks so much for your help.
> I used 'saveByteCode' because that is how it is written in the docs, at
> http://wiki.eclipse.org/Jetty/Howto/Configure_JSP
> The page also says "if the value you set doesn't take effect, try using
> all lower case instead of camel case", and I had tested "savebytecode" as
> well, but it did not occur to me to try a mix of lowercase and camelcase...
> Perhaps you could update the documentation so that others don't have the
> same problem?
>
> Also this as a general feedback - having .class files precompiled in the
> work dir is a big help performance wise, because when a server restarts for
> whatever reason it does not have to recompile everything again. When you
> have hundreds of jsps in a web app, it does make a difference. Our app also
> does an 'inside precompilation' at startup, by connecting to itself and
> loading each jsp. If no .class files are saved, at every restart it takes
> minutes of 100% cpu to recompile everything -  something that did not occur
> with Jetty 7. I know for sure that  other developers use the same method,
> as it's something I've seen in several blogs of JSP developers. And even if
> you don't do a precompilation, your first customer of the day will
> experience slow response times at every click.
>
> Was it ever considered the idea of leaving the default behavior that was
> in Jetty 7 in newer versions? I'm not sure how many end users realize that
> this is the new 'normal'.
>
> Anyway, just a personal feedback. Thanks for your prompt help, it saved my
> day.
>
>
> ------------------------------
> Date: Fri, 31 May 2013 10:14:24 +1000
> From: [email protected]
> To: [email protected]
> Subject: Re: [jetty-users] Jetty 9 : Jasper not saving .class files to
> work dir?
>
>
> Simon,
>
> Previous versions of jsp (eg in jetty-7) always used the JDT java
> compiler. That compiler always writes out the class files to disk. Jasper
> changed in version 2.2 to prefer the jvm's compiler, which does not write
> out the classes unless you explicitly set the init-param "saveBytecode" for
> the jsp servlet. Note the exact capitalization - your example posted
> "saveByteCode" with proper camel-case but that's not what they use :)
>
> Make sure when you're adding that init-param to the jsp servlet that if
> you edit $JETTY_HOME/etc/webdefault.xml that you need to ensure that file
> is applied to your webapp (by default it is not - the webdefault.xml inside
> the jetty-webapp jar is used instead) by calling setDefaultsDescriptor() on
> your context.
>
> regards
> Jan
>
>
>
> On 30 May 2013 19:38, Simon Mills <[email protected]> wrote:
>
> Hi All,
> after recently upgrading from Jetty 7 to Jetty 9, I noticed that in the
> scratch/work dir, Jasper no longer writes a .class file for each JSP that
> it compiles. It only writes the generated .java file.
> the JSPs work fine, but there seems to be no .class file written to the
> scratch/work dir. This used to occur in Jetty 7.
>
> To explain what I'm talking about:
> 1. I get latest Jetty 9 distribution (I used 9.0.3.v20130506)
> 2. I run it with "java -jar start.jar"
> 3. I open http://127.0.0.1:8080/test/jsp/dump.jsp in my browser, and see
> the JSP's correct output
> 4. somewhere in my temp directory (for me
> it's 
> C:\Users\simon\AppData\Local\Temp\jetty-0.0.0.0-8080-test.war-_test-any-\jsp\org\apache\jsp\jsp),
> I find the file dump_jsp.java being generated, but no .class
>
> The same occurs in Jetty 8.1.11: no .class file.
>
> If however I do the same test in Jetty 7 (7.1.6.v20100715 is the version I
> was using in the past), I see the file dump_jsp.class in the corresponding
> scratch dir for that server.
>
> For reference, I used JDK 1.7.0_21 64 bit for Windows in all tests.
>
> This is just with the plain distribution, without any change from me. I
> also tried editing the webdefault.xml in my own web app, adding/removing
> keepgenerated, saveByteCode, and other JspServlet init parameters, but
> all I could do was turn off the preservation of the .java file via
> keepgenerated. But I cannot get to see the .class file saved to disk
> anywhere.
>
> I also thought this could be a compilation error (hence the reason why the
> .java file is still around), but it doesn't make much sense, because I can
> see the correct output of the jsp in the browser... and there are no error
> messages in the server's console either.
>
> Is there a reason for this? How does this affect response times when
> restarting the server? Does Jetty/Jasper have to recompile that .java file
> every time the server is restarted? Or, worse, every time the jsp is
> accessed?
>
> If this is covered somewhere in the documentation or faq, please forgive
> me for not finding it. I searched around for half a day but could not find
> any mention of this anywhere.
>
>
>
>
>
>
> _______________________________________________
> jetty-users mailing list
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/jetty-users
>
>
>
>
> --
> Jan Bartel <[email protected]>
> www.webtide.com – Developer advice, services and support
> from the Jetty & CometD experts.
>
> _______________________________________________ jetty-users mailing list
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/jetty-users
>
> _______________________________________________
> jetty-users mailing list
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/jetty-users
>
>


-- 
Jan Bartel <[email protected]>
www.webtide.com – Developer advice, services and support
from the Jetty & CometD experts.
_______________________________________________
jetty-users mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/jetty-users

Reply via email to