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
