0004875: Undeploy does not seem to undeploy /var/www/webapps/blog/WEB-INF/lib,

Viewing Issue Simple Details [ Jump to Notes ]

[ View Advanced ] [ Issue History ] [ Print ]

Category

Severity

Reproducibility

Date Submitted

Last Update

0004875

[Resin]

minor

always

11-25-11 17:14

06-15-12 12:05

Reporter

rickHigh

View Status

public

Assigned To

ferg

Priority

normal

Resolution

reopened

Status

closed

Product Version

4.0.24

Summary

0004875: Undeploy does not seem to undeploy /var/www/webapps/blog/WEB-INF/lib,

Description

I notice during the course of writing the cloud deploy tutorial that undeploy does not seem to clean up all of the jar files in WEB-INF.

Roo has a problem where it includes jstl files that it should not.

To get around this issue, I remove all jstl dependencies pom.xml

$ mvn clean
$ mvn package
$ resinctl deploy target/blog-0.1.0.BUILD-SNAPSHOT.war -name blog

At this point, I should not get an 500 message (included below), but I do.

When I wipe out the deploy dir (/var/www/webapps/blog/), it then works.

$ mvn clean
$ mvn package
$ sudo rm -rf /var/www/webapps/blog/
$ resinctl deploy target/blog-0.1.0.BUILD-SNAPSHOT.war -name blog

Here is the error, but it does not really matter.

500 Servlet Exception

file:/var/www/webapps/blog/WEB-INF/tags/util/panel.tagx:1: org.xml.sax.SAXParseException;
lineNumber: 6; columnNumber: 40; The prefix "c" for element "c:if" is not
bound.

1: <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" [^] xmlns:fn="http://java.sun.com/jsp/jstl/functions" [^]
xmlns:spring="http://www.springframework.org/tags" [^] xmlns:c="http://java.sun.com/jsp/jstl/core" [^]
version="2.0">
2: <jsp:output omit-xml-declaration="yes" />
3:

Additional Information

Attached Files

Relationships

Notes
(0005704) jafr 03-01-12 10:20	This behaviour breaks cluster and cloud deployments completely. I experienced the same problem if I install a war with a set of libraries that contain version numbers in the JAR file names, and then re-deploy a new version that has upgraded JAR libraries, you finish with both, OLD and NEW, JAR files on your WEB-INF/lib expanded directory. Given the way the class-loader searches the directory the code finish using the old libraries instead of the new. If you use Maven where every release of your different code modules may have a different version number, this bug makes Resin deployments unusable. The severity of this bug needs to be raised as it is a major issue.

(0005855) ferg 06-15-12 12:05	server/6b0e

Issue History
Date Modified	Username	Field	Change
11-25-11 17:14	rickHigh	New Issue
03-01-12 10:11	jafr	Issue Monitored: jafr
03-01-12 10:20	jafr	Note Added: 0005704
06-15-12 12:05	ferg	Note Added: 0005855
06-15-12 12:05	ferg	Assigned To	=> ferg
06-15-12 12:05	ferg	Status	new => closed
06-15-12 12:05	ferg	Resolution	open => reopened
06-15-12 12:05	ferg	Fixed in Version	=> 4.0.29

Mantis 1.0.0rc3[^]

33 total queries executed.
28 unique queries executed.