My experience with this has been a blend of some of what's been said so far, with a bit of sugar on top.

I agree with those who say that the filesystem and a stock webserver (apache) are the way to server images - and all static content, imho. (ymmv) Particularly since your image data is dynamic (not part of your app but user data that is uploaded), this makes webapp deployment easier and even allows deployment of an unpacked war.

I use apache to serve all images, and an image manager object in the service layer of my app (as I believe Joe suggested as wel ). The image manager handles storing uploaded images to the a configured filesystem location as well as associating the related metadata with the business data.

The bit of sugar you might consider is a tag that uses a configured http prefix to generate the URL's for img tags.

In one application, I have a simple tag that composes product catalog image URL's, given a product instance, for example:

<img src="i:catalogImageURI product=${product}'"/>

That tag just uses attributes of the Product domain object to compose the URL, given the currently-configured http server that's handling images.

You can then tweak your webapp configuration to allow for your web container to serve the images out of your context root during development for example, but have apache serve the images in production.

- Ken

On Dec 1, 2004, at 12:12 PM, Woodchuck wrote:

hihi,

yea i also keep images on the fileserver.  it's nice and simple.  as
many others have said already, all that needs to go to the database is
any meta info about the image you require and any other info needed to
construct the image link for display.

no need for any servlet image<-->blob business.  when you need to
deploy or redeploy, just zip up the the images folder or just war the
whole thing and away you go.  can't get simpler than that.

i have also found websphere to be slower than tomcat.  it's not as
zippity as tomcat.  i'm willing to bet that it's because websphere has
a lot of @[EMAIL PROTECTED]@$&@% code in it.

woodchuck


--- Jim Barrows <[EMAIL PROTECTED]> wrote:



-----Original Message-----
From: Brady Hegberg [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 01, 2004 10:40 AM
To: Struts Users Mailing List
Subject: RE: Where to store and how to retrieve Images for web app

<snip/>


Does anyone know if there are advantages in particular app-servers
to
keeping your graphics on the filesystem versus in the database?

Well...let's see... local to server file system, no data xfer across network. Store image in DB and you have to pull image across net, then shove it out to user.

Depending on image size and network latency, the container won't make
any difference at all to performance.

If you're doing a lot of images, then you probably want to put Apache
in front.  I have told apache to redirect certain requests to the
images directory, while letting my web app write their.  Beats ths
stuffin out of writing a pass through servlet.  If apache and
app-server can't reside on same box, share drives or use something
like rsync to keep both boxes up to date.

As for app-server speed... I've found Websphere to be somewhat slower
the Tomcat.... then again.. it could be the @[EMAIL PROTECTED]@$&@% legacy code
I'm dealing with too.....

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





__________________________________ Do you Yahoo!? All your favorites on one personal page – Try My Yahoo! http://my.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to