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
