Ok. After more investigation I've found a couple of things.
First, I've found that there is a workaround that (sometimes) seems
to help. If I force our ant build script to regenerate the jsp
wrapper files, it will *sometimes* push the webapp into a state where
(after the initial wrapper recompile) the problem seems to go away.
After this initial rebuild/recompile, minor changes to specific sub-
tags seem to get picked up by resin and properly re-compiled.
Second, I was wrong earlier. It seems that the the dependency list in
the compiled .java file (from the jsp/tag files) is actually NOT
correct in some cases (it only lists one dependency -- the wrapped
outer tag file).
Specifically, after performing the above manual rebuild, the
dependency list is (sometimes) correct. When this is true, the
recompilations then behave as expected (problem goes away).
So it seems that the problem is due to an incorrect dependency list
in the compiled jsp/tag files.
Any idea why the JSP compiler might generate an incorrect dependency
On Feb 2, 2007, at 4:45 PM, Scott Ferguson wrote:
> On Feb 2, 2007, at 4:37 PM, Gerry Panganiban wrote:
>> The dependency list looks correct. The tag files I am changing are
>> listed there.
>> Although I noticed that some of the values that are being passed
>> into the lastModified attribute are actually negative (e.g.:
> That number's just a CRC. So half of them should be negative.
> Are you changing the return values for things like doStartTag()?
> Resin's tag analysis code looks to see what values your tag can
> return from doStartTag() and generates optimized code based on those
> values. But the dependency checking code only validates the
> signatures, not the actual code. So it's possible that Resin isn't
> detecting your changes because it thinks you haven't done anything
> significant to the class.
> Does that sound possible?
> -- Scott
>> --- [EMAIL PROTECTED] wrote:
>> From: Scott Ferguson <[EMAIL PROTECTED]>
>> To: General Discussion for the Resin application server <resin-
>> [EMAIL PROTECTED]>
>> Subject: Re: [Resin-interest] Odd problem with JSP recompile
>> Date: Fri, 2 Feb 2007 16:21:46 -0800
>> On Feb 2, 2007, at 3:21 PM, Gerry Panganiban wrote:
>>> This problem has been baffling me for weeks now. We are running
>>> resin (somewhat older 3.0.14 release) and I'm seeing something
>>> Much of our application's interface is implemented in JSP 2.0
>>> *.tag files. As part of our build process (using ant), we auto-
>>> generate a *.jsp file which is a simple wrapper around a main tag
>>> file, which itself embeds many other *.tag files underneath it.
>>> Normally, in our development environment, any change in the
>>> underlying tag
>>> files are detected by resin, which will then recompile the tag
>>> and redeploy just the tag files that changed and its 'parent' tags.
>> Can you look at the generated *.java class for the JSP file? It
>> should list the dependencies, which may give an idea why that
>> dependency isn't being detected.
>> -- Scott
>>> The problem is that for ONE specific wrapper tag, changes in tags
>>> underneath it are never seen by resin and does not trigger a
>>> recompile. Our only workaround so far has been to:
>>> 1) Stop the resin server
>>> 2) Rebuild the entire web app, including the auto-generated wrapper
>>> 3) Copy the entire web app's directory structure to the resin
>>> webapps directory
>>> 4) Restart the resin server
>>> This causes resin to have to *recompile* all the tag and jsp files
>>> which can be very time consuming (it takes as long as 30 minutes).
>>> What I don't understand is why for EVERY auto-generated wrapper JSP
>>> except this one, resin does not detect that a dependent tag file
>>> has been changed.
>>> I've made sure that resin.conf file has the proper settings (<jsp
>>> auto-compile="true" ... etc >).
>>> Another oddity is that this problem only started happening fairly
>>> recently. Nothing in the development environment has changed.
>>> Can anyone shed some light as to why this might possibly be
>>> resin-interest mailing list
>> resin-interest mailing list
>> resin-interest mailing list
> resin-interest mailing list
resin-interest mailing list