Knowledge Base (Display) Knowledge Base (Display)

Release Notes v1.0RC3

The Release Candidate 1.0.3 includes many bug fixes and exciting new features! 

 Interactive BIRT tables & crosstables!

Bring your BIRT reports to life, with the new first-class interactive table feature!

  • Dynamic instant sort on any data column!
  • Dynamic column reorder
  • Vertical scroll with fixed headers & footers!
  • Dynamic instant filter on any keyword across all your data columns!
  • Dynamic columns selection: show/hide any data column!
  • Select the number of rows to display, the table is instantly re-paginated
  • Client-side datatype auto-detection: sort numbers even with currencies symbols and thousands separators!
  • Copy to clipboard, export or print  your filtered rows 

This feature is also available for cross-tables! See the live demo for more informations.

Facultative parameters

The sample report provided for the above dynamic table is also designed to be used as a reference, to demonstrate how it can be easy to set up multiple facultative parameters, with this famous "All values" item. This report design does not contain any single line of script, and implements the method explained in the knowledge base article BIRT required / facultative parameters.

Internet Explorer 9

  • An issue specific to IE9 has been pinpointed. In the previous versions, it heavily slows down some reportlet UI options. It is fixed in RC1.0
  • In some situations, drillthrough don't work in IE9 (when we define the target as 'New window' in BIRT designer). It is now fixed, except for drill within a chart. As a workaround, use any other target option when you define a drill in a chart, for example "Parent frame".

PDF Export 

In previous versions only one type of PDF export is available, it appears in some situations this is not sufficient. For example, if a report table is using a "Page break interval" set to 0 (which means no pagination should be applied), the current pdf export won't be exploitable. The vRC1.0 offers 3 PDF pagination options, such as Eclipse Web Viewer does:

  • Actual size: use all paginations & size options set up in the report design (this is actually the export used in v0.9.4 and previous)
  • Auto: report design pagination is completely ignored, and the Birt engine paginates your exported document to fit correctly in multiple pdf pages
  • Enlarge page: Fit the whole document in a single page

Enhanced inter-portlet events!

A major feature is included in RC1.0, relevant to inter-portlet events: events sent by a reportlet now include the current report parameters values! In previous versions, only the report name and a message could be sent to your own portlets. A new field "queryValue" is added to JSON events, and allows to build powerful custom portlets around reportlets. By the way, localized report "display name" is now also included in events. An amazing "storelet" demo section showing how you can take advantage of this in your portal  is available right now!!  

HTML generation

  • Html markup streams generated are about twice as small as they are in v0.9.4 and previous releases.
  • An enhancement specific to Gatein, Liferay and JBoss Enterprise makes the html generated even smaller. For the samples report, html streams are from 3 to 5 times smaller as they are in previous versions. 

This enhancement has three main goals:

  1. Improve global response times 
  2. Improve network traffic for large unpaginated reports 
  3. Speed up the integration of large unpaginated  reports by client-side web browsers (in particluar for interactive tables - crosstables)

Reportlet UI

  • When you drill to a pretty large target unpaginated report (for example a 2000 cells cross-table), and then close the drill dialog, this dialog may be "long" to be closed (a few seconds, depending of your processor speed). It is fixed in RC1.0.
  • The "Fast print "option has been much improved: it does not open a new browser window anymore, and makes use of an ajax call to get the current report page in a printable format. For example if you use SVG charts in your reports (and enable the SVG reportlet preference), the fastprint option now converts these charts in a PNG format just before printing, to avoid any display issue. This print option is particularly useful if you use a web browser which automatically displays a preview, such Google Chrome does. 
  • The drill-through dialog now displays the target report "Display name", instead of "Drill-through" as title (in the top left corner). You can set up a display name in each BIRT report through your Eclipse designer, and localize it if necessary:

Multi-select listbox

This powerful and ergonomic jQuery widget has been updated to its latest release. It is now entirely operational and very fast, in vRC1.0 it is used by default when a BIRT parameter is set as "Multiple". The current widget will be still available if you want to use it, but won't be the default one. 

However this widget has still a controversal "All" option. Combined with filtering keywords it is very convenient, but with a large list of values it may lead to huge selections, which could cause issues in architectures and even in your DBMS optimizer.  This point is currently under discussion with users to decide if the number of selected values must be limited or not, and how. Any further opinions will be much appreciated.

Thread safety

v0.9.4 and previous versions are already thread-safe in a massive multi-user context, and across several reportlet windows per page. However, if mutliple requests are received simultaneously on a same reportlet window session ( a user sending several queries in a row in the same window, when previous are not still finished), there is a low risk to get an unexpected result. It is fixed in vRC1.0. 

Sessions serializable & cluster

The reportlet works in a very similar manner to a RESTful application. In vRC1.0, portlet sessions are still used a little bit (it is obligatory in case of a page refresh and for security considerations) but they are as light as possible and serializable, and then can be clustered.

JSP beans modified

As a consequence, all JSP pages have been slightly modified. If you have already customized some of them, you must apply these changes as well: 

VisioBridge vbridge=(VisioBridge) renderRequest.getPortletSession().getAttribute(VisioConstants.bridgeSession);

has been replaced with:

VisioBridge vbridge=VisioBridge.getVisioBridge(renderRequest);

Cache management

The cache management GUI has been improved. This module was initially designed for information and debugging purpose, but it appears many of you really need this in a production context to refresh caches on demand. By the way a small bug related to the display of the client-side cache elements is fixed. Furthermore, a new button makes use of Terracotta API to estimate the current memory usage for both documents & rendering caches. These two caches are fully serializable, and then can be clustered. In the example below, you can notice 37 documents entries only use 1Mb, and 46 rendering entries use 0,7Mb.  With the default setup, you may note this memory usage is not correlated with elements count, because the ehcache configuration file limits the memory use to 100 elements. 

