On 20 Nov 2012, at 21:44, Jim <open...@gmail.com> wrote: >> What I'm getting at is this: your release process should produce a >> .war (or exploded directory) that is copied to Tomcat and that Tomcat >> should not be reading any part of the app from the /war directory - a >> source controlled directory. > Right: we produce an exploded directory which is then copied to Tomcat. The > exploded "/war" directory in our project is copied into > "$CATALINA_HOME/webapps/[name of app]". All of Tomcat, including the "/work" > and "/webapps" directories, is separate from our source-controlled project. > > To clarify one thing: the JSPs /are/ being compiled, and recompiled. I will > see the classfile for the JSP/tag appear in Tomcat's "/work" directory, but > Tomcat claims it can't find it. If I remove the ".class" file in the "/work" > directory, and re-visit the JSP, Tomcat will re-compile the .class file, but > the page will still fail to load with the same error about not being able to > "resolve" the class. That latter behavior makes me think that Git/timestamps > are a red herring; my problem seems to be that the compilation occurs > correctly, but that the classes are sometimes not loaded into the > classloader. Also, when this error happens, restarting Tomcat -- without > changing the contents of "/webapp/[name of app]" at all -- resolves the > issue, which hints at some sort of classloading race condition. > > -- Jim > > On 11/20/12 3:40 PM, Pid * wrote: >> On 20 Nov 2012, at 19:44, Jim <open...@gmail.com> wrote: >> >>> No -- the /war/WEB-INF/classes directory is .gitignored, and empty until we >>> deploy, at which point we copy in the compiled .java files, etc. >>> >>> I suppose my core question is: if >>> "$CATALINA_HOME/work/Catalina/localhost/_/org/apache/jsp/tag/web/about_tag.class" >>> exists, what situations could cause Tomcat to give the following error: >>> >>> An error occurred at line: 1 in the jsp file: >>> /WEB-INF/jsp/about/about_impact.jsp >>> org.apache.jsp.tag.web.about_tag cannot be resolved to a type >>> 1: <%@ include file="../common/constants.jsp" %><templates:about> >>> >>> If I delete >>> "$CATALINA_HOME/work/Catalina/localhost/_/org/apache/jsp/tag/web/about_tag.class", >>> and re-visit "/WEB-INF/jsp/about/about_impact.jsp", >>> "$CATALINA_HOME/work/Catalina/localhost/_/org/apache/jsp/tag/web/about_tag.class" >>> gets re-created, but I still get the above error. >>> >>> So, Tomcat appears to be compiling the JSP fine, but that compiled JSP does >>> not appear to be making it into the classloader? >>> >>> -- Jim >>> >>> >>> On 11/20/12 2:34 PM, Pid * wrote: >>>> On 20 Nov 2012, at 13:42, Jim <open...@gmail.com> wrote: >>>> >>>>> Thanks for the question -- I worded that part awkwardly. >>>>> >>>>> Our project has a root-level "/src" directory with the web app's Java >>>>> files, and a root-level "/war" directory with the exploded non-Java files >>>>> (static assets, JSPs, etc.). When developing, Eclipse compiles the >>>>> "/src" directory into the "/war/WEB-INF/classes" directory, and then >>>>> copies any changed files from "/war" into its embedded Tomcat instance. >>>>> >>>>> When we switch Git branches, that could change the .jsp/.tag files inside >>>>> the "/war" directory, but depending on the branch, those changed files >>>>> might have an earlier modified-timestamp than the .jsp/.tag files that >>>>> have already been copied over to the embedded Tomcat's exploded webapp >>>>> directory. So my thought was that those files would not, then, be >>>>> recompiled, and so at runtime, Tomcat would be using the older versions >>>>> of those files that are cached in Tomcat's "/work" directory. I think >>>>> that theory is countered, however, by my colleague's claim that she >>>>> clears out "/work" before deploying a new branch, and also my own >>>>> experience wherein I watched Tomcat re-compile the .tag file into the >>>>> "/work" directory, yet still claim the tag's class "cannot be resolved." >>>>> >>>>> But to clarify: no part of Tomcat itself, including "/work", is kept >>>>> under version control. >>>>> >>>>> -- Jim >>>>> >>>>> >>>>> On 11/20/12 2:18 AM, Pid * wrote: >>>>>> On 19 Nov 2012, at 23:58, Jim <open...@gmail.com> wrote: >>>>>> >>>>>>> Hello! >>>>>>> >>>>>>> My team has been having an issue wherein our application occasionally >>>>>>> fails to start up because Tomcat claims it can't find find a >>>>>>> dynamically-created classfile. This doesn't happen all the time, and >>>>>>> restarting Tomcat (albeit more than once, sometimes) resolves it. >>>>>>> >>>>>>> For example, I just started my Tomcat 6.0.26 instance (via Eclipse WTP, >>>>>>> on OS 10.7.5), tried to load a page, and got: >>>>>>> >>>>>>> ** snip ** >>>>>>> >>>>>>> An error occurred at line: 1 in the jsp file: >>>>>>> /WEB-INF/jsp/about/about_impact.jsp >>>>>>> org.apache.jsp.tag.web.about_tag cannot be resolved to a type >>>>>>> 1: <%@ include file="../common/constants.jsp" %><templates:about> >>>>>>> >>>>>>> ** snip/ ** >>>>>>> >>>>>>> The constants.jsp referenced above contains: >>>>>>> <%@ taglib prefix="templates" tagdir="/WEB-INF/tags" %> >>>>>>> >>>>>>> ... and /WEB-INF/tags contains the "about.tag" file. >>>>>>> >>>>>>> The "$CATALINA_HOME/work/Catalina/localhost/_/org/apache/jsp/tag/web" >>>>>>> directory exists, and it contains both about_tag.class and >>>>>>> about_tag.java, with timestamps corresponding to when I loaded the page. >>>>>>> >>>>>>> I then deleted those files, and refreshed the page in my browser. >>>>>>> about_tag.class and about_tag.java get recreated in that directory, but >>>>>>> I still get the above error claiming about_tag can't be resolved. >>>>>>> >>>>>>> I then restarted Tomcat, refreshed the page in my browser, and all is >>>>>>> well. >>>>>>> >>>>>>> >>>>>>> I've also seen this happen regularly for my Windows-using colleagues, >>>>>>> as well as in a non-Eclipse Linux-based 6.0.29 instance, and (hearsay) >>>>>>> a colleague reported it happening in his Tomcat 7. Thinking it was a >>>>>>> runtime race condition, we also tried telling Tomcat to load the JSP on >>>>>>> startup via the web.xml, and while we did see the .java and .class >>>>>>> files being created on startup, we still ran into the issue. We >>>>>>> haven't yet tried pre-compiling our JSPs/TAGs before starting Tomcat -- >>>>>>> but that shouldn't be necessary, right? >>>>>>> >>>>>>> I'd love some advice/insight in how I might investigate this further, >>>>>>> or if there's a "gotcha" I might be running into. It "feels" like a >>>>>>> race condition in the classloader, but I don't want to submit a bug >>>>>>> report without a reliable test case, of course. Since we can't reliably >>>>>>> recreate the situation, I'm having trouble putting that together. >>>>>>> >>>>>>> This seems to happen more often for me when I'm switching between >>>>>>> substantially-different Git branches, so I thought it might have to do >>>>>>> with the /work directory having older versions of the JSPs/TAGs, but >>>>>>> one of my colleagues claims to clean her "/work" directory every time >>>>>>> she switches branches, and before starting Tomcat, and still getting >>>>>>> the issue. >>>>>> What is the relationship between Git and Tomcat, exactly? >>>>>> >>>>>> Does Tomcat load an app (or its files) directly from a version >>>>>> controlled file system? >>>>>> >>>>>> >>>>>> p >>>>>> >>>>>> >>>>>> >>>>>>> Thanks in advance for any help! >>>>>>> Jim >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>>>>>> For additional commands, e-mail: users-h...@tomcat.apache.org >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>>>>> For additional commands, e-mail: users-h...@tomcat.apache.org >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>>>> For additional commands, e-mail: users-h...@tomcat.apache.org >>>> Is any part of the compiled output, under /war in version control? >>>> (It should not be). >>>> >>>> >>>> p >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>>> For additional commands, e-mail: users-h...@tomcat.apache.org >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> I wasn't clear. >> >> What I'm getting at is this: your release process should produce a >> .war (or exploded directory) that is copied to Tomcat and that Tomcat >> should not be reading any part of the app from the /war directory - a >> source controlled directory. >> >> If this is the case? >> >> If this is a common feature of you & your colleagues dev environments >> it's a candidate for the cause, in my view. >> >> >> Another common reason is timestamps on files not matching >> server/machine time, but I don't think this fits your description. >> >> >> p >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org
There have been some fixes to Jasper since 6.0.26 (the latest is 6.0.36). Perhaps you could try with the latest release? p PS are you seeing any clues about top posting? --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
