Replies inline.
Note, people on this mailing list frown on top-posting (see items 6 and
7 here: http://tomcat.apache.org/lists.html). It does make the reply and
response difficult to follow without rereading the entire thread.
Please either reply inline or at the end, so people late to the party
(or those of us with short / fragmented memory :-p) can remember what's
going on.
On 12/16/2013 1:00 PM, Ray Holme wrote:
I have been trying three scenarios. So far one works (least security and not
good for all OS versions).
Again thanks to both Marks for the pointers, but I am afraid they are not
working yet.
My goal is to enable one directory to be used which is outside the application
(and tomcat too)
.../webapps/mywebapp hierarchy
which mywebapp.war will replace with a new release
use 1: to store/retrieve images locally to a machine
under application control (db stores names of files)
use 2: to store a static movie - demo (no update - this is the simple test
case I try)
The goal is to get this stuff out of the war file (leaving nothing, an empty
dir, or a link as needed - see below). All of the below require apache/tomcat
to be down when you make the changes, then restart to test
a) IF you have linux (or unix) or osx - you can do symbolic linking
simply move the directory and link (my case below):
cd ..../webapps/mywebapp; mv images /opt; ln -s /opt/images
and to enable symbolic linking to other directories on your machine (all of
them)
create a ..../webapps/mywebapp/META-INF/context.xml file (or edit the one
you have)
<?xml version="1.0" encoding="UTF-8"?>
<Context allowLinking="true"> </Context>
advantages for this method: works simply
faults: MS os's don't do symbolic; also opens up ALL linking (security
issues? probably)
BUT THERE ARE 2 other SAFER more restrictive ways below, both also done in
the same context.xml file (if I can get either of them to work - the
examples often say the server.xml file, but there is only one of them in the
top tomcat conf directory, which has NO context references - but if they go
there, then path= probably needs to be specified.)
b)
<?xml version="1.0" encoding="UTF-8"?>
<Context aliases="/images=/opt/images" />
</Context>
c)
<?xml version="1.0" encoding="UTF-8"?>
<Context <Resources className="org.apache.naming.resources.VirtualDirContext"
extraResourcePaths="/images=/opt/images" />
</Context>
I hope that you meant:
<Context>
<Resources className="org.apache.naming.resources.VirtualDirContext"
extraResourcePaths="/images=/opt/images" />
</Context>
-------------------------
These are both more security conscious and might should work for MS
(with MS correct paths such as d:\images)
Which of these is simpler and/or better - I have no idea. Net comparisons
don't say.
but the VirtualDirContext.html pages say: DO NOT USE FOR PRODUCTION
of course- they don't say why NOT
I'm not sure that this is valid any more.
Why both require the escaped greater than sign, beats me too. "/>"
It's not an escaped greater than sign. It's how one closes an empty tag
in XML. You could also have written it the following way:
<Context>
<Resources className="org.apache.naming.resources.VirtualDirContext"
extraResourcePaths="/images=/opt/images">
</Resources>
</Context>
I would have thought it would be simply ">" on the 2nd and 3rd lines resp.
(b and c)
NEITHER OF THESE WORKED FOR ME! (so far and I have tried many variants)
Do I have to have the symbolic link (in Linux - I did for a) obviously)
or should this be a plain empty directories (like Linux/Unix mount points)
or should there be no "../webapps/myapp/images" anything at all?
There should be nothing in your web application at all. However,
according to the documentation, the alias path (and by extension, the
VirtualDirContext) are searched first, so it shouldn't matter as long as
the target directory exists.
In the manual version there are more parameters, but most folks say to drop
"path=mywebapp"
and the rest seem to not be relevant to what I am doing so I cut them out.
Maybe that is the problem.
Here is the example I found under VirtualDirContext online
<Context path="/mywebapp" docBase="/Users/theuser/mywebapp/src/main/webapp" >
<Resources className="org.apache.naming.resources.VirtualDirContext"
extraResourcePaths="/pictures=/Users/theuser/mypictures,/movies=/Users/theuser/mymovies"
/>
<Loader className="org.apache.catalina.loader.VirtualWebappLoader"
virtualClasspath="/Users/theuser/mywebapp/target/classes" />
<JarScanner scanAllDirectories="true" />
</Context>
The example you quoted was for the directory structure listed above the
example.
Do not use path if you're deploying in the appBase directory defined in
server.xml ($CATALINA_BASE/webapps by default), which you are.
Do not use docBase at all - this is for locating an application outside
of the appBase directory defined in server.xml.
Now using the following context.xml:
<Context>
<Resources className="org.apache.naming.resources.VirtualDirContext"
extraResourcePaths="/images=/opt/images" />
</Context>
Your application should end up with <img> tags looking like the following:
<img src="images/picture1.png" alt="Picture 1">
Things are a bit nicer if you use the core tag libraries, and of course
if you're using HTML 5 you'll need to close the tag (the above is HTML
4.01 Transitional).
I wrote a quick web application to access some pictures in my home
directory with:
<?xml version="1.0" encoding="UTF-8"?>
<Context>
<Resources className="org.apache.naming.resources.VirtualDirContext"
extraResourcePaths="/pictures=/home/mdeggers/Pictures"/>
</Context>
This was done on Fedora 19, Tomcat 7.0.42, JRE 1.7.0_45, and it worked
as advertised.
I also tried the following, which worked:
<?xml version="1.0" encoding="UTF-8"?>
<Context aliases="/pictures=/home/mdeggers/Pictures">
</Context>
Links in my index.jsp:
<img src="pictures/snapshot1.png" alt="snapshot 1"><br>
<img src="pictures/snapshot2.png" alt="snapshot 2"><br>
<img src="pictures/snapshot3.png" alt="snapshot 3"><br>
<img src="pictures/snapshot4.png" alt="snapshot 4"><br>
I normally use the core tag library, so those links would be:
<img
src='<c:url value="/pictures/snapshot1.png"/>' alt="snapshot 1"><br>
<img
src='<c:url value="/pictures/snapshot2.png"/>' alt="snapshot 2"><br>
<img
src='<c:url value="/pictures/snapshot3.png"/>' alt="snapshot 3"><br>
<img
src='<c:url value="/pictures/snapshot4.png"/>' alt="snapshot 4"><br>
. . . . just my two cents.
/mde/
On Sunday, December 15, 2013 7:39 PM, Christopher Schultz
<ch...@christopherschultz.net> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Martin,
On 12/15/13, 4:52 PM, Martin Gainty wrote:
Mark I assume you're referring to Virtual DirContext...? <Context
path="/mywebapp" docBase="/Users/theuser/mywebapp/src/main/webapp"
You shouldn't use the "path" attribute, here. You should know this.
<Resources
className="org.apache.naming.resources.VirtualDirContext"
extraResourcePaths="/WEB-INF/classes=/Users/theuser/mywebapp/target/classes,/pictures=/Users/theuser/mypictures,/movies=/Users/theuser/mymovies"/>
VirtualDirContext
is not necessary, but it is one option.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJSrkvIAAoJEBzwKT+lPKRYZ4cP/1SvH4mwBFUIjmtiGnBfa3vU
IHwSsyfHaoyO55p1/1AasP6avv8rjpMl9i8d+kmYolIiYMF461UCGTuE44SzHP1Y
O1/VayieLS3A/pn2YS86LqfXTuuKD4pWQ93TDEihchpXpJ+/B3sMfJeCzvRRYue7
PZ32luoXvsHEgA2nt7Qpp88Nz+9RggYAw5KlnTrnndqyMl8FyWLkTccpaqTthOnW
LcZgieAW7ySWZRbyAiXNEsk6kVDTat9z/EAeDmMWqN43LJikxLh4Glez3jv80mhy
cNtZ43mqroyCRF82nSO6eHxeSxIh70kdVaz6/x7QaBNAWIe96DHlQFTZwBnClzwY
T5uHYEBwSTfZ7GFlT/z+zGWxhX0fme9q9auZyXnufEHqPadKWkGdbjFN4dgifYm6
Js/O5o2TsCK9RKYbNomPygZ+fek6AqtFtEOvimyFd0Udml4hoQKzTOc81Rb/Dhx9
J/u47Oj754kTL18mv0Ci1ZOB4IQ1jO8YZDz35RU/9MZeoQ+LKkSxZHZTL1/PaH0u
h15XSAWv5MVHelPJM7WZWfrQdGAuYKUR+QOB1T4zoW+HKkcjsY7pilO3FJvrv84Y
+Xei2lxZLFPjF8c50HYuawqt5/un9vvARVofo2Hb5xr0E6gNxxma8X7LvIPWJ5YZ
3ii7LoCyfyTASfv7sPk0
=wGs5
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
