[digester] Loading of resources causes webapp to fail redeploy under Tomcat 5.5.x

• Key: DIGESTER-29
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Unassigned
• Reporter: Rich Feit
• Affects Version/s: 1.5
• Fix Version/s: 1.8

Environment

Operating System: other
Platform: Other

Description

This was originally filed against Beehive as
http://issues.apache.org/jira/browse/BEEHIVE-960 , but I've narrowed it down to
either a Digester issue or a Tomcat issue. Tomcat seems to suggest that this is
an issue related to getting resources out of a JAR:

• http://issues.apache.org/bugzilla/show_bug.cgi?id=33830
• http://jakarta.apache.org/tomcat/faq/windows.html#lock

Specifically, Tomcat turned off the behavior that prevents locking of JARs under
Windows. They did this to improve startup time. I don't necessarily agree with
this choice as a default, but if you believe their bug comments and FAQ, this
actually just exposes Windows-specific bugs in the way resources are read out of
JARs.

To reproduce this:

• Run 'ant build war' in the attached directory.
• Copy strutsRedeploy.war into $CATALINA_HOME/webapps.
• Verify that there is a fully-extracted webapp under
  $CATALINA_HOME/webapps/strutsRedeploy.
• Copy strutsRedeploy.war (again) into $CATALINA_HOME/webapps.

Now look in $CATALINA_HOME/webapps/strutsRedeploy – it failed to redeploy, and
the only file left in there is WEB-INF/lib/struts.jar.

I'm attaching a Digester patch that fixes the issue.

Note: the fix for this issue belongs in one of three places:

• Tomcat (which has rejected working around it since it impacts startup time)
• Digester
• XML support in the JDK

Hopefully you'll choose Digester.

Comments

[Rich Feit]

Created an attachment (id=16669)
Repro case

I had to remove a few JARs from WEB-INF/lib for the attachment to be accepted
– I ran it again and it still seems to work.

[Rich Feit]

Created an attachment (id=16670)
Proposed fix

This seems to fix the problem.

[Simon Kitching]

Thanks very much for your patch, Rich.

I've got no objection to this change in principle. Clearly the correct place to
fix it is in the JDK's implementation of InputSource, but this wouldn't be the
first workaround for a JDK bug in Digester.

There is a potential issue with the provided patch, which is that the
InputSource is created with no knowledge of the systemId (just a Stream) which
means that relative paths within the resource won't work any longer. I think
that can be fixed by just doing:

InputSource is = new InputSource(urlConnection.getInputStream());
is.setSystemId(entityURL);
return is;

And there should also be a comment in the code explaining why this simple task
is being implemented in this odd manner.

I don't have much time to analyse this patch properly just at the moment; I'll
try to do so at the weekend if someone else doesn't commit this before then.

[Rich Feit]

Thanks for the fast response, Simon. I'll verify that fixing the lack of
systemId doesn't break my test case (I doubt it).

[Simon Kitching]

I've applied a slightly modified version of this patch. See r325861, r325866.

I'd like to leave this open as I think the xmlrules module probably has a few
places where this same change needs to be made.

[Rich Feit]

Thank you. FYI, I verified that your modified patch fixes the specific problem
I reported.

[Craig McClanahan]

Besides 1.5 (the documented "Affected Version"), this issue is also present in version 1.6 and 1.7. It bit me when I was using the Digester.register() method to register copies of DTDs internal to the JAR file. This would cause an I/O stream or something to remain open on the DTD, which (in turn) would cause the jar file to remain locked after a webapp undeploy on Windows.

Happily, the patched version works fine for this scenario (tested with the 20061111 nightly build), so I guess it's time to get back in the digester game and help get a 1.8 release out the door .

[Simon Kitching]

Hi Craig, welcome back. There is currently work going on to prepare Digester for a 1.8 release; finishing maven2 support is the major TODO. Hopefully a release can be made in the next couple of weeks.

There is a recent email thread in the dev archives talking about release stuff.

Of course all help is welcome!

[Simon Kitching]

Fixed in 1.8 release.