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
