tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 44021] - Deployer cannot deploy wars with #s
Date Thu, 21 Feb 2008 07:30:55 GMT
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


Mime
View raw message