You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2009/09/23 11:55:36 UTC

DO NOT REPLY [Bug 47467] Deployment of the war file by URL when contextpath is not specified in Manager Application.

https://issues.apache.org/bugzilla/show_bug.cgi?id=47467

Uwe Günther <uw...@cscc.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Platform|PC                          |All
         OS/Version|Windows XP                  |All

--- Comment #1 from Uwe Günther <uw...@cscc.de> 2009-09-23 02:55:30 PDT ---
I just investigated a bit in this one and IMHO this bug is realy odd because
the documentation in html-manager-howto.xml and
o.a.catalina.manager.ManagerServlet is not in sync with what the code does or
is designed for.

Let me point that out in detail:

1. The docs are talking about JarURLConnection like syntax for the 'WAR or
Directory URL' field in the 'Deploy' section of HTMLManagerServlet* (aka known
as war parameter there):

    jar:file:/c:/myWebapp.war!/ **

If you look in the code - you will find out - it can only handle java.io.File
like file names (with an optional 'file:' prefix): 

    file:C:/myWebapp.war
    file://C:/myWebapp.war
    file:///C:/myWebapp.war
    file:////C:/myWebapp.war
    file://///C:/myWebapp.war
    file://////C:/myWebapp.war

    file:C:/myWebapp
    file://C:/myWebapp
    file:///C:/myWebapp
    file:////C:/myWebapp
    file://///C:/myWebapp
    file://////C:/myWebapp

    C:/myWebapp.war
    C:\myWebapp.war

    C:/myWebapp
    C:\myWebapp


Every other filename not ending with '.war' is handled by the code as already
exploded directory and gets deployed as such!

Back to the point: The existing code in HTMLManagerServlet and ManagerServlet
is unable to handle JarURLConnection like syntax like following one mentioned
above: jar:file:/c:/myWebapp.war!/ To make it crystal clear here, the only type
of URL they can handle are 'file:' URLs based on java.io.File(String) at all.

* Note: HTMLManagerServlet is a sub class of ManagerServlet which gets used by
the Ant DeployTask as well. So there are common implications.


2.) On the one hand if you deploy a war file remote via the 'Select WAR file to
upload' field in the 'Deploy' section of HTMLManagerServlet the 'Context Path'
gets derived from the war file name. So you don't need a 'Context Path' to
deploy a *.war file. For example if your war file is callled 'myWebapp.war',
your 'Context Path' will be '/myWebapp'.
On the other hand if you try to deploy a webapp as a *.war or a directory
locally via 'WAR or Directory URL' you have to provide a 'Context Path', but it
would be possible to derive the 'Context Path' as well from the 'WAR or
Directory URL' name like it is done for remote deployments.


Proposed Solution:

- Fix the documentaion and the HTMLManagerServlet UI to get number 1.) fixed.
Especially remove the word 'URL' from the HTMLManagerServlet UI field
descriptors and the jar:file:.... Urls from the javadoc and the
html-manager-howto.xml

- Enhance ManagerServlet to derive the 'Context Path' (aka 'path' parameter)
from an already given 'WAR or Directory' (aka 'war' parameter). For example if
you have no 'Context Path' and the 'WAR or Directory' filed contains
'C:\myWebapp' or 'C:\myWebapp.war' the 'Context Path' will be '/myWebapp'.

I start to work on this from now on in the trunk and will append the patch as
soon as I am finished (probably this week) to this bug, so it can merged in by
one of the commiter.

Would be nice to get some feedback if the probosed solution fits or not.

-- 
Kind Regards
Uwe Günther

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org