http://community.jboss.org/message/192491#192491

and as described in JRun’s “jrun-web.xml” documentation here:

http://www.adobe.com/livedocs/jrun/4/Assembly_and_Deployment_Guide/descriptors4.htm

There is a major different between web.xml and jrun-web.xml in that web.xml is server/vendor implementation agnostic and will thus deploy in any j2ee compliant server while jrun-web.xml is much like jboss-web.xml, and weblogic.xml in that they are vendor specific deployment descriptors and are therefore unusable on any other app servers. It’s like trying to speak Korean to an Icelandic person, they won’t understand what’s being described by the descriptors.

It appears from that unanswered JBoss post that it has never been addressed. The use of virtual-mapping is not part of the j2ee standard, and is therefore not implemented in JBoss. It appears the closest thing you can do is configure a jboss external directory as a context as described in this article:

http://community.jboss.org/wiki/ExternalDirectories

Essentially you end up creating a mapped context to a local directory. I think this still takes the compilation of JSPs off the table as there is no way for JBoss to dynamically load in those files and compile them into servlets.

Its important to know a little bit about how jboss works with deployments – JBoss takes each deployable artifact and copies them into the instance/tmp directory. As JBoss loads them into the instance/tmp directory they all get loaded into ram and if configured to auto detect file updates, will reload the modified file on demand. JSPs are a litlte different – these guys are read in and compiled into servlet code and then written to disk in the instance/work directory, one folder for every mapped domain served by the instance. In order for external JSP directories to work as they do in the JRun implementation there would need to be some kind of connector that would snap on to the web.xml parsing engine which would figure out how to load local configured directories into the JBoss servlet container – compiling those jsps and then saving them into that instance/work directory. Such a connector does not exist as far as I know.

Now, it seems to me, Apache mod_jk is serving relative paths and JBoss web cannot make sense of the path by looking at the web.xml. I looked at adding virtual directory definitions as part of Tomcat context, but JBoss 5.1.0 does not support it.

At this point, my option does not include redoing the existing structure or bringing files into the WAR.

How would I make Apache or JBoss serve/understand the real path and pick files up? I wld love to get rid of these symlinks.

So the simple answer is: no. Not unless you want to load the jsp file into a java 1.6 dynamic compiler object, and compile all your jsp code yourself and then somehow hook into jboss’ servlet container framework so you can persist the compiled servlet. The method in this article gives you access to a directory, from which you can load items into a File object. This works well for reading into a Properties object, but not so much for compiling jsps.

In a nutshell if you end up needing to go outside the web application’s space, into say, a local /www httpd web directory, prefer the fully qualified local server/hostname instead of using the internal file structure of your OS. By trying to use the local file system instead of a dedicated web server, your application will collapse under load. Web servers are meant to handle much heavier stress than the OS’s file system – symbolic links included, as web servers implement much more rigorous caching mechanisms and access time saving techniques. You might also be breaking the j2ee paradigms by making your application installed base dependant, not making it easy to deploy into a new environment.

Can you describe your environment a little more? Its unusual that you’d have to stick all your jsps and resources somewhere other than a war file. There is definitely a better way than having to resort to symbolic links.