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
