-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Affan,
[EMAIL PROTECTED] wrote:
> I have an application which contains a bunch of images for products whose
> filenames come from the database. Right now the images are stored inside
> the WAR file when deploying the application
Ugh.
> We don't care about versioning image files since they are maintained
> by a third party.
Yeah, get those things out of CVS.
> I wish to know what approach would be the best to keep the images outside
> of the built WAR and still being able to access them easily from the
> application. Some approached I thought of were:
>
> - Maintain images in a separate CVS module. When deploying the application
> explode the WAR file and include the images and re-war the war file.
Why bother with CVS? Why bother with a WAR? Why bother with deployment?
Just keep them in the same place all the time.
> - Store images in a separate folder outside of the context root and refer
> to them via a symlink (platform dependent) or a configuration property in
> the application (platform independent).
The symlink is not necessary.
I think you should just allocate a portion of your URL-space to these
images. Something like "/images", maybe.
You ought to be able to divert a particular URL space to another
directory which is external to your webapp (i.e. not stored in the
"myapp" directory under your servlet container's deployment directory).
For instance, in Apache httpd, you could do this:
Alias /images /full/path/to/your/image/repository
I would imagine that Jakarta Tomcat has the same capability, though I
have no idea how to configure it.
If you do something like this, you can keep your images in a directory
structure that is completely independent of your webapp, and doesn't
have to be handled specially during deployment of new webapp versions
(or even additional webapps).
If you make the "URL prefix" for those images dynamic within your
application, you can do something like this:
<a href="${image-prefix}/{$image-path}">View Image</a>
Your image-prefix could even be fully-qualified (i.e. starting with
http://) and you could use a different server altogether to serve those
images. In fact, if you have a third-party who maintains your images,
you might even be able to serve these images from /their/ servers.
Hope that helps,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFU8d39CaO5/Lv0PARAobKAJ9Je01VRGJf4e4ctgVwraZdXF7ouACghuWA
DFJwCQB57GQWG8N9MjX0ILk=
=eceU
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
