Test app has been added to repo\qa\trunk\Regression\ICE-5048. Thanks, Adnan.

Thanks Paul and Hybris for verification.

works for me
thanks

Tested it with the patched jar on Tomcat 6. Looks like my image problem has been solved.
Thanks, Adnan. Regards, Paul.

The bug has been fix, for quick testing I am attaching a patched jar. can you please verify it.

Thanks,

Modified: D:\work\development\head\svn\ossrepo\icefaces\trunk\icefaces\component\src\com\icesoft\faces\component\ext\HtmlGraphicImage.java
Sending content: D:\work\development\head\svn\ossrepo\icefaces\trunk\icefaces\component\src\com\icesoft\faces\component\ext\HtmlGraphicImage.java
Completed: At revision: 19589

Modified: D:\work\development\head\svn\ossrepo\icefaces-ee\branches\icefaces-ee-1.8.2\icefaces\component\src\com\icesoft\faces\component\ext\HtmlGraphicImage.java
Sending content: D:\work\development\head\svn\ossrepo\icefaces-ee\branches\icefaces-ee-1.8.2\icefaces\component\src\com\icesoft\faces\component\ext\HtmlGraphicImage.java
Completed: At revision: 19591

This can be easily reproduce on Glassfish after page reload.

I think that's just a coincidence. I'm having the same kind of problem with a number of pages in Tomcat 6, not with all, and not with this example you provided though.

Thanks Hybris for the testing of the application with both web servers. So this seems like server specific issue. We will look into it.

i tested the app with glassfish 2.1 and tomcat 6.0.18

with glassfish initially all seems to work ok but if i reload the page (via the browser button) all stops working as described before. no error is given but pressing the get next image button does not produce the expected result.

same test with tomcat works fine even after reloading the page

When I encountered this bug, it doesn't fail all the time. It works the first time I enter a Java bean page with graphicImage. It is when I enter the Java bean page the second time and afterwards that graphicImage stops changing.

Attaching new war file, which doesn't require any external file. Images are served from the web/images.

Maybe just a stupid guess. But I hope the hashcode of the byte[ ] isn't just computed as bytes.hashCode() (where bytes is a byte[ ])? That delivers the address of the array, not a valid hash code (the Object default)! But it would perfectly explain the results I am seeing...
Regards, Paul.

Hi,
i'm having much trouble in getting "C:\work\1.jpg" work in a linux environment.
Could you please provide me the source code of the test case so i can adapt it to my system or modify it so it searches for images in the application context root?
Thanks

I am attaching a slide show demo using byte[] and 1.8.2 jars. I have tested it with tomat6 + FF3, IE8, Safari and Chrome. Seems to be working fine. Can you please test it, mean while we will test it with your configuration. App has source as well.

This is what i do.
I can see the hashCode changing in the uri and sniffing the browser actions (with httpfox and firefox) i can see that the browser actually requests the new picture.
I tracked my server application and i am sure that a new picture and a new byte array are generated whenever i have a new image to display.

The problem is that it seems that the picture served is not updated even if a new byte array is given and even if the hash code proves that the array is new.

We fixed a memory leak in 1.8.2, so regardless of number of images get served would be served by one resource only. To let the browser know when to request a new image we pass the hashCode of the contents of the image. In graphicImage case its the hashcode of the byte[]. So its in the control of the application. Don't recreate the byte array for the served images. Only recreate it when you want new picture to be loaded.

uri.getPath()+ "?"+ content.hashCode();