Tooltip & Servlet

[nivedeeta]

Hi,

By breaking out the creation of the BufferedImage it is possible to have one servlet/JSP create the BufferedImage, write out the HTML image map and store the BufferedImage in the session. Another servlet/JSP can then retrieve the BufferedImage from the session, write it out to the servlet response OutputStream and then remove the BufferedImage from the session.

I tried to do do this. But couldn't get it

can any one post example for this?

Regards,
Nivedeeta

[nivedeeta]

what i have done in servlet is

.....

ChartRenderingInfo info = new ChartRenderingInfo(new
StandardEntityCollection());
BufferedImage img = draw(chart, 600, 600 );
OutputStream out = response.getOutputStream();
PrintWriter writer = new PrintWriter(out);
ChartUtilities.writeImageMap(writer, "chart", info);;
ChartUtilities.writeBufferedImageAsJPEG(out,img);
out.close();

}


protected BufferedImage draw(JFreeChart chart, int width, int height)
{
BufferedImage img =new BufferedImage(width , height,
BufferedImage.TYPE_INT_RGB);
Graphics2D g2 = img.createGraphics();
chart.draw(g2, new Rectangle2D.Double(0, 0, width, height));
g2.dispose();
return img;
}


and this servlet is invoked by the jsp page where i am displaying the chart.
This chart is displayed but doesn't show tooltiip.

Thanks,
Nivedeeta

[Richard Atkinson]

Since I wrote about the possibility of having one servlet/JSP produce the chart, write the image map and store the chart in the session as a BufferedImage, and then have another one stream the chart to the browser and remove the BufferedImage from the session - I have gone right off the idea.

The idea is good in theory because the browser should always request the HTML page and then request the image. However in practice, in some circumstances, the browser will re-request the image without requesting the page again. This causes an exception because the BufferedImage is no longer available in the session. The most common cause of this is when someone tries to print a page (with a chart on it) that has been created from a POST request. Which is a common occurrence and obviously a bug.

Since then I have come up with an alternative idea to persist the chart image in the temporary directory (java.io.tmpdir) and then have a generic servlet binary stream the chart to the client. This can be tied in so that when the users session expires all the charts that they have produced are deleted from the temporary directory freeing up the disk space. It also ensures that charts continue to be available beyond the original request so that printing the page later produces the correct results.

I have committed the necessary modifications to CVS at SourceForge and also posted them at http://homepage.ntlworld.com/richard_c_ ... freechart/ .
There is also a demonstration WAR file with examples showing bar charts, pie charts and timeseries charts with tooltips and a flexible drill-down capability. All the source code is also available for download. Feel free to take a look, all feedback is welcome.

Regards,
Richard...

P.S. There is still a case for using BufferedImages stored in the session where a frequently requested chart is kept in the session so that when user requests come in it can be streamed to them without regenerating the chart and without any disk IO.

[nivedeeta]

Hi Richard,

Thanks for all your help.

Regards,
Nivedeeta

[Guido Laures]

Hi Richard,

I had a look at your suggestions to modify JFreeChart to make in tooltip enabled. I do not fully agree with your approaches in two ways:

1. it is not needed to change JFreeChart in any way to get tooltips running
2. the <alt> tag does not guarantee a tooltip rendering as it is only an alternative string which describes the img in non image displaying browsers.

