[Bug 54007] Improve handling of failed web application deployments

2017-01-01 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=54007

Mark Thomas  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|NEW |RESOLVED

--- Comment #4 from Mark Thomas  ---
Marking as WONTFIX since 6.0.x has reached end of life.

-- 
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

2012-11-11 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=54007

--- Comment #3 from Mark Thomas ma...@apache.org ---
Note the leak has been identified and fixed in trunk and 7.0.x. See r1408163
and r1408166.

-- 
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

2012-10-15 Thread bugzilla
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



[Bug 54007] Improve handling of failed web application deployments

2012-10-15 Thread bugzilla
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