JSP responding as a image MIME type

[Michael Lepore]

I don't seem to be able to have a JSP respond as an image the same way I can
with a servlet. It seems as if you can't get the output stream the same
way.

SAMPLE CODE:

<%
java.awt.Frame frame = null;
java.awt.Graphics g = null;

try
{
System.out.println(module+",get output stream...");
java.io.OutputStream ost = response.getOutputStream();

System.out.println(module+",Set Content to image/jpeg...");
response.setContentType("image/jpeg");

System.out.println(module+", Create hidden frame...");
frame = new java.awt.Frame();
frame.addNotify();


System.out.println(module+", draw image...");
java.awt.Image image = frame.createImage(400,60);
g = image.getGraphics();

//Draw "Hello World" to the off-screen graphics context
g.setFont(
new java.awt.Font("Serif",java.awt.Font.ITALIC,48));

g.drawString("Hello World",10,50);

System.out.println(module+",create encoder...");
com.sun.image.codec.jpeg.JPEGImageEncoder encoder =
com.sun.image.codec.jpeg.JPEGCodec.createJPEGEncoder(ost);

System.out.println(module+",encode and output...");
encoder.encode((java.awt.image.BufferedImage)image);

System.out.println(module+",finished.");
}
catch(Throwable t)
{
System.out.println(module+", EXCEPTION: "+t);
}

if(g!=null)g.dispose();
if(frame!=null)frame.removeNotify();
%>

Throws exception:
doJPEG.jsp,get output stream...
java.lang.IllegalStateException: getWriter() was already called

[Larne Pekowsky]

In article <399ad6ef$1@news.devx.com>, Michael Lepore <leporem@saic.com> wrote:
>
>I don't seem to be able to have a JSP respond as an image the same way I can
>with a servlet. It seems as if you can't get the output stream the same
>way.

Hi Michael,

The problem here is that your JSP engine is going to try to create the
'out' variable, which will be an instance of some class that
implements JspWriter, which manages a bunch of state information about
what's been written, what needs to be flushed, and so on. Grabbing
the underlying output stream interferes with this mechanism.

Fortunately, there are two easy ways around this. The first is to
send all output through "out." In your case, you could replace

> java.io.OutputStream ost = response.getOutputStream();
>
> com.sun.image.codec.jpeg.JPEGImageEncoder encoder =
> com.sun.image.codec.jpeg.JPEGCodec.createJPEGEncoder(ost);
>
> encoder.encode((java.awt.image.BufferedImage)image);

With something like

java.io.ByteArrayOutputStream ost =
new java.io.ByteArrayOutputStream();

com.sun.image.codec.jpeg.JPEGImageEncoder encoder =
com.sun.image.codec.jpeg.JPEGCodec.createJPEGEncoder(ost);

encoder.encode((java.awt.image.BufferedImage)image);

out.print(ost.toString());

This is probably the safest approach, and is very much in the "JSP
spirit", since all output is ideally supposed to go through the
JspWriter. This means you'll be able to use jsp:includes and
forwards, even when dealing with binary data.

The other approach, less safe but easier, is to make sure there is no
data after your closing %>. No spaces, no newline or carriage
returns, nothing. At least under current version of Tomcat, this
prevents the JspWriter from being used, which avoids the problem.
This may or may not work with other JSP engines.

By the way, you should probably set the mime type before calling
response.getOutputStream(). In this case it doesn't really make a
difference, but all headers must be set before any data is sent, and
putting all the response.setX() stuff at the top can avoid some
hard-to-find problems later.

- Larne

[Fernando Ribeiro]

Following the first approach (simpler, sure) you can send any kind of data
even a .doc file just changing the MIME type. This "you could even use jsp:include
following this approach" seems quite good and is new to me. I will try it
tomorrow.

I am not sure, although, I have understood it the way I should. Does this
mean I could include the content of a second image file in my output stream
which I will write a first image to? It would be quite nice but I am sure
it depends on the implementation of the jsp:include tag. I have never taken
a look at the generated servlet when using a jsp:include tag to see what
is done by the jspc with that.

