Hi Johnny, hi everybody
I took the images example to explain and simplify the problem, but
actually I may need to include different contents, which may be
static - like images, flash animations, html pages - but may also be
jsp pages for exemple, and some of these contents are likely to be
generated by another web application.
This works fine for years with oc4j / orion, so we would rather have
the lesser to change before we can switch oc4j for tomcat. In fact if
we can't manage to do that, it may be a reason to discard tomcat from
our choice list, because some part of our application relies on
virtual directories.
Best regards
Sylvain
At 10:14 11/04/2007, Johnny Kewl wrote:
Hi sylvian....
When developing I do this
request.getContextPath() + uri;
but I wrap the request.getContextPath() in a little routine like say
imageMap(String uri) and use that in my JSP's
Thats cool because if I change the context path the app doesnt break...
BUT... I do it for a much better reason.
When I'm done making a Tomcat app I move all the images to the
Apache server...
And then just change imageMap(String uri) to point to the Apache Web
server url...
Apache Web Srvr is damn good at delivering images and Tomcat speeds
up nicely when you do this.....
I actually cant believe that people use cross context stuff for
images.... if you dont want to use apache, the you could make a
single webapp, dump all your images in there, and just address that
in your other apps, http://myImageTomcatServer/image/xxx.jpg
Let the browser join the images for you... if you have a look at web
pages you will often see the images come from a different server...
like look at web counters for example.
Heres another example.... if I make a captcha generator (you know
those little images that have numbers in them) then I make a
seperate servlet called CapchaGen.jpg.... and in my other apps I
call that URL.... image appears in the browser.
What document is this that you talking about... sucking images from
other webApps through context sharing... sounds crazy?
Good luck
[EMAIL PROTECTED]
----- Original Message ----- From: "Sylvain Roche" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <users@tomcat.apache.org>
Sent: Tuesday, April 10, 2007 7:23 PM
Subject: virtual directory
Hi
this seems a very classical problem for tomcat users, but I
couldn't find on the web a solution which satisfies me.
We plan to host multiple applications, on a tomcat box. These
applications may all need an images directory. But of course each
of them has a different images directory.
What we want to do is to deploy different versions of each
application, without the need to move the images.
The crosscontext context solution, which is the one given
everywhere, does not correspond to our need, because, as far as I tried it
- I may need an unknow depth for the point I will make the link,
for example, it could be /images/layout/DE_de
- I need to have a mapping inside my web-app, ie inside the context
rather than at the same level
- when I read the doc, it seems to me that this is a workaround, a
misuse of something that was made for being able to dispatch
requests to another application - what I want is only to link
something out of my application deployment path as if it was
inside. I don't know if it is wise to rely on this workaround for long term
- the same mapping (/images) has to be different for each application
basically this is what is performed on Oracle's OC4J with the
virtual-directory directive, on weblogic with
virtual-directory-mapping. Actually I found some kind of virtual
directory on every j2ee server but tomcat. I can't imagine that
this problem has no solution other than the cross context. I may
have missed something, but where ?
Best regards
Sylvain
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
