Release Notes v1.0RC3
| || |
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.
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".
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 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:
- Improve global response times
- Improve network traffic for large unpaginated reports
- Speed up the integration of large unpaginated reports by client-side web browsers (in particluar for interactive tables - crosstables)
- 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:
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.
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:
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.
The reportlet has been successfully tested on this new Liferay release. By the way, visioneo.org 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:
- An excessive memory usage with Liferay's StripFilter
- An excessive memory usage with Liferay's JRuby engine.
To workaround the first issue, you must set this parameter in your Liferay portal-ext.properties:
By default, you will find this properties file under
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
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.
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
SEVERE: Problem while serving resource renderingURL for the portlet: local._dumbvalue
ClientAbortException: java.net.SocketException: Software caused connection abort: socket write error
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
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.
- 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
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
Integration tests v1.1.1 16 March 2013
Release Notes V1.0.1.Final 15 March 2013
Release notes v2.1 852930 Views
Release notes 0.9.1 271035 Views
Release notes 0.9.2 261079 Views
Release notes 0.9.3 259736 Views
Release Notes v1.0RC4 244646 Views
Release notes 0.9.4 243639 Views
Release Notes V1.0.RC5 233233 Views
Release notes v1.2.2 216923 Views
Release notes v2.0 204754 Views
Release notes v1.3.0 174411 Views