If you need to allow specific users to access this module, please note you can set up any portal role to be a reportlet administrator. In other words, a reportlet administrator is not necessarily a portal administrator: you can map to "administrator" any role you want in your reportlet portlet.xml file (or liferay-portlet.xml for Liferay).

An issue related to the metadata cache is fixed: in previous versions if you have for example 30 reports design in your BIRT report path, the metadata cache stores 60 elements. This cache now stores exactly as many elements as "rptdesign" available in your reports hierarchy. 

Javascript minified

Javascript plugins are now all minified. Without jQuery&UI, which could be for example pulled from a CDN such Google, once compressed by your application server all javascript plugins have a total size of only 98 Kb! And less than 20Kb for the visioneo core! If you keep jQuery & UI embedded (as it is by default), the whole javascript stream size, once compressed is only 280Kb.

Liferay 6.1.1.GA2

The reportlet has been successfully tested on this new Liferay release. By the way, portal has been upgraded to it.


The v0.9.4 package  to download has been updated to support this new Liferay release

Private Plugin Installer

Pending the reportlet is available on the Marketplace, to install it you must now use this private plugin installer

The reportlet and the storelet have been successfully tested on the JBoss 7 package as well. With JBoss, if you utilize the default Liferay's bundle, you must increase JVM maxPermSize up to 384 Mb.

Memory leaks in Liferay CE 6.1+ 

You may encounter significant memory leaks by using the reportlet with Liferay 6.1+ versions:

To workaround the first issue, you must set this parameter in your Liferay


By default, you will find this properties file under <webapp>/ROOT/WEB-INF/classes. If it does not already exist, create it. Setting this parameter shouldn't affect performances in any way: by looking at the code it appears Liferay does not minify inline Javascript and css fragments when it is set to 0. In fact it should even be faster. 

To workaround the second issue, pending it is fixed by Liferay team, you should avoid  including CSS resources in all liferay-portlet.xml files. Include your css files in a portal theme instead, or in a JSP page. This is what the reportlet does from RC1.0 version. 

Furthermore, Liferay is loading tons of JSP classes which are never unloaded. Therefore if you use Tomcat 7, you may consider to set the maxLoadedJsps parameter in $CATALINA_HOME/conf/web.xml.

With these changes, your Liferay 6.1+ server should never require any periodic restart.

By the way you should vote for the relevant JIRA issue to make it fix.

Gatein 3.4.M01 & Final

Visioneo reportlet has been successfully tested on this new Gatein release, both with Tomcat 7 and JBoss 6 & 7. Though a small bug has been found on this version: when you add a portlet to a portal page, you have to save this page before using the "Edit mode". If you don't, portlet headers are not correctly processed and the edit mode won't work. This issue is logged as GTNPORTAL-2582, it is fixed in Gatein 3.5.

uPortal 4.0.6.SP1

The reportlet has been successfully tested on this new uPortal release. Note inter-portlet events are now fully implemented in uPortal. 

Report parameters values size

In previous versions, selected parameters values are sent to the server side within an URL, which is limited to 2kb on popular browsers. It appears some users have broken this limit with huge multivalues parameters selections. It is fixed in RC1.0, parameters values are now sent as data. However please consider most of the time, these situations are due to a significant  design error with a report or the data model, or a mistake from an end user.

ClientAbortException in Gatein

If you use Gatein, you may have encountered this kind of stack trace in your logs:
SEVERE: Problem while serving resource renderingURL for the portlet: local._dumbvalue
ClientAbortException: Software caused connection abort: socket write error
at org.apache.catalina.connector.OutputBuffer.realWriteBytes(
at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(
at org.apache.tomcat.util.buf.ByteChunk.append(
at org.apache.catalina.connector.OutputBuffer.writeBytes(
This exception happens when a user cancels a running visioneo report in his web browser exactly when it is being transfered, and more generally when any ajax request is aborted in Gatein during transfer. It does not have any consequence except logging an error message. An enhancement has been submitted to catch this exception in exoplatform portlet container.

Maximized width

The default maximized width is now 965px, when it is 1100px in previous versions. 965 px seems just fine if your site is designed in a 1024 resolution, as the Visioneo live demo portal is. You can of course tune this value in portlet.xml.

BIRT reports default path

The default path of BIRT reports and resources is now just under the root of the web application. In a production context, note it is probably a good practice to set up an absolute path, outside the application server scope

License simplified

The license is even more permissive as it was in previous versions: you can now modify any reportlet JSP file, when in v0.9.4 and previous, only a few specific JSP files were opened. There are about 50 JSP files, which allow to control the whole presentation layer of the application. 

Pixel perfect

  • In v0.9.4 if you decrease the size of the parameters dialog in preferences mode, an annoying horizontal scrolling bar appears at the bottom of this dialog. It is now fixed.
  • Still in this report parameters dialog, the margin between the help text and the first parameter is slightly increased. 
  • The export dialog height is slightly increased
Tags: release notes
Average (0 Votes)
Most Recent
Release notes v3.2 24 November 2015
Release notes v3.1 26 September 2015
Release notes v2.2 19 August 2015
Release notes v1.4.1 06 December 2013
Release notes v1.4.0 03 December 2013
Release notes v1.3.0 13 October 2013
Release notes v2.0 26 September 2013
Release notes v2.1 01 August 2013