Thanks for the info. A friend of mime is now reading your book and told me
it is quite great. Congratulations.

Fernando Ribeiro
fribeiro@bol.com.br

larnep@canetoad.canetoad.com (Larne Pekowsky) wrote:
>In article <399ad6ef$1@news.devx.com>, Michael Lepore <leporem@saic.com>
wrote:
>>
>>I don't seem to be able to have a JSP respond as an image the same way
I can
>>with a servlet. It seems as if you can't get the output stream the same
>>way.
>
>Hi Michael,
>
>The problem here is that your JSP engine is going to try to create the
>'out' variable, which will be an instance of some class that
>implements JspWriter, which manages a bunch of state information about
>what's been written, what needs to be flushed, and so on. Grabbing
>the underlying output stream interferes with this mechanism.
>
>Fortunately, there are two easy ways around this. The first is to
>send all output through "out." In your case, you could replace
>
>> java.io.OutputStream ost = response.getOutputStream();
>>
>> com.sun.image.codec.jpeg.JPEGImageEncoder encoder =
>> com.sun.image.codec.jpeg.JPEGCodec.createJPEGEncoder(ost);
>>
>> encoder.encode((java.awt.image.BufferedImage)image);
>
>With something like
>
> java.io.ByteArrayOutputStream ost =
> new java.io.ByteArrayOutputStream();
>
> com.sun.image.codec.jpeg.JPEGImageEncoder encoder =
> com.sun.image.codec.jpeg.JPEGCodec.createJPEGEncoder(ost);
>
> encoder.encode((java.awt.image.BufferedImage)image);
>
> out.print(ost.toString());
>
>This is probably the safest approach, and is very much in the "JSP
>spirit", since all output is ideally supposed to go through the
>JspWriter. This means you'll be able to use jsp:includes and
>forwards, even when dealing with binary data.
>
>The other approach, less safe but easier, is to make sure there is no
>data after your closing %>. No spaces, no newline or carriage
>returns, nothing. At least under current version of Tomcat, this
>prevents the JspWriter from being used, which avoids the problem.
>This may or may not work with other JSP engines.
>
>By the way, you should probably set the mime type before calling
>response.getOutputStream(). In this case it doesn't really make a
>difference, but all headers must be set before any data is sent, and
>putting all the response.setX() stuff at the top can avoid some
>hard-to-find problems later.
>
> - Larne
>

[Larne Pekowsky]

Fernando Ribeiro <fribeiro@bol.com.br> wrote:
>Following the first approach (simpler, sure) you can send any kind of
>data even a .doc file just changing the MIME type. This "you could
>even use jsp:include following this approach" seems quite good and is
>new to me. I will try it tomorrow.

Cool, let us all know how it goes...

>I am not sure, although, I have understood it the way I should. Does this
>mean I could include the content of a second image file in my output stream
>which I will write a first image to?

It means you could embed the bits comprising part of an image in
between the bits comprising other parts. For jpegs, gifs, and pretty
much every other type of image this isn't particularly useful, since
there's no direct relationship between 'bits' and 'pixels.'

However, this could be used with an image type like ppm, which is a
simple stream of red/green/blue values. An outer JSP could start
generating a 200x200 image, an included JSP could generate the first
200x50 pixels, perhaps comprising the word "Hello", another included
JSP could do the next 200x50 pixels, perhaps containing "World", and
the parent JSP could finish up the image.

This could also work with simple sound formats like wav or au: a
parent could write the header info, and then a series of included JSPs
could each add a musical note.

Of course, if the internet has taught us anything, it's that just
because something can be done, doesn't mean it should be. Probably
999 times out of a thousand it will be better to put any code that
generates binary data into a servlet or, better yet, a bean. The real
strength of JSPs is in manipulating text, html, and xml.

>Thanks for the info. A friend of mime is now reading your book and told me
>it is quite great. Congratulations.

Thanks (and thank your friend for me)!

- Larne