Bug 44021 - Deployer cannot deploy wars with #s
Deployer cannot deploy wars with #s
Status: RESOLVED FIXED
Product: Tomcat 5
Classification: Unclassified
Component: Catalina
5.5.26
All other
: P1 enhancement (vote)
: ---
Assigned To: Tomcat Developers Mailing List
:
: 43013 (view as bug list)
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2007-12-04 15:34 UTC by Eric Benzacar
Modified: 2008-08-14 01:32 UTC (History)
4 users (show)



Attachments
Patch to resolve this bug / issue (4.94 KB, patch)
2007-12-04 15:55 UTC, Eric Benzacar
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Benzacar 2007-12-04 15:34:01 UTC
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.
Comment 1 Eric Benzacar 2007-12-04 15:55:14 UTC
Created attachment 21230 [details]
Patch to resolve this bug / issue
Comment 2 Mark Thomas 2007-12-11 14:28:54 UTC
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.
Comment 3 Jacob Kjome 2008-02-20 23:30:55 UTC
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
Comment 4 Thomas Freitag 2008-02-22 01:54:46 UTC
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".
Comment 5 Eric Benzacar 2008-03-06 06:38:14 UTC
Hi Mark,

Sorry for the delay in getting back to you on this; I hadn't receive the automated notif from Bugzilla for some reason, so I didn't see you had commented on this.

To address your concerns of my patch; I didn't have a set of specs to follow, so I tried to do what I thought would make the most sense, and attempt to replicate the current behaviour of Tomcat.

Regarding the auto-deployment of /foo:
This is the current behaviour of Tomcat.  If I manually put a war into /foo/abc.war and create a foo#war.xml context file, Tomcat's auto-deployer will deploy both foo/abc.war and foo/.  As far as I see it, this is expected behaviour.

Regarding a clash of foo#bar.war and foo#bar#too.war, that is one thing that I had not considered or taken into account.  I can understand that to be confusing.  The best suggestion I can have for that is to have the deployment of foo#bar#too.war fail if there is already something that is deployed at foo#bar.war,  In fact, I am surprised that it does not already do this.  

Please let me know how you expect Tomcat to behave in the above circumstance, and I'll see if I can update my patch for that.  I will still be working on patching 6.0.14 however; I expect that my updates should be easily transferrable to the 6.0.16 branch by someone a little more knowledgable of Tomcat's internal intracacies.

Thanks,

Eric
Comment 6 Mark Thomas 2008-03-11 15:27:09 UTC
(In reply to comment #5)
> Regarding the auto-deployment of /foo:
> This is the current behaviour of Tomcat.  If I manually put a war into
> /foo/abc.war and create a foo#war.xml context file, Tomcat's auto-deployer will
> deploy both foo/abc.war and foo/.  As far as I see it, this is expected
> behaviour.
This is currently an invalid configuration. The way I see this working would be a foo#abc.war file in the appBase which creates/uses a foo.abc.xml context file.

> Regarding a clash of foo#bar.war and foo#bar#too.war, that is one thing that I
> had not considered or taken into account.  I can understand that to be
> confusing.  The best suggestion I can have for that is to have the deployment
> of foo#bar#too.war fail if there is already something that is deployed at
> foo#bar.war,  In fact, I am surprised that it does not already do this.
I think this needs to work. Maybe if the files are expanded to directories named foo#bar and foo#bar#too? This could also fix the autodeployment of foo problem.
  
> Please let me know how you expect Tomcat to behave in the above circumstance,
> and I'll see if I can update my patch for that.
Done. See above ;)

> I will still be working on
> patching 6.0.14 however; I expect that my updates should be easily
> transferrable to the 6.0.16 branch by someone a little more knowledgable of
> Tomcat's internal intracacies.
That's fine. The code hasn't changed much, if at all. When you get this working, I'll port it to the latest 6.0.x
Comment 7 Eric Benzacar 2008-03-12 08:15:24 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > Regarding the auto-deployment of /foo:
> > This is the current behaviour of Tomcat.  If I manually put a war into
> > /foo/abc.war and create a foo#war.xml context file, Tomcat's auto-deployer will
> > deploy both foo/abc.war and foo/.  As far as I see it, this is expected
> > behaviour.
> This is currently an invalid configuration. The way I see this working would be
> a foo#abc.war file in the appBase which creates/uses a foo.abc.xml context
> file.

