You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Jim <op...@gmail.com> on 2012/11/20 00:58:03 UTC
TC 6.0.2*: Dynamically-compiled jsps/tags not being loaded
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.
Thanks in advance for any help!
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: TC 6.0.2*: Dynamically-compiled jsps/tags not being loaded
Posted by Mark Thomas <ma...@apache.org>.
On 20/11/2012 22:19, Jim wrote:
> Sorry about that; thanks for the note -- it looked like other recent
> messages to the list were top-posted, or inline, so I assumed that was
> desired.
Top-posting bad.
Bottom-posting fine.
In-line better.
Appropriate quoting even better.
> One of my colleagues was using a recent Tomcat 7 release with our
> project and claims to have been getting the same issue, so I'm skeptical
> that an upgrade will solve this. That's hearsay, though; it's on my
> list to confirm that for myself.
I'd suggest starting Tomcat with debugging enabled and stepping through
the JSP loading code when the problem starts. With a better idea of why
the class doesn't load we might be able to figure out the root cause.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: TC 6.0.2*: Dynamically-compiled jsps/tags not being loaded
Posted by Jim <op...@gmail.com>.
On 11/20/12 5:02 PM, Pid * wrote:
> On 20 Nov 2012, at 21:44, Jim <op...@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 <op...@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 <op...@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 <op...@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-unsubscribe@tomcat.apache.org
>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>> For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Sorry about that; thanks for the note -- it looked like other recent
messages to the list were top-posted, or inline, so I assumed that was
desired.
One of my colleagues was using a recent Tomcat 7 release with our
project and claims to have been getting the same issue, so I'm skeptical
that an upgrade will solve this. That's hearsay, though; it's on my
list to confirm that for myself.
-- Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: TC 6.0.2*: Dynamically-compiled jsps/tags not being loaded
Posted by Pid * <pi...@pidster.com>.
On 20 Nov 2012, at 21:44, Jim <op...@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 <op...@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 <op...@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 <op...@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-unsubscribe@tomcat.apache.org
>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: TC 6.0.2*: Dynamically-compiled jsps/tags not being loaded
Posted by Jim <op...@gmail.com>.
> 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 <op...@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 <op...@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 <op...@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-unsubscribe@tomcat.apache.org
>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: TC 6.0.2*: Dynamically-compiled jsps/tags not being loaded
Posted by Pid * <pi...@pidster.com>.
On 20 Nov 2012, at 19:44, Jim <op...@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 <op...@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 <op...@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-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: TC 6.0.2*: Dynamically-compiled jsps/tags not being loaded
Posted by Jim <op...@gmail.com>.
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 <op...@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 <op...@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-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: TC 6.0.2*: Dynamically-compiled jsps/tags not being loaded
Posted by Pid * <pi...@pidster.com>.
On 20 Nov 2012, at 13:42, Jim <op...@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 <op...@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-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: TC 6.0.2*: Dynamically-compiled jsps/tags not being loaded
Posted by Jim <op...@gmail.com>.
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 <op...@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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: TC 6.0.2*: Dynamically-compiled jsps/tags not being loaded
Posted by Pid * <pi...@pidster.com>.
On 19 Nov 2012, at 23:58, Jim <op...@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org