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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
