| Re: [jetty-dev] [jetty-users] JSP pages are recompiled at runtime |
If you have use the maven jspc plugin, then you should have a web.xml file that contains <servlet> definitions for each jsp page. Is that the case or not?JanOn 14 September 2017 at 10:25, upendar devu <devulapalli8@xxxxxxxxx> wrote:I meant to say removing scratch dir means removing the below of line of code as mentioned in one my previous emails.Later I started using the tern removal of scratch dir.context.setAttribute("javax.servlet.context.tempdir", getScratchDir()); The below summary would help you. Please let me know if you find any.Case 1 :Development =falsecontext.setAttribute("javax.servlet.context.tempdir", getScratchDir()); Case 1Results:1. JSPs are getting recompiled into the specified scratch dir i.e /tmp/embedded-jetty-jsp as this folder has .class files.2. Lower envs - All jsps are recompiled and no errors are seen; Example if the application has 100 jsp pages then we seen 100.class files3. Production env - Only few recompiled JSP pages are seen in /tmp/embedded-jetty-jsp Example if the application has 100 jsp pages then we seen 4 .class files and caused errors - see entire stack trace listed in my first email thread. Struggling to find the root cause why only few jsp pages are recompiled.Case 2 :Development =false//Removed this line of code//context.setAttribute("javax.servlet.context.tempdir", getScratchDir()); Case 2 Results:1. Created a directory under /tmp folder with name as jetty-0.0.0.0-9011-applicatioName-_xx-any-430151829451406 2102.dir with 0 files under it. this proved jsp pages are not getting recompiled since no .class files are found under /tmp 2. no issues are encountered . Yet to take call to move the changes to prodOn Wed, Sep 13, 2017 at 7:37 PM, Jan Bartel <janb@xxxxxxxxxxx> wrote:You're confusing 2 separate but related things: the javax.servlet.context.tempdir, and the jsp engine scratch dir. The former is the place where the webapp will be unpacked to if necessary, and the jsp engine scratch dir is the location to which jsps will be compiled. Jetty tells the jsp engine that the scratch dir to use is the javax.servlet.context.tempdir/jsp. So if you set javax.servlet.context.tempdir= /tmp/embedded-jetty-jsp the scratchdir will be /tmp/embedded-jetty-jsp/jsp. If you don't set the javax.servlet.context.tempdir it defaults to java.io.tmpdir, which on *nix systems is "/tmp", so the scratch dir would be /tmp/jsp. Again, if you are correctly using the jspc maven plugin to generate classes from your jsps, and also populate web.xml with appropriate <servlet>s, then jsp-on-the fly compilation never happens because the JspServlet is never hit. If you are seeing any on-the-fly compilation at all, then you have not populated web.xml correctly.JanOn 14 September 2017 at 09:16, upendar devu <devulapalli8@xxxxxxxxx> wrote:After removing scratch dir I don't see jsps getting recompiled since embded-jetty-jsp dir not found in tmp location and not even in entire system. Conclusion is removing scratch dir helping resolve the recompilation issue. What I wanted to know is when scratch dir is enabled why only few jsps are recompiled that caused io exception and no class def errors ..On Sep 13, 2017 7:09 PM, "Joakim Erdfelt" <joakim@xxxxxxxxxxx> wrote:"no recompilation jsps seen"... doesn't mean its not still happening (just somewhere else on your filesystem).Enable the debug logging and you'll see that scratchDir still exists, just not configured in a place you expect.You'll also see events in the debug logs for when it recompiles.Joakim Erdfelt / joakim@xxxxxxxxxxxOn Wed, Sep 13, 2017 at 3:50 PM, upendar devu <devulapalli8@xxxxxxxxx> wrote:We are using jetty jspc maven plugin since jetty version 8; migration to jetty 9.4.6 team added scratch dir code.however no issues seen in lower env as all jsp pages are recompiled into tmp location. But only few pages are recompiled that caused errors listed in my email thread.now removed scratch dir code and no recompilation jsps seen.we added more logs but couldn't find why few pages are recompiled in prod env.Thank youOn Sep 13, 2017 6:43 PM, "Jan Bartel" <janb@xxxxxxxxxxx> wrote:The recommended way to deploy for a production environment is to precompile jsps and place <servlet> definitions for them into web.xml. You can use a tool like the jetty-jspc-maven-plugin to do that for you: see https://www.eclipse.org/jetty/documentation/current/jett . You could also use an ant task to do the compilation, see https://tomcat.apache.org/y-jspc-maven-plugin.html tomcat-8.5-doc/jasper-howto.ht . This way, page accesses are fast as there is no on-the-fly compilation and thus no need for a full jdk on the production machine.ml#Production_Configuration When NOT using precompiled jsps defined as <servlets>, when a jsp page is requested, the jsp engine uses the scratch dir to look for a class matching the jsp. It does so iff development==true or the page is being requested for the first time. The page will be (re)compiled iff: the class does not exist, or the modification date on the jsp page is more recent than the date on the class file.As Joakim suggests, you should try and produce more debug logs to determine the difference between your test and production environments. But ideally, you would instead use the proper pre-compilation procedure for your production environment.JanOn 14 September 2017 at 07:56, upendar devu <devulapalli8@xxxxxxxxx> wrote:I'm sure that we didn't get any errors removing scratch dir.On Sep 13, 2017 5:39 PM, "Joakim Erdfelt" <joakim@xxxxxxxxxxx> wrote:Removing that scratchdir attribute just moves the jsp compilation to system temp (aka java.io.tmpdir)Its a requirement for JSP, you cannot run without a scratch directory.In fact, you'll get startup errors if the scratch directory is bad/invalid.Eg:The JSP engine is not configured with a scratch dir. \nPlease add \"jsp.initparams=scratchdir=<dir-name>\" \n in the servlets.properties file for this context.orThe scratchDir you specified: {0} is unusable.I believe that to use precompiled JSPs you have to put the precompiled versions into your ServletContextHandler as servlets.Jan, do you concur?Joakim Erdfelt / joakim@xxxxxxxxxxxOn Wed, Sep 13, 2017 at 2:18 PM, upendar devu <devulapalli8@xxxxxxxxx> wrote:We removed below line of code then we dont see the folder embedded-jetty-jsp getting created . I believe server using the pre compiled jsp pages as I dont locate the JSPs recompiling.context.setAttribute("javax.servlet.context.tempdir", getScratchDir()); On Wed, Sep 13, 2017 at 5:16 PM, Joakim Erdfelt <joakim@xxxxxxxxxxx> wrote:I would have expected each compiled JSP to be added as a Servlet to the ServletContextHandler via the .addServlet() call.Joakim Erdfelt / joakim@xxxxxxxxxxxOn Wed, Sep 13, 2017 at 2:10 PM, upendar devu <devulapalli8@xxxxxxxxx> wrote:Thanks for quick response. I dont think we followed the example code you followed but little lines of code might match .Attached code snippet what we are using. Please refer the code.I think below line of code does .WebAppContext.setBaseResource(new ResourceCollection(validPaths. toArray(new String[0])));. i.eWebAppContext.setBaseResource(new ResourceCollection("src/main/w ebapp", "src/main/resources", "src/main", "webapp", "."); On Wed, Sep 13, 2017 at 4:45 PM, Joakim Erdfelt <joakim@xxxxxxxxxxx> wrote:The fact that you mention /tmp/embedded-jetty-jsp hints that you are using the example code fromIs this true?If so, can you describe how you are adding your pre-compiled JSPs to the ServletContextHandler?Joakim Erdfelt / joakim@xxxxxxxxxxxOn Wed, Sep 13, 2017 at 1:24 PM, upendar devu <devulapalli8@xxxxxxxxx> wrote:We recently upgraded from Jetty version 8 to 9.4.6 ; The embedded Jetty server recompiling the JSP pages and creating a folder /tmp/embedded-jetty-jsp despite the configuration attribute Development is set to false. In my lower env - the folder embedded-jetty-jsp is getting created and we see all the recompiled JSP pages .in Production env - the folder embedded-jetty-jsp is getting created and we see ONLY few of the JSP pages are getting recompiled . Due to this we are getting below error on clicking the page in the portal - the page associated to jSP is recompiled in that tmp folder.We need your help to find the rootcause and fix for this issue.Error :07 Sep 2017 16:26:28,153 [qtp1043351526-50615] ERROR biz.xxxx.xxxx.common.struts.ExceptionInterceptor (intercept:31) - JSPException including path '/pages/theme/xxxx.jsp'. org.apache.tiles.request.rende r.CannotRenderException: JSPException including path '/pages/theme/xxxx.jsp'. at org.apache.tiles.impl.BasicTil esContainer.render(BasicTilesC ontainer.java:399) at org.apache.tiles.impl.BasicTil esContainer.render(BasicTilesC ontainer.java:238) at org.apache.tiles.TilesContaine rWrapper.render(TilesContainer Wrapper.java:103) at org.apache.tiles.impl.mgmt.Cac hingTilesContainer.render(Cach ingTilesContainer.java:126) at org.apache.struts2.views.tiles .TilesResult.doExecute(TilesRe sult.java:161) at org.apache.struts2.result.Stru tsResultSupport.execute(Struts ResultSupport.java:208) at com.opensymphony.xwork2.Defaul tActionInvocation.executeResul t(DefaultActionInvocation.java :373) at com.opensymphony.xwork2.Defaul tActionInvocation.invoke(Defau ltActionInvocation.java:277) at com.opensymphony.xwork2.interc eptor.annotations.AnnotationWo rkflowInterceptor.intercept(An notationWorkflowInterceptor.ja va:133) at com.opensymphony.xwork2.Defaul tActionInvocation.invoke(Defau ltActionInvocation.java:247) at com.opensymphony.xwork2.interc eptor.ConversionErrorIntercept or.doIntercept(ConversionError Interceptor.java:139) at com.opensymphony.xwork2.interc eptor.MethodFilterInterceptor. intercept(MethodFilterIntercep tor.java:98) at com.opensymphony.xwork2.Defaul tActionInvocation.invoke(Defau ltActionInvocation.java:247) at com.opensymphony.xwork2.interc eptor.ParametersInterceptor.do Intercept(ParametersIntercepto r.java:133) at com.opensymphony.xwork2.interc eptor.MethodFilterInterceptor. intercept(MethodFilterIntercep tor.java:98) at com.opensymphony.xwork2.Defaul tActionInvocation.invoke(Defau ltActionInvocation.java:247) at org.apache.struts2.interceptor .CheckboxInterceptor.intercept (CheckboxInterceptor.java:88) at com.opensymphony.xwork2.Defaul tActionInvocation.invoke(Defau ltActionInvocation.java:247) at com.opensymphony.xwork2.interc eptor.PrepareInterceptor.doInt ercept(PrepareInterceptor.java :174) at com.opensymphony.xwork2.interc eptor.MethodFilterInterceptor. intercept(MethodFilterIntercep tor.java:98) at com.opensymphony.xwork2.Defaul tActionInvocation.invoke(Defau ltActionInvocation.java:247) at org.apache.struts2.interceptor .ServletConfigInterceptor.inte rcept(ServletConfigInterceptor .java:171) at com.opensymphony.xwork2.Defaul tActionInvocation.invoke(Defau ltActionInvocation.java:247) at biz.xxxx.xxxx.common.struts.Pr eBindInterceptor.intercept(Pre BindInterceptor.java:19) at com.opensymphony.xwork2.Defaul tActionInvocation.invoke(Defau ltActionInvocation.java:247) at biz.xxxx.xxxx.core.web.interce ptor.LiteResultInterceptor.int ercept(LiteResultInterceptor.j ava:51) at com.opensymphony.xwork2.Defaul tActionInvocation.invoke(Defau ltActionInvocation.java:247) at biz.xxxx.xxxx.core.web.interce ptor.FragmentInterceptor.inter cept(FragmentInterceptor.java: 35) at com.opensymphony.xwork2.Defaul tActionInvocation.invoke(Defau ltActionInvocation.java:247) at org.apache.struts2.interceptor .FileUploadInterceptor.interce pt(FileUploadInterceptor.java: 246) at com.opensymphony.xwork2.Defaul tActionInvocation.invoke(Defau ltActionInvocation.java:247) at biz.xxxx.xxxx.common.struts.No CacheInterceptor.intercept(NoC acheInterceptor.java:39) at com.opensymphony.xwork2.Defaul tActionInvocation.invoke(Defau ltActionInvocation.java:247) at biz.xxxx.xxxx.core.web.interce ptor.SecurityInterceptor.inter cept(SecurityInterceptor.java: 70) at com.opensymphony.xwork2.Defaul tActionInvocation.invoke(Defau ltActionInvocation.java:247) at biz.xxxx.xxxx.common.struts.Ex ceptionInterceptor.intercept(E xceptionInterceptor.java:23) at com.opensymphony.xwork2.Defaul tActionInvocation.invoke(Defau ltActionInvocation.java:247) at org.apache.struts2.factory.Str utsActionProxy.execute(StrutsA ctionProxy.java:54) at org.apache.struts2.dispatcher. Dispatcher.serviceAction(Dispa tcher.java:564) at org.apache.struts2.dispatcher. ExecuteOperations.executeActio n(ExecuteOperations.java:81) at org.apache.struts2.dispatcher. filter.StrutsPrepareAndExecute Filter.doFilter(StrutsPrepareA ndExecuteFilter.java:143) at org.eclipse.jetty.servlet.Serv letHandler$CachedChain.doFilte r(ServletHandler.java:1637) at biz.xxxx.xxxx.common.filter.Ba seFilter$WrappedFilterChain.do Filter(BaseFilter.java:108) at biz.xxxx.xxxx.common.filter.Ba seFilter.doFilter(BaseFilter.j ava:64) at org.eclipse.jetty.servlet.Serv letHandler$CachedChain.doFilte r(ServletHandler.java:1637) at biz.xxxx.xxxx.common.filter.Ba seFilter$WrappedFilterChain.do Filter(BaseFilter.java:108) at biz.xxxx.xxxx.common.filter.Re sponseUrlFilter.onDynamic(Resp onseUrlFilter.java:14) at biz.xxxx.xxxx.common.filter.Ba seFilter.doFilter(BaseFilter.j ava:49) at org.eclipse.jetty.servlet.Serv letHandler$CachedChain.doFilte r(ServletHandler.java:1637) at biz.xxxx.xxxx.common.filter.Ba seFilter$WrappedFilterChain.do Filter(BaseFilter.java:108) at biz.xxxx.xxxx.common.filter.Pe rformanceFilter.onDynamic(Perf ormanceFilter.java:17) at biz.xxxx.xxxx.common.filter.Ba seFilter.doFilter(BaseFilter.j ava:49) at org.eclipse.jetty.servlet.Serv letHandler$CachedChain.doFilte r(ServletHandler.java:1637) at biz.xxxx.xxxx.common.filter.Ba seFilter$WrappedFilterChain.do Filter(BaseFilter.java:108) at biz.xxxx.xxxx.common.filter.Se curityContextFilter.onDynamic( SecurityContextFilter.java:18) at biz.xxxx.xxxx.common.filter.Ba seFilter.doFilter(BaseFilter.j ava:49) at org.eclipse.jetty.servlet.Serv letHandler$CachedChain.doFilte r(ServletHandler.java:1637) at org.eclipse.jetty.servlet.Serv letHandler.doHandle(ServletHan dler.java:533) at org.eclipse.jetty.server.handl er.ScopedHandler.handle(Scoped Handler.java:143) at org.eclipse.jetty.security.Sec urityHandler.handle(SecurityHa ndler.java:548) at org.eclipse.jetty.server.handl er.HandlerWrapper.handle(Handl erWrapper.java:132) at org.eclipse.jetty.server.handl er.ScopedHandler.nextHandle(Sc opedHandler.java:190) at org.eclipse.jetty.server.sessi on.SessionHandler.doHandle(Ses sionHandler.java:1595) at org.eclipse.jetty.server.handl er.ScopedHandler.nextHandle(Sc opedHandler.java:188) at org.eclipse.jetty.server.handl er.ContextHandler.doHandle(Con textHandler.java:1253) at org.eclipse.jetty.server.handl er.ScopedHandler.nextScope(Sco pedHandler.java:168) at org.eclipse.jetty.servlet.Serv letHandler.doScope(ServletHand ler.java:473) at org.eclipse.jetty.server.sessi on.SessionHandler.doScope(Sess ionHandler.java:1564) at org.eclipse.jetty.server.handl er.ScopedHandler.nextScope(Sco pedHandler.java:166) at org.eclipse.jetty.server.handl er.ContextHandler.doScope(Cont extHandler.java:1155) at org.eclipse.jetty.server.handl er.ScopedHandler.handle(Scoped Handler.java:141) at org.eclipse.jetty.server.handl er.HandlerCollection.handle(Ha ndlerCollection.java:126) at org.eclipse.jetty.server.handl er.HandlerWrapper.handle(Handl erWrapper.java:132) at org.eclipse.jetty.server.Serve r.handle(Server.java:564) at org.eclipse.jetty.server.HttpC hannel.handle(HttpChannel.java :317) at org.eclipse.jetty.server.HttpC onnection.onFillable(HttpConne ction.java:251) at org.eclipse.jetty.io.AbstractC onnection$ReadCallback.succeed ed(AbstractConnection.java:279 ) at org.eclipse.jetty.io.FillInter est.fillable(FillInterest.java :110) at org.eclipse.jetty.io.ChannelEn dPoint$2.run(ChannelEndPoint.j ava:124) at org.eclipse.jetty.util.thread. Invocable.invokePreferred(Invo cable.java:128) at org.eclipse.jetty.util.thread. Invocable$InvocableExecutor.in voke(Invocable.java:222) at org.eclipse.jetty.util.thread. strategy.EatWhatYouKill.doProd uce(EatWhatYouKill.java:294) at org.eclipse.jetty.util.thread. strategy.EatWhatYouKill.run(Ea tWhatYouKill.java:199) at org.eclipse.jetty.util.thread. QueuedThreadPool.runJob(Queued ThreadPool.java:672) at org.eclipse.jetty.util.thread.