I implemented another approach in cewolf 0.8.beta (http://cewolf.sourceforge.net). It uses the overlib library to implement tooltips. Maybe you got time to have a look on it. I also implemented server-side caching of images in the session. Maybe you are also interested in that. The final 0.8 will also contain a flag which lets the user specify the expiration date of the chart description.
I'm interested in your comments.

Regards,
Guido

[Richard Atkinson]

Guido,

Thanks for the feedback.

1. Agreed it is not necessary to modify JFreeChart in order to get tooltips running. However, I do believe that it is beneficial to modify JFreeChart to support tooltips in server-side environments. The tooltip functionality was not otherwise employed in a server environment and it was a requirement that I had, that I am sure many others share.

One of the great benefits of an open source project like JFreeChart is the ability to make modifications to support additional flexibility and contribute those changes back to the community. The result is a more flexible solution that meets a wider range of requirements, and everyone benefits.

2. Agreed the alt tag does not guarantee the displaying of a tooltip. However Internet Explorer always does display tooltips for alt tags in image maps. Which to Microsoft's credit, is a good idea. In my user community (corporate, financial and home) I haven't seen anything but Internet Explorer for quite some time. Some recent reports rate IE usage on the more general internet at around 95%.

That being said it would be a simple modification to add an option to generate an image map providing tooltips using OpenLIB. The downside is that OpenLIB requires DHTML support and so is also not guaranteed to display a tooltip, but once again the aim is to provide flexibility. That way people have the choice. For my own use using the alt tag does the job nicely.

I haven't had a chance to look at the server-side caching yet, but I'll try and take a look.

Regards,
Richard...

[Achilleus Mantzios]

Hi,

Just some points.

About the chart-map lost sync problem that Richard addresed,
i used the following aproach.
I kept the image and the map (with all jfreechart code) in a SFSB.
I used a custom configuration (in jboss, but the same can be done
for any app server), in order to adjust the lifetime,age, size etc..
parameters of the bean.
Then i used a simple maping between SFSB creation parameters
and a String which i used as the name of the attribute to represent this SFSB in ServletContext.

The displaying jsp (the browser called one), checks if the SFSB
with the specific parameters is stored in the application (ServeltContext)
(by using the simple maping from parameters to String).
Then it checks if the SFSB is alive.
If no then it creates it with the appropriate parameters.
If yes, then it uses a servlet (passing the attribute string) to display the image.
After that the displaying jsp gets the map from the SFSB and outputs the
appropriate html code.

Altho i believe both approaches eventually and under specific circumstances
will fail against the browser bug that Richard addressed (which browser does
that BTW??), i think that with the latter approach we have

a) Application wide caching (the same chart can be viewed by many users)
b) Application server caching management (we leave the job to the app server)
c) The storing of non managed ServletContext attributes may seem too expensive
regarding memory requirements, but what happens really is that only the remote object handle of the SFSB is stored and not the image (chart) or the map.

[Richard Atkinson]

Achilleus,

Sorry, my initial post was not entirely clear. The bug that I refer to is really a flaw in the method that I was using to produce the images, not a bug in the browser. The browser behaviour is correct as a browser is allowed to re-request something that has been initially retrieved via an HTTP GET, however it is not allowed to re-request something that has been retrieved via an HTTP POST. This is to prevent your browser from ordering two copies of that CD just because you decided to print the confirmation page. I am using IE, but I believe any browser would behave the same way.

I think it is important to differentiate between two issues though

1. Ability to re-request charts within the same session using just the chart URL. A requirement for printing pages produced from POST requests.
2. Caching of charts and image maps for improved performance.

My changes are only designed to address the first. The solution that you have created using stateful session beans (I presume?) looks interesting. The only potential issue could be the memory load on the app server if the stateful session beans are keeping all the charts and image maps in memory. Some kind of reaping mechanism to limit the number of charts would be useful, however that would probably bend a few rules about threading in EJB containers/servlet engines. The performance benefits would be dependent on the variety of charts that are produced and the volume of re-requests.

Regards,
Richard...

[Achilleus Mantzios]

Hi Richard,

The Stateful Session Beans are "Stateful" in order to cache data,
and "Session" in order to be non eternally persistent!

Users usually access the charting system from a form.
This form usually has a set of input parameters.
These different combinations if inout parameters divide charts into different image "clusters"
(with the statistical meaning of the term).
What we cache is one chart per cluster.
The app server will unallocate expired Session Beans, or unallocate older
beans if newer ones are to come to life and the max size of the cache is reached.

All these are done with simple app server-specific confuguration, with
no user code invlolved.

[Richard Atkinson]

Achilleus,

Glad you've got it covered!

Richard...

[nivedeeta]

Hi

I am using jfreechart-0.9.3.

I am creating a chart .
If i print the filename string it has follwing value:
/jfreechart-sample/servlet/DisplayChart?filename=jfreechart-57027.png


If i search the chart by name (before ending the session) , the chart by 'jfreechart-57027.png' file is not found.

Where does the chart reside?

Regards,
Nivedeeta

[Richard Atkinson]

In the temporary directory which is defined by the java.io.tmpdir System property. If you have the jfreechart-sample WAR installed it tells you where your temporary directory is on the first page. Or you can just create your own JSP file with the following line.

<%= System.getProperty("java.io.tmpdir") %>

Regards,
Ricahrd...

[nivedeeta]

Thanks

Found it in C:\DOCUME~1\ADMINI~1.000\LOCALS~1\Temp.
In settings i had not checked option for showing hidden folders.

Hence couldn't trace the file.................

Nivedeeta