Xebia Blog

Many applications we built have to provide reporting to allow end users to monitor results, progress, etc. In most cases a simple query and an Excel export is more than sufficient. In cases where more advanced reports are required we often look at projects like JasperReports or if that doesn't suffice maybe even Crystal Reports. As I'll try to explain in this blog, it might be worth your time to take a look at Eclipse BIRT.

The Eclipse “Business Intelligence and Reporting Tools” is one of those Eclipse projects I've been tracking for some time now. Its current release features a report designer based on our favorite IDE (also available as standalone download) which allows non-technical users to create reports with charts, tables, etc. It includes a web based report viewer application. It can of course execute the report designs, but also provides export capabilities (with AJAX column selection) and a range of other features.

For a more thorough overview of the features of BIRT, take a look at their website at http://eclipse.org/birt/phoenix. Features I found interesting:

• Standalone designer (based on the Eclipse IDE)
• Support for various datasources (including XML)
• Different output formats (with similiar layout)
  
  Currently it supports PDF and HTML, but there is also an (experimental) XLS emitter available. Look for "tribix" here: http://qauck.blogspot.com

In most cases we want to include the reporting directly in our applications (to be able to provide security, caching, etc.). Since most of our applications are built using the Spring framework it would be convenient if we could use BIRT by instantiating a few beans. As it turns out we can, but it took me some time reading (sometimes) badly documented source code and googling a lot. The remainder of this blog describes the steps I took to integrate BIRT in a sample Spring web application.

(more...)

Filed under: Eclipse, Java, Spring
8 Comments

Proxy-based AOP frameworks like the one in the Spring Framework have a not oft discussed problem. When a method in a class invokes another method in the same class (or a superclass), any interceptors on that second method are not executed. This unexpected behaviour can have serious consequences when the interceptor delivers important services like transactions or security.

Let's say we are implementing an application for a bank where only certain employees are allowed to perform a credit check on suspect transaction, e.g. those exceeding 1 million euros. Using Aspect Oriented Programming this can be implemented as follows:

When processed by AspectJ's precompiler, the following woven class is output:

As you can see in the picture, when the method processPayment is invoked, the correct security check is performed when the checkCreditRating method is invoked.

However, that precompilation step was perceived as complicated and hard to integrate into the build proces (and not every IDE has appropiate plugins). This led to the appearance of proxy-based AOP solutions such as dynaop and Spring's AOP framework. A precompilation step is no longer necessary. Instead, a proxy is created on the fly. This proxy performs the functionality defined in the aspect before (and after) invoking the method in the original object:

Apart from only offering method interception instead of the full range of AOP functionality, this approach has one other, not often discussed, drawback. When invoking the checkCreditRating method on the proxy, the security check is correctly performed. However, when invoking the processPayment method on the proxy (see the picture), control is passed to the processPayment method in the original object which invokes this.checkCreditRating() directly, thereby bypassing the security check. This occurs because this in the original object refers to that object itself instead of the proxy.

Other functionality that assumes the identity of the proxy and the identity of the original object are identical will fail too. As mentioned in GoF on page 178 when discussing the Decorator pattern:

3. A decorator and its component aren't identical. A decorator acts as a transparent enclosure. But from an object identity point of view, a decorated component is not identical to the component itself. Hence you shouldn't rely on object identity when you use decorators.

This is an unexpected result of the proxy-based implementation of AOP and one that you need to be especially aware of when implementing important functionality in a aspect!

Filed under: AOP, Java, Spring
8 Comments

I am writing a GWT application and want to test this application both in the GWT shell and in Tomcat. The application uses different Eclipse projects for the GWT UI and for the business service layer.

I found out that this can easily be done if you use an Eclipse WTP dynamic web project instead of the standard Java project that is created by the GWT projectCreator.

Using a dynamic web project has the following advantages:

• It is possible to use external jars and other Eclipse projects from services that are implemented with the RemoteServiceServlet.
• It is easy to test the 'compiled' JavaScript version in tomcat without having to create and deploy a war file.
• It is easy to export a war file that can be deployed in any application server.

There is an Eclipse plugin for using GWT with WTP: Googlipse . However, this plugin does not (yet) support launching the 'compiled' JavaScript application. I will outline the steps that allow you to launch the JavaScript version of a GWT application in WTP.

(more...)

Filed under: Java
2 Comments

We ran into a TransientObjectException in our Hibernate-enabled code. At first the exception was very hard to reproduce and only occured in very rare cases. Sometimes during our integration tests and sometimes during our smoke tests.

We tried just about everything to find out why Hibernate interpreted the relevant objects as being unsaved (ie transient) even though we verified that they were indeed saved in a previous Hibernate Session by looking at the sql logging.

It turns out that Hibernate does not see the diffference between the values "0" and "null" when looking at the ID property (a java.lang.Long) to check whether the object is persistent. Because our Oracle sequence starts at 0, the first object that was persisted had an ID of 0. When that object was then used in a later Session, Hibernate did not recognize that value as valid and interpreted the object as transient.

We fixed this by adding an extra unsaved-value attribute to the relevant mapping. Like so:
[code]

MY_SEQ

[/code]
That solved the problem. Whether this is a bug or a feature in Hibernate I'll leave as an exercise for the readers

Filed under: Hibernate, Java
4 Comments

We’ve put up a new article on the Articles page. Summary follows:

The article Factories are about abstraction, not creation told what factories are for, and when they should be used. This article will show different ways to implement factories. The complexity that is needed for a factory implementation depends on the required flexibility and how much effort is needed to construct a complete instance:

• when should it be possible to configure the factory repository: can it be coded and remain fixed for a release or should it be configurable at runtime?
• does the client of a factory need to influence the subclass choice in some way?
• how complex is the algorithm to determine the correct subclass?
• how difficult is it to construct a valid instance of the required class?

Filed under: Articles, Java
No Comments

In this post I'd like to point out some ideas regarding Binary XML and Excel.

The W3C's XML Binary Characterization Working Group started in the summer of 2003 and its first activity sparked protest from XML experts around the world. The Binary XML concept has been discussed before, exchanging ideas why a less verbose XML is necessary.

One year ago the XBC Working Group published their documents and continued their efforts at the Efficient XML Interchange Working Group, sadly without gaining too much interest. The problem is, Binary XML would be a whole new set of specifications, creating new problems: it would be humanly unreadable, new and updated tools, parsers and editors would be necessary, and a new set of agreements would have to be made for e.g. well-formedness validations.

Why do we invent a Binary XML when we already have a perfectly useable alternative: Microsoft Excel?

Excel is used for all kinds of purposes, even many it was not designed for: requirements, structured specifications, messages, issue tracking, timesheets, project management, timeseries data and -- of course, calculations. That makes Excel as much 'general purpose' as XML is.

What's more, it is already used by countless numbers of users worldwide. Nowadays non-Microsoft tools are able to take care of the Excel file format, so the usefulness of Excel spreadsheets is extended beyond the Microsoft Windows platform.

An Excel sheet is a binary format which simple human beings know how to deal with: we can open those spreadsheet files in our favourite office suite and look, analyse and modify what's in there. It's even more user-friendly than XML itself! No more tag balancing, no more character escaping! Spreadsheets lend themselves perfectly for mixed human-computer message exchange. For instance, a questionnaire or a timesheet could be provided as an Excel template, filled in by a user and processed by an administrative system, using the user's favourite Spreadsheet application and software like Jakarta POI.

It's a shame that most spreadsheets are only used by users, and almost never processed by software, which is a very real and practical option...

When will businesses go all the way and use spreadsheets to implement c2b or b2b messaging?

Filed under: Java, XML
7 Comments