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 2007/12/05 00:34:01 UTC
DO NOT REPLY [Bug 44021] New: - Deployer cannot deploy wars with #s
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=44021>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=44021
Summary: Deployer cannot deploy wars with #s
Product: Tomcat 6
Version: 6.0.14
Platform: All
OS/Version: other
Status: NEW
Severity: major
Priority: P1
Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: ebenze@hotmail.com
If you want to deploy a war in a sub-context, there is currently no mechanism
to allow for that. Although you can name your context file as path#to#app.xml
to serve an application at /path/to/app, there is no way to auto-deploy a war
with the same name. ie: path#to#app.war.
See http://www.nabble.com/How-to-Deploy-WAR-using-a-sub-context-path--
tf4838797.html#a13843361 for further explanation of the issue.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 44021] - Deployer cannot deploy wars with #s
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=44021>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=44021
------- Additional Comments From ebenze@hotmail.com 2007-12-04 15:55 -------
Created an attachment (id=21230)
--> (http://issues.apache.org/bugzilla/attachment.cgi?id=21230&action=view)
Patch to resolve this bug / issue
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 44021] - Deployer cannot deploy wars with #s
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=44021>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=44021
------- Additional Comments From hoju@visi.com 2008-02-20 23:30 -------
I ran into this issue today after seeing that Tomcat supported such a concept in the Context documentation...
"Multi-level context paths may be defined using #, e.g. context#path.xml"
I figured it would work for WARs in the same way, such as context#path.war, which I found, of course, it didn't, other than using manual unpacking a manual creation of context#path.xml to match.
I've read all the comments in the email thread and Mark's findings below. I agree that it can be problematic, such as possible overwriting of files. Then again, anyone using this feature is doing it for special reasons and is likely to have read the documentation and understand the risks involved. And I'm ok with the fact that "/context" gets deployed as a context itself, in addition to "/context/path". This allows for serving common files related to the /path application as well as other applications that might exist under /context. More on that below...
One nice thing about this concept is that one can organize multiple related, but separate, webapps under a common path within a host. For example, I can have...
/myapps/index.html (linking to the various apps in this path)
/myapps/app1
/myapps/app2
/myfriendsapps/index.html (linking to the various apps in this path)
/myfriendsapps/app1
/myfriendsapps/app2
I put the /myapps/... structure under webapps and put myapps#app1.xml and myapps#app2.xml in the localhost conf directory. Seems to work just fine. The only problem is it is not possible to hot-deploy this.
What I'd like to see is the concept of uber-wars (my own term). That is, a WAR file containing other WAR files or directory structures representing multiple contexts within a common context. This would allow for hot deployment of these multi-path applications. So...
myapps.war
- index.html
- app1.war
- app2.war
OR
myapps.war
- index.html
- app1
- app2
A multi-path-named WAR file would be rare in this scenario, unless the multipath was 3 levels deep, though it could be supported. For instance...
myapps#mysubcontext.war
- index.html
- app1.war
- app2.war
Would result in...
/myapps/mysubcontext/index.html
/myapps/mysubcontext/app1
/myapps/mysubcontext/app2
Basically, WARS with WEB-INF in the root of the WAR file would be treated in the standard way and those with nested WEB-INF directories would be treated as uber-wars.
Ultimately, if my uber-war concept is rejected (maybe because of lack of official specification?... then again myapps#app1.war is non-standard anyway), then I still think that individual *hot* deployment of myapps.war, myapps#app1.war, and myapps#app2.war should be possible. As long as the risks are documented, I think it should be ok. Those doing things the standard way won't ever run into issues and those doing things the non-standard, multi-path, way will have read the documentation in order to have known about said non-standard way and can be assumed to have read the applicable caveats.
Here's my wholly non-biding +1 vote to include this patch and/or my uber-war concept in the next version of Tomcat6.
Jake
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 44021] - Deployer cannot deploy wars with #s
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=44021>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=44021
------- Additional Comments From thomas.freitag@kippdata.de 2008-02-22 01:54 -------
I observed some unexpected behaviour when deploying a webapp using the Tomcat
Client Deployer (TCD) package and hashes ("#") in the deployed context path of
the webapp (I observed this using 6.0.16). In my humble opinion, using hashes in
the path is not very usual, but this may be somewhat related to this topic and
easy to fix if somebody works on the original issue.
It is possible to deploy a webapp to a context path "/foo#bar" using TCD.
Undeploying using TCD of this webapp fails, because the path is truncated at the
hash (resulting in "/foo") which results in an error. Undeploying using the
manager webapp results in the same error. An additional problem is, that in case
a webapp ist deployed at the context path "/foo", it will be undeployed when
trying to undeploy the webapp deployed at "/foo#bar".
A possible workaround is to undeploy the webapp using both TCD and manager
webapp when the hash ist replaced by "%23".
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 44021] - Deployer cannot deploy wars with #s
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=44021>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=44021
hoju@visi.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hoju@visi.com
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 44021] - Deployer cannot deploy wars with #s
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=44021>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=44021
markt@apache.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|major |enhancement
------- Additional Comments From markt@apache.org 2007-12-11 14:28 -------
I have done some testing and there is a minor problem. If I deploy foo#bar.war
it works as expected but the expanded directory is seen by the auto deployer so
it deploys /foo as well. There is also the problem that foo#bar.war and
foo#bar#too.war will clash and possibly over-write each others files.
These problems are all part of the reason this functionality was not written for
the current version. I don't want to give the impression that this is impossible
or that it isn't worth trying to do but there are a few wrinkles to iron out yet.
I have changed the severity to enhancement. Ping me when you have an updated
patch or if you have any questions.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org