Really?  Why would that be an invalid configuration?  I was under the impression that the whole point of the # in the context file names was to allow sub-paths to the war file.  Why are you looking to change that to using "." instead?


> > Regarding a clash of foo#bar.war and foo#bar#too.war, that is one thing that I
> > had not considered or taken into account.  I can understand that to be
> > confusing.  The best suggestion I can have for that is to have the deployment
> > of foo#bar#too.war fail if there is already something that is deployed at
> > foo#bar.war,  In fact, I am surprised that it does not already do this.

> I think this needs to work. Maybe if the files are expanded to directories
> named foo#bar and foo#bar#too? This could also fix the autodeployment of foo
> problem.

The problem with this, however, is that if foo#bar.war is deployed, you have to assume that any path under foo/bar belongs to the foo#bar.war file.  For instance, foo#bar.war might have a path as foo/bar/eric/file.jsp.  This is the current way that tomcat seems to work.  Similarly, it might have a file under foo/bar/too/file.jsp, which would be properly served.

Now, if suddenly we allow deployment of foo#bar#too.war, you would assume that to mean any paths under foo/bar/too would belong to the foo#bar#too.war application, and they should all be served under that war deployment.  In which case, you'll run into a conflict.

I'm not convinced that allowing foo#bar.war to be deployed as well as foo#bar#too.war will not cause significant conflicts and errors for some people who deploy conflicting paths without realizing it.


Thanks,

Eric
Comment 8 Mark Thomas 2008-03-12 08:29:05 UTC
(In reply to comment #7)
> Really?  Why would that be an invalid configuration?  I was under the
> impression that the whole point of the # in the context file names was to allow
> sub-paths to the war file.  Why are you looking to change that to using "."
> instead?

<<appBase>>/foo/abc.war is invalid
The "." was a typo on my part. I meant foo#abc.xml

> Now, if suddenly we allow deployment of foo#bar#too.war, you would assume that
> to mean any paths under foo/bar/too would belong to the foo#bar#too.war
> application, and they should all be served under that war deployment.  In which
> case, you'll run into a conflict.

No conflict - the spec is quite clear. The request is handled by the context with the longest context path that matches the request. Under the current code you can deploy foo.xml, foo#bar.xml and foo#bar#too.xml and it will work (providing the docBases are outside the appBase).

What the current code doesn't handle, and your patch needs to fix, is dropping the equivalent wars into the appBase. The more I think about it, the more I think expansion of a#b#c.war to a dir named a#b#c is the way to fix this.
Comment 9 Jacob Kjome 2008-03-12 19:40:02 UTC
I presume that when Tomcat deploys a#b#c.war to a dir named a#b#c, it will also deploy META-INF/context.xml contained in a#b#c.war to ${CATALINA_BASE}/conf/Engine/host/a#b#c.xml, correct?

Jake
Comment 10 Mark Thomas 2008-03-13 00:56:22 UTC
(In reply to comment #9)
> I presume that when Tomcat deploys a#b#c.war to a dir named a#b#c, it will also
> deploy META-INF/context.xml contained in a#b#c.war to
> ${CATALINA_BASE}/conf/Engine/host/a#b#c.xml, correct?

That is how I envisage it working.

Comment 11 Mark Thomas 2008-05-05 11:17:51 UTC
*** Bug 43013 has been marked as a duplicate of this bug. ***
Comment 12 Mark Thomas 2008-05-05 12:01:28 UTC
I have committed a fix for this to trunk and proposed it for 6.0.x and 5.5.x.

If you rea able to test the fix and report back that would be great.
Comment 13 Mark Thomas 2008-05-15 13:52:26 UTC
This has been committed to 6.0.x and will be included in 6.0.17 onwards.
Comment 14 Mark Thomas 2008-08-14 01:32:32 UTC
This has been fixed in 5.5.x and will be included in 5.5.27 onwards.