graphicimage not rendering streamedcontent in Primefaces

Question

I'm using streamedcontent to render a byte sent from JSF then send it back as a streamed content as following:

<p:graphicImage value="#{manage.bytesToStreamedContent(car.image)}"/>

where image is the byte array of the image stored in the database

backing bean:

public StreamedContent bytesToStreamedContent(byte[] bytes)
{
    InputStream is = new ByteArrayInputStream(bytes);
    StreamedContent image = new DefaultStreamedContent (is, "image/jpeg");
    return image;
}

But I'm not getting the image in the JSF page. I got this message appearing in the server log:

WARNING: JSF1091: No mime type could be found for file dynamiccontent. To resolve this, add a mime-type mapping to the applications web.xml.

and:

SEVERE: Error in streaming dynamic resource.

can you please help me out here, I cant find any useful info regarding this issue

PS:

Im using the following libraries:

Mojarra 2.1.3

PrimeFaces 3.1.1

Glassfish 3.1

Answer 1

Found where the problem was. The problem wasn't in the graphicimage. It was because the graphicimage tag is being loaded dynamically (similar issue when trying loading from datatable). Dynamic images cannot be rendered directly in datatable or datagrid. (Workaround is to assign a param and bring the images from the id).

However, the solution is here

Answer 2

This is an odd problem and I don't think that adding the mime-type to web.xml will fix it. It is listed as both a bug in PrimeFaces with a target for 3.2

http://code.google.com/p/primefaces/issues/detail?id=3546

And it is also listed as an open bug in Mojarra 2.1.1. There is a patch submitted for this bug however it looks like you will have to manually apply the code to the Mojarra 2.1.1 source and build it. One would think that this would be fixed in 2.1.3 however, Glassfish may have its own prebundled Mojarra implementation that is still at an earler version and your application may be using this instead.

http://java.net/jira/browse/JAVASERVERFACES-2103

EDIT:

You can just pass the byte[] directly as an argument to the method like that. What you can do though is pass the id of the car as a param and then retrieve that car and fetch the bytes from the Car entity. The reason for this is because the graphicImage actually renders as an HTML img tag and this occurs in a separate HTTP request from the request for the JSF page. Download and install the Firebug plugin for Firefox and you will see this occur, the page is requested, then subsequent requests occur for the images after the page is retrieved. Because of this ViewScoped and RequestScoped beans cannot be accessed in this way, however a request parameter can still be passed with the necessary information needed to retrieve the Car bytes for the image.

<p:graphicImage value="#{manage.bytesToStreamedContent}">
<f:param name="item_id" value="#{car.id}" />
</p:graphicImage>

Now in your managed bean property you can get the car id, and after you get the car id you should be able to get the right car.

public StreamedContent getBytesToStreamedContent() {
  String id = FacesContext.getCurrentInstance().getExternalContext().getRequestParameterMap().get("item_id");
  //Now get the car with the id
}

Answer 3

In general, it's not a great idea to create the StreamedContent in the getter for graphicimage. The image will be fetched in a separate request from the rest of the content, meaning variables depending on iterators will not work. This means that in the relevant call to bytesToStreamedContent the bytes array will be null/empty. If you put breakpoints inside the method you will probably see that in the last call there is no data in bytes.

You need to make sure the image is generated while you still have access to all the needed content and then store it in a way that you get retrieve it again in bytesToStreamedContent. Whether or not this will fix the problem and actually work for you is hard to say without seeing the rest of the code. I would start by trying to remove the byte array argument and returning a static image to confirm that this is the problem.