jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Cooper" <mart...@apache.org>
Subject RE: Using Image Taglib when J2EE application is inside (an unpacked) war file.
Date Wed, 09 Jun 2004 05:00:12 GMT
The right way to solve this in a manner that is guaranteed to be portable is
to use the web app's temp directory, or a subdirectory of it, rather than
trying to find other locations that may or may not work.

Per the servlet spec, the container is required to provide a temp directory
for each web app. Using that directory ensures that different web apps do
not step on each other's toes, even if they're running in the same
container. See section SRV.3.7.1 (in the 2.3 spec).

Attempting to use the file system in general, outside of the abovementioned
temp directory, is not guaranteed to be portable, for the simple reason that
there is no guarantee that there *is* a file system.

It is perfectly valid for a container to be implemented in an environment
where there is no regular file system, and where the temp directory might be
provided as RAMdisk. This might be the case in an embedded environment,
which, interestingly enough, is one of the scenarios in which Jetty is
stronger than most. (There would obviously be no option to explode any WAR
or EAR file in such a scenario, either.)

--
Martin Cooper


> -----Original Message-----
> From: Abey Mullassery [mailto:abey@mullassery.com]
> Sent: Friday, June 04, 2004 4:06 AM
> To: Tag Libraries Developers List
> Subject: Re: Using Image Taglib when J2EE application is inside (an
> unpacked) war file.
>
>
>
> The directory that Image taglib uses is not a cache. The final images
> are generated into it. This has great performance advantages.
>
> The image taglib does not use a servlet to serve the request for the
> image. It generates the images into a directory once during startup (if
> refresh attribute is not set) and the appropriate url is specified in
> the <img> html tag. The means that it is generated only when it is
> required and for the rest of the time it is served just like static
> images. This mimics the normal static scenario and is a LOT simpler.
>
> As you know the request for the image comes separately later after the
> html page is loaded by the browser. If the images are generated into
> another folder it would not be within the web site.
>
> Can it be specified in JBoss/Jetty to unpack the war?
>
> If not, the Image taglib may have to be changed to,
> 1. Use a servlet to serve the once generated images from an absolute
> directory (slightly slower)
> 2. Use the servlet to generate the images and stream everytime (much
> slower and lot of issues to solve)
> 3. Allow target folders outside the context and use server conf/settings
> to map a folder outside the webapp!!??
>
> But any of the above changes will increase the complexity of the
> implementation.
>
> Can anyone suggest any other better/ smart solutions?
>
>
> Abey Mullassery
> http://www.mullassery.com
>
>
> Matti Härö wrote:
> > Hi,
> >
> > In some of our services, we have JBoss/Jetty as application
> server. Jetty does
> > not unpack the war file of our application while in startup,
> like Tomcat does.
> > This results in Image Taglib being unable to create a directory
> "gen-images" for
> > caching the created, resized image. There is a "dir" attribute
> for the tag, but
> > this attribute is handled as relative to the context path,
> which points, again,
> > inside the war file. So, using the "dir" attribute does not
> help with the
> > problem. Is there a way to specify absolute directory for image
> caching, or is
> > there another way of being able to use the Image Tag library
> with environments
> > where the war files are never unpacked for execution?
> >
> > With best regards,
> > Matti Härö
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org


Mime
View raw message