following on from this,

have a simple virtual host with a context element inside, simple one line

symlinks work fine on one level, so my app directory is x, everything is served from x including symlinks to physical directories or files.

however if a symlink under x points to another symlink which then points to a physical directory, i get a resource not found error.

this is the same behaviour for all tomcats 5.5 + works fine in tomcat 5.019/28
any ideas would be much appreciated

oli

Using “allowLinking=true” in context.xml of tomcat 6, I am able to access soft links, within the application project directory.
but the problem is when I undeploy the application by deleting only project.war file, tomcat is deleting all the contents inside the soft links along with that project directory, but for me it’s causing the serious problem by deleting the valuable web content.

Let me know if you have any clue on this.

Thanks
Ningappa

Just wanted to thank you both for the info on the allowLinking setting.

We run Australia’s largest/oldest java hosting company and have a customer on a dedicated server who write and operate
a CMS.

Usually all their sites run under a single account, but they wanted a way to have a separate account (separate Host entry)
which uses the WEB-INF, META-INF and data folder from their main CMS account.

The purpose was so that their client could log in using FTP and create additional folders of static content.
eg: http://www.example-domain.com/promo

We found at first that we could symlink META-INF with no problems, but symlinking WEB-INF ended up deploying an
application with no name (which did not correctly start up). The other alternative was to copy the WEB-INF folder
into the new webapps_someclient/ROOT folder, but this meant that any code updates needed to be deployed to
every Host set up in this way.

After adding the allowLinking flag however, it all works fine.

As an added benefit, the FTP service has not been set to follow symlinks, so their client can now log in, see the
META-INF, WEB-INF and data folder links, but cannot change-directory to them, and therefore cannot download
or edit the application classes.

Also – good advice by DenisH. This setup is on Linux so does not affect the security.

We recommend the use of context.xml as it’s the most effective way of allowing customers to upload their applications,
either unpacked or in a WAR. Other alternatives are placing context files in the conf folder, which limits what customers
can do, or in server.xml (yuck).

One recommendation I have however, is to remove path=”/myapp” from your Context tag. It is unnecessary and may
cause headaches if you relocate the application. If you leave it out, the path defaults to whatever the application
path is relative to the webapps folder.

eg:
/webapps/ROOT – the META-INF/context.xml for this app will default to “/”
/webapps/myApp – the META-INF/context.xml for this app will default to “/myApp”

… so leave the path attribute out, then you can copy myApp to myOtherApp and the application will still work properly
without any modifications to it’s context.xml file.

The context.xml file is also a great place for JNDI DBCP datasource settings, and Tomcat Realms security file/database location
settings.

Regards,
Neale

And second, in the migration documentation from 5.5 to Tomcat 6, it says “When using a shared webhosting environment, it is recommended that usage of context.xml inside a WAR is forbidden (using the deployXML attribute of the Host element)”. Presumably this is because it would allow badly behaved configurations to be loaded?

So, just be aware of these pieces of advice if you are going to use the context.xml and allowLinking.