-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chuck,

On 5/13/2011 10:36 AM, Caldarale, Charles R wrote:
> "
> This attribute provides a list of external locations from which to
> load resources for this context. The list of aliases should be of the
> form "/aliasPath1=docBase1,/aliasPath2=docBase2" where aliasPathN
> must include a leading '/' and docBaseN must be an absolute path to
> either a .war file or a directory.
> 
> A resource will be searched for in the first docBaseN for which
> aliasPathN is a leading path segment of the resource. If there is no
> such alias, then the resource will be searched in the usual way.
> "
> 
> If you set each /aliasPath to the same .war file or directory, this
> may achieve your goal.

A dirty little trick that might actually work.

However.

I would expect that the /aliasPathN would be rooted in the webapp's
context path URI space, so if you had a webapp deployed as, say "/foo"
and then aliased "/bar" to foo.war, you'd end up with the /foo webapp
being available on both /foo and /foo/bar.

This feature was designed to allow URI spaces to be mapped to a physical
directory outside of the deployed webapp, say, for static content stored
elsewhere. That's why I suspect that the context path will be required.

Now, one might still be able to use this technique if you deploy to ROOT
and alias /both/ URI prefixes you want to use, like this:

path="ROOT" aliases="/foo=path/to/war, /bar=path/to/war"

In this case, the webapp is available on all of these virtual context paths:

  /
  /foo
  /bar

I would also suspect that request.getContextPath would return "" in all
uses.

It may be better for the OP to just use UrlRewrite.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk3NTMQACgkQ9CaO5/Lv0PB81QCfXa74u/5auaLNdEjmF0aBXvHB
23MAnjmiQcqPLzJ4xmN8L4SnXV6TDP+r
=jrah
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to