ImageTag updated to use web app's temp dir (was Re: Using Image Taglib when J2EE application is inside (an unpacked) war file.)

[Abey Mullassery <ab...@mullassery.com>]

I have updated the ImageTag to use the web app's temp directory to save 
images. The preliminary version has been checked. You can try out the 
examples (or read the doc) to see how it works.


Martin,
    Thanks for your timely and very useful suggestion.




The change brought in some new issues. I tried to resort to the simplest 
implementation (that I could think of) possible. Please let me know your 
comments to the ones listed below (issue-implementation pairs)


1. The web app's dir is out of the context and hence a plain static url 
cannot point to a image saved in it.

Added an ImageServlet that would fetch and serve the image and the urls 
"written" by the ImageTag would point to it. For eg.
src="/image-examples/servlet/org.apache.taglibs.image.ImageServlet?image=splash-new-gray.jpg"


2. Since I could not think of a way the Image tag could access or find 
the name of the servlet or a servlet mapping (that a user could specify 
in the web.xml) urls pointing to 
"servlet/org.apache.taglibs.image.ImageServlet" has to be used.

Image Tag "looks" for a context parameter "ImageServletMapping". If it 
is absent it defaults to 
"servlet/org.apache.taglibs.image.ImageServlet". As given in the 
image-examples.war's web.xml, if it has something like

   <context-param>
     <param-name>ImageServletMapping</param-name>
     <param-value>/gen-image</param-value>
   </context-param>

   <servlet>
     <servlet-name>ImageServlet</servlet-name>
     <servlet-class>org.apache.taglibs.image.ImageServlet</servlet-class>
   </servlet>

   <servlet-mapping>
     <servlet-name>ImageServlet</servlet-name>
     <url-pattern>/gen-image/*</url-pattern>
   </servlet-mapping>

urls such as
src="/image-examples/gen-image?image=splash-new-gray.jpg"
is generated/used.


3. The ImageServlet might be slower than a webserver serving a static image.

Tried to use compressed (gzip) streaming to minimize the streaming time 
and hoped that it would help.


4. Not sure if the existing usage of generating images into a local 
directory within the context should be discontinued since I GUESSED that 
a lot of people might like to use it if they can do without the servlets 
and so on.

Current implementation uses the local directory (as it was before this 
update) if the "dir" attribute is specified. If not, the ImageTag 
defaults to the use of web app's temp directory and the usage of the 
ImageServlet.




Note: This is still WIP and hence may take a few more days to update 
some additional attributes to specify servlet mapping/ name, support 
directories within the temp dir and update all the documentation.

Let me know your comments.


Abey Mullassery
http://www.mullassery.com


Martin Cooper wrote:
> 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

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