[Bug 54007] New: Improve handling of failed web application deployments
https://issues.apache.org/bugzilla/show_bug.cgi?id=54007 Priority: P2 Bug ID: 54007 Assignee: dev@tomcat.apache.org Summary: Improve handling of failed web application deployments Severity: normal Classification: Unclassified OS: Windows XP Reporter: knst.koli...@gmail.com Hardware: PC Status: NEW Version: 6.0.35 Component: Catalina Product: Tomcat 6 1) If Tomcat 6 runs with autodeployment being enabled, and a web application deployment fails, Tomcat will repeat attempts to autodeploy the application every 10 seconds. So every 10 seconds an error message is printed into the error log. To reproduce: place a broken context xml file (e.g. with a typo) into conf/Catalina/localhost. 2) The input stream for the broken context xml file is not properly closed. When running on Windows the file cannot be deleted without stopping Tomcat. 3) If a broken web application is deployed via Manager web application GUI, it fails to deploy and it is not displayed in the list of the applications. As a consequence - It cannot be undeployed via GUI, as it is absent from the list. If one crafts the command URL manually, it fails with FAIL - No context exists for path /test - It cannot be replaced with a new correct version of the application, because if you try to upload a new war, it fails with FAIL - War file test.war already exists on server Note, that in Tomcat 7 the issue has already been fixed in 7.0.23 -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 54007] Improve handling of failed web application deployments
https://issues.apache.org/bugzilla/show_bug.cgi?id=54007 --- Comment #1 from Konstantin Kolinko knst.koli...@gmail.com --- Created attachment 29477 -- https://issues.apache.org/bugzilla/attachment.cgi?id=29477action=edit 2011-11-14_tc6_54007.patch Patch for Tomcat 6 The change in ContainerBase.addChild() is needed to display failed applications in the Manager webapp. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1398228 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: kkolinko Date: Mon Oct 15 09:18:59 2012 New Revision: 1398228 URL: http://svn.apache.org/viewvc?rev=1398228view=rev Log: Created an issue in bugzilla and uploaded the patch there. The patch is the same as proposed earlier (just combined two patches into one patch file), so no changes in the votes. Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=1398228r1=1398227r2=1398228view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Mon Oct 15 09:18:59 2012 @@ -31,14 +31,13 @@ PATCHES ACCEPTED TO BACKPORT: PATCHES PROPOSED TO BACKPORT: [ New proposals should be added at the end of the list ] -* Fix autodeployment of applications that have configuration errors. +* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=54007 + Fix deployment of applications that have configuration errors. If autodeployment fails, create DeployedApplication object and register what we deployed (xml or war or dir - a single file) as redeployResource. If it is updated the application will be redeployed. - + ContainerBase patch adds display of failed apps in manager. They can be - listed and undeployed. - http://people.apache.org/~kkolinko/patches/2011-11-14_tc6_HostConfig.patch - http://people.apache.org/~kkolinko/patches/2011-11-14_tc6_ContainerBase.patch + Note that this includes a change to ContainerBase.addChild(). + https://issues.apache.org/bugzilla/attachment.cgi?id=29477 +1: kkolinko, schultz +0: kfujino: Question of if host.addChild(context) threw IllegalStateException. E.g. case of deployDirectory. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 51698] ajp CPing/Forward-Request packet forgery, is a design decision? or a security vulnerability?
https://issues.apache.org/bugzilla/show_bug.cgi?id=51698 zhanqili zhanq...@163.com changed: What|Removed |Added Component|Connectors |Servlet JSP API Version|7.0.20 |6.0.8 Product|Tomcat 7|Tomcat 6 Target Milestone|--- |default OS|Windows XP |Windows Server 2008 -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 51698] ajp CPing/Forward-Request packet forgery, is a design decision? or a security vulnerability?
https://issues.apache.org/bugzilla/show_bug.cgi?id=51698 Mark Thomas ma...@apache.org changed: What|Removed |Added Component|Servlet JSP API |Connectors Version|6.0.8 |7.0.20 Product|Tomcat 6|Tomcat 7 Target Milestone|default |--- OS||All -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Bug 51698] ajp CPing/Forward-Request packet forgery, is a design decision? or a security vulnerability?
On 15/10/2012 10:21, bugzi...@apache.org wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=51698 zhanqili zhanq...@163.com changed: This idiot ^ has had their BZ account locked for messing about with this bug. I have restored the original values. Mark What|Removed |Added Component|Connectors |Servlet JSP API Version|7.0.20 |6.0.8 Product|Tomcat 7|Tomcat 6 Target Milestone|--- |default OS|Windows XP |Windows Server 2008 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 54007] Improve handling of failed web application deployments
https://issues.apache.org/bugzilla/show_bug.cgi?id=54007 --- Comment #2 from Konstantin Kolinko knst.koli...@gmail.com --- Concerns about the patch 1) Messy. The new methods have to be documented better and to be made protected instead of private. 2) Several concerns about getContextPathFromFileName() method: - It needs better API. In the patch it combines context name calculation, canonicalization check and update of invalidWars map. Originally the check was supposed to be performed for war files only. - Typo in getContextPathFromFileName() JavaDoc: a Cyrillic char instead of trailing '.' - A bug: The appbase argument is not used because of a typo. The method calls validateContextPath(appBase,..) using this.appBase instead of appbase argument. - The validation check that uses canonicalization is expensive. It could be improved by reordering the checks. Reordering cannot be done if the check is encapsulated in this method. See http://svn.apache.org/viewvc?view=revisionrevision=1380891 3) HostConfig.invalidWars is a HashSet. I think it has to be made final and access to it has to be made synchonized. 4) As noted by kfujino in STATUS.txt of Tomcat 6 where this patch was proposed: Question of if host.addChild(context) threw IllegalStateException. E.g. case of deployDirectory. If META-INF/context.xml exist in Directory, context.xml is copied to configBase. If host.addChild(context) threw IllegalStateException, only a directory is registered into redeployResources. Context.xml does not register into redeployResources. If manager app execute undeploy(or delete directory), directory is deleted but context.xml isn't deleted. Should (conf/Catalina/localhost/)context.xml be registered into redeployResources? Or need to delete context.xml manually? I think context.xml should be registered into redeployResources. A better patch is needed. 5) Regarding the change to ContainerBase.addChild() It seems too wide (concerns all containers), but I do not see a better solution here. (In reply to comment #0) 2) The input stream for the broken context xml file is not properly closed. When running on Windows the file cannot be deleted without stopping Tomcat. I do not have a solution for the locked context xml file issue. Tomcat 7 is affected as well. The issue seems to occur inside XmlReader created by Digester. We could patch out copy of Digester, but I do not see an API there to explicitly close the file. The workaround is to force full GC (e.g. to press the Find Leaks button in the Manager). After that the file is unlocked. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1398251 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: kkolinko Date: Mon Oct 15 11:27:09 2012 New Revision: 1398251 URL: http://svn.apache.org/viewvc?rev=1398251view=rev Log: Revoke the proposal, due to issues listed in https://issues.apache.org/bugzilla/show_bug.cgi?id=54007#c2 Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=1398251r1=1398250r2=1398251view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Mon Oct 15 11:27:09 2012 @@ -31,25 +31,6 @@ PATCHES ACCEPTED TO BACKPORT: PATCHES PROPOSED TO BACKPORT: [ New proposals should be added at the end of the list ] -* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=54007 - Fix deployment of applications that have configuration errors. - If autodeployment fails, create DeployedApplication object and register - what we deployed (xml or war or dir - a single file) as redeployResource. - If it is updated the application will be redeployed. - Note that this includes a change to ContainerBase.addChild(). - https://issues.apache.org/bugzilla/attachment.cgi?id=29477 - +1: kkolinko, schultz - +0: kfujino: Question of if host.addChild(context) threw IllegalStateException. - E.g. case of deployDirectory. - If META-INF/context.xml exist in Directory, context.xml is copied to configBase. - If host.addChild(context) threw IllegalStateException, only a directory is - registered into redeployResources. Context.xml does not register into redeployResources. - If manager app execute undeploy(or delete directory), directory is deleted - but context.xml isn't deleted. - Should (conf/Catalina/localhost/)context.xml be registered into redeployResources? - Or need to delete context.xml manually? - -1: - * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=52918 Add WebSocket support to Tomcat 6 +1: fhanik - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1398256 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: kkolinko Date: Mon Oct 15 12:06:28 2012 New Revision: 1398256 URL: http://svn.apache.org/viewvc?rev=1398256view=rev Log: Vote against WebSockets proposal and move it into the stalled section. Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=1398256r1=1398255r2=1398256view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Mon Oct 15 12:06:28 2012 @@ -31,11 +31,6 @@ PATCHES ACCEPTED TO BACKPORT: PATCHES PROPOSED TO BACKPORT: [ New proposals should be added at the end of the list ] -* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=52918 - Add WebSocket support to Tomcat 6 - +1: fhanik - -0: jfclere - * Backport UserDataHelper class (issue 52184) Provide greater control over the logging of errors triggered by invalid input data (i.e. data over which Tomcat has no control). @@ -91,3 +86,20 @@ PATCHES/ISSUES THAT ARE STALLED markt - r1172614 needs to be included in this proposal. With that patch, my testing shows that the unloading works as designed -1: + +* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=52918 + Add WebSocket support to Tomcat 6 + +1: fhanik + -0: jfclere + -0: kkolinko: + - Interesting, but I do not think there is much interest in it. + If one needs this feature I would suggest to upgrade to Tomcat 7. + If one cannot upgrade to Tomcat 7 then they probably cannot + upgrade to a later Tomcat 6 either. + - The protocol specification still evolves. I think it is too risky + to implement websockets for Tomcat 6. + - Formally, the proposal does not have a link to the patch. + - The patch in Bugzilla does not include latest changes from Tomcat 7. E.g. +http://svn.apache.org/viewvc?view=revisionrevision=1380841 + (Is one supposed to just copy the current version of websocket + package from Tomcat 7 here?) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GUMP@vmgump]: Project tomcat-taglibs-standard (in module tomcat-taglibs) failed
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project tomcat-taglibs-standard has an issue affecting its community
integration.
This issue affects 2 projects,
and has been outstanding for 130 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- tomcat-taglibs-standard : Standard Taglib
- tomcat-taglibs-standard-install : JSP Taglibs
Full details are available at:
http://vmgump.apache.org/gump/public/tomcat-taglibs/tomcat-taglibs-standard/index.html
That said, some information snippets are provided here.
The following annotations (debug/informational/warning/error messages) were
provided:
-INFO- Optional dependency httpunit failed with reason build failed
-DEBUG- (Apache Gump generated) Apache Maven Settings in:
/srv/gump/public/workspace/tomcat-taglibs/standard/gump_mvn_settings.xml
-INFO- Failed with reason build failed
-DEBUG- Maven POM in:
/srv/gump/public/workspace/tomcat-taglibs/standard/pom.xml
-INFO- Failed to extract fallback artifacts from Gump Repository
The following work was performed:
http://vmgump.apache.org/gump/public/tomcat-taglibs/tomcat-taglibs-standard/gump_work/build_tomcat-taglibs_tomcat-taglibs-standard.html
Work Name: build_tomcat-taglibs_tomcat-taglibs-standard (Type: Build)
Work ended in a state of : Failed
Elapsed: 23 secs
Command Line: /opt/maven2/bin/mvn --batch-mode -DskipTests=true --settings
/srv/gump/public/workspace/tomcat-taglibs/standard/gump_mvn_settings.xml
install
[Working Directory: /srv/gump/public/workspace/tomcat-taglibs/standard]
M2_HOME: /opt/maven2
-
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Nothing to compile - all classes are up to date
[debug] execute contextualize
[INFO] [resources:testResources {execution: default-testResources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
/srv/gump/public/workspace/tomcat-taglibs/standard/spec/src/test/resources
[INFO] Copying 3 resources
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] No sources to compile
[INFO] [surefire:test {execution: default-test}]
[INFO] Tests are skipped.
[INFO] [bundle:bundle {execution: default-bundle}]
[INFO] [install:install {execution: default-install}]
[INFO] Installing
/srv/gump/public/workspace/tomcat-taglibs/standard/spec/target/taglibs-standard-spec-1.2-SNAPSHOT.jar
to
/srv/gump/public/workspace/mvnlocalrepo/shared/org/apache/taglibs/taglibs-standard-spec/1.2-SNAPSHOT/taglibs-standard-spec-1.2-SNAPSHOT.jar
[INFO] [bundle:install {execution: default-install}]
[INFO] Parsing
file:/srv/gump/public/workspace/mvnlocalrepo/shared/repository.xml
[INFO] Installing
org/apache/taglibs/taglibs-standard-spec/1.2-SNAPSHOT/taglibs-standard-spec-1.2-SNAPSHOT.jar
[INFO] Writing OBR metadata
[INFO]
[INFO] Building JSTL Implementation
[INFO]task-segment: [install]
[INFO]
[INFO] [remote-resources:process {execution: default}]
[INFO] snapshot org.apache.taglibs:taglibs-standard-spec:1.2-SNAPSHOT: checking
for updates from apache.snapshots
[debug] execute contextualize
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 14 resources
[INFO] Copying 3 resources
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 96 source files to
/srv/gump/public/workspace/tomcat-taglibs/standard/impl/target/classes
[INFO] -
[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR]
/srv/gump/public/workspace/tomcat-taglibs/standard/impl/src/main/java/org/apache/taglibs/standard/tag/common/sql/DataSourceWrapper.java:[38,7]
error: DataSourceWrapper is not abstract and does not override abstract method
getParentLogger() in CommonDataSource
[INFO] 1 error
[INFO] -
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
/srv/gump/public/workspace/tomcat-taglibs/standard/impl/src/main/java/org/apache/taglibs/standard/tag/common/sql/DataSourceWrapper.java:[38,7]
error: DataSourceWrapper is not abstract and does not override abstract method
getParentLogger() in CommonDataSource
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
tagging 6.0.36 tomorrow morning
Hi, I have done all tests I plan to tag tomorrow morning (my morning). Comments? Cheers Jean-Frederic - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 54010] New: Suggestion for code improvement (avoiding potential bug)
https://issues.apache.org/bugzilla/show_bug.cgi?id=54010
Priority: P2
Bug ID: 54010
Assignee: dev@tomcat.apache.org
Summary: Suggestion for code improvement (avoiding potential
bug)
Severity: normal
Classification: Unclassified
OS: Linux
Reporter: shensiu...@gmail.com
Hardware: PC
Status: NEW
Version: 5.5.36
Component: Connector:Coyote
Product: Tomcat 5
In connectors/jk/java/org/apache/jk/common/HandlerRequest.java
coyote.Request's schemeMB is assigned in 2 places.
1st place:
400 boolean isSSL = msg.getByte() != 0;
401 if( isSSL ) {
402 // XXX req.setSecure( true );
403 req.scheme().setString(https);
404 }
2nd place:
518 case AjpConstants.SC_A_SSL_CERT :
519 req.scheme().setString( https );
and similar assignments for SC_A_SSL_CIPHER and SC_A_SSL_SESSION cases below.
It seems they do not make sense because the packet's 8-bit field is designated
for telling whether it's SSL or not. So the 1st place is enough. Adding the 2nd
place may pose potential bug in that a packet with the 8-bit SSL field being 0
and suffixes of SC_A_SSL_* key-value pairs can later incorrect trigger a wrong
redirection message pointing to a https location.
A simple correction is to honor the 8-bit SSL-field in packet and delete the 3
lines of 2nd place assigning https.
Even though the chances of such spurious packet is low, but it's best we can
have threat-free, semantic-correct tomcat code.
The same lines of code remain in 6.0 and 7.0.
But maybe I misunderstand the code, in which case please kindly point out.
Thanks.
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
