Archive for June, 2009
Migrating to Eclipse Galileo and the Flash Builder 4 plug-in
For some time now, I’ve been using Eclipse with the Flex Builder plug-in to code my Java/Flex projects. Recently I’ve decided to switch from Flex Builder 3 to Flash Builder 4. And since Eclipse Galileo had just been released, I just had to add it to the migration stack and let go of good ol’ Ganymede.
Installing Eclipse Galileo
As usual, installing Eclipse is a breeze. Go to the downloads page, select the package that suits you best, download it, then decompress it. I’ve taken the Java EE package for Mac OS X (Carbon), since it suits best my needs and the platform I’m running on (Mac OS X Leopard 10.5.7).
Installing Flash Builder 4
Download it from the Flash Builder 4 page from Adobe Labs.
Installing Flash Builder 4
Everything went smooth and after the installation was done, I was able to create my first FB4 project :
My first FB4 project
Other plug-ins
After FB4, I did install other plug-ins that I use in my daily work : the Perforce plug-in, M2Eclipse, the TestNG plug-in, JBoss Tools, EclEmma, the PMD plug-in, the Checkstyle plug-in and Flex Formatter.
Everything works fine, just as before, and I’m very pleased about it.
Migrating the workspace
The real test for my new IDE stack was migrating the workspaces I use. After everything was in place, I opened my latest workspace with my new Eclipse and it turned out to be OK. I didn’t experience any issues with the Java projects or the plug-ins.
Migrating Flex projects
Everything worked out smoothly, except for the Flex projects. When building the Flex projects from my workspace, I kept running into an error with a message like this :
Attempted to beginRule: R/, does not match outer scope rule: P/my.project
This error would pop up during each project build, so I had to do something about. I did a bit of googling and it turned out that this message is common to multiple issues to Eclipse, most of them who got fixed, so that didn’t help me much. I tried out a couple of workarounds and in the end I managed to fix the problem by deleting the Flex projects from the workspace (but not the project contents) and then using the Import wizard to recreate them :
Import the Flex project as an existing project
After I did this I didn’t receive any more errors when building the projects. However, I did change the default Flex SDK to be Flex SDK 3.4, instead of 4.0 as Flash Builder defaults to. This was the last configuration I had to do before I could work as smoothly as I did before with the Eclipse Ganymede/Flex Builder 3 stack.
Let’s get Tanki
While checking up what’s new on Cornel’s blog, I read his recent post on this new massively multiplayer online game called Tanki Online. It’s a game with, well d’oh, tanks. I gave it a go and I really really enjoyed it. What’s not to enjoy in creating chaos and mayhem with your camouflage-painted tank ?
The game is based on Flash technology and is at this moment in open test, meaning there still are things to improve and that sometimes you won’t be able to play due to the huge number of online players. However, the game is still very fun to play and it’s definitely worth it. So come on, go to Tanki Online and join me in a deathmatch.
Java code coverage reports in Eclipse
A part of our team’s “definition of done” is having unit-tests in place and, unofficially, a minimum of 80% code coverage. Our Maven-based build process runs the tests and then creates code coverage reports in HTML format, that we can then consult in the documentation that Maven generates. Along with other reports, this helps us get a clear picture of where our code is in terms of stability and quality.
This is all great ; but when you’re in the middle of a task and you write unit-tests, it’s quite tedious to run the build and then open the HTML coverage report just to monitor your code coverage. I spend about 80% of my time for a task in Eclipse : opening and activating tasks with Mylyn, coding, writing unit-tests, running unit-tests and so on. This is why for me it made sense to seek out a way to monitor the code coverage in Eclipse.
After a bit of googling, I found a Java code coverage plug-in for Eclipse : EclEmma. As you can see from its name, it’s based on the EMMA Java code coverage tool. Here’s a list with its main features :
- a coverage mode in which applications launched or unit tests are instrumented and measured
- coverage overview : a coverage view containing a report on the source code coverage values at project-level, package-level and class-level
- source highlighting in the Java code editor using customizable colors
- customizable coverage counters
- multiple coverage sessions and session merging
- importing EMMA coverage data files
- exporting to EMMA coverage data, XML and HTML
The easiest way to install it is through the update site : http://update.eclemma.org. After the installation, you will notice a new launch mode appearing in the Eclipse toolbar, called Coverage, similar to the Run and Debug modes. This new mode allows you to run coverage reports on applications or unit-tests just like you would before run those applications or unit-tests.
In a project I’m currently working on, our server-side unit tests are written using TestNG. From Eclipse, I can run one or multiple TestNG units using the Eclipse TestNG plug-in, so I can easily verify that my code passes the unit tests. I have defined a launch configuration for each server-side project which runs all of the unit-tests. To check out the code coverage for those tests, all I have to do is create a coverage configuration and make sure that I select the source code folders to be instrumented.
I created a sample Java-Maven-TestNG project and added to it a simple class called ShoppingCartImpl along with a TestNG test class. Here’s how it looks :
Source code of a very basic shopping cart
As you can see, this is a very basic class. Now on to configuring the coverage settings ; this is a simple matter of clicking on the Coverage button in Eclipse’s toolbar and selecting the menu option Coverage Configurations…. This opens up the coverage configuration window, as seen below :
Creating a new EclEmma coverage configuration
All I have to do is select the TestNG test suite that I want to run and check the source folders that are relevant to code coverage. I’m using Maven and all my source code is in src/main/java so I only select that folder. I click Apply and then I can finally run the coverage report. I click on the Coverage button and theTestNG configuration is executed and the coverage report is available :
Code coverage report after a first run
In the bottom of the Eclipse window, you get a clear picture of the code coverage. As you can see, the are reports at project, package and class level, which also show up in the package explorer, in the left. To enable the decorators in the package explorer, go to the Eclipse menu and select Preferences -> General -> Appearance -> Label decorations, then make sure that the Java Code Coverage label decoration option is checked.
Another interesting feature of EclEmma is that after the code coverage instrumentation you can actually see the coverage in the source code. As you can see, each line relevant to the coverage report is marked with a color. Green is for 100% branch coverage, yellow is for some branch coverage and red for no coverage at all. The shopping cart has quite a low code coverage so I did shape it up. After a bit of fiddling with the code, I get a 100% code coverage and a very nice report :
The ShoppingCart class with 100% code coverage
Meaningful exceptions in LCDS/BlazeDS applications using Spring BlazeDS Integration
Posted by margelatu in Flex, Java, LCDS / BlazeDS on June 15th, 2009
In a project I’m currently working on we’re using LiveCycle Data Services to expose Java back-end services to a Flex client application. The back-end is structured in several layers using some flavors of Spring “glue”. You can see below the basic building blocks of the back-end :
As you can see, the architecture is quite simple. We have a layer of service API which is implemented by another layer, a LCDS-based implementation which, in turn, uses an implementation of a DAO layer. In the diagram, I grayed out the DAO layers because they are of no interest to our current subject.
Briefly, the service API only contains the interfaces of the services along with related objects : exceptions and DTOs.
We use our custom business exceptions to signal to service clients any issues encountered during service operations. Each custom exception has a public code which indicates its nature and meaning.
Simple exception mechanism
At first, we decided to simply throw business exceptions from the service implementations. This meant that the Flex client application would receive a fault event, which it had to strip to get to the actual exception.
Here is the Java service exception and method :
public class InvalidCriteriaException extends Exception { ... public String getCode() { return ExceptionCode.INVALID_CRITERIA.toString(); } } public SearchResultDto searchById(SearchCriteriaDto criteria) throws InvalidCriteriaException { try { // do some processing, use the DAO layer ... } catch (SomeDaoException e) { // convert the DAO exception into a service exception and then throw the new exception ... } catch (Throwable e) { // any unexpected exception is caught and a new service exception is created and thrown further ... } }
And the corresponding Flex code :
private function handleException(event:FaultEvent) : void { var errorMessage:ErrorMessage = event.message as ErrorMessage; Alert.show(errorMessage.rootCause.code); }
As you can see, the Java service code is cluttered within a try..catch block, which also contains the details on converting possible exceptions to service exceptions. On top of this, the client-side code is not very clean either, because it uses an untyped object ( rootCause ) on which we make assumptions and assumptions are generally a bad thing to do in your code. The right solution on the client-side would be to take advantage of the properties of the ErrorMessage object.
A better exception mechanism
In order to leverage the properties of the Flex class ErrorMessage, we decided to only throw instances of flex.messaging.MessageException, which is shipped in LCDS (and BlazeDS). To do this in an easy way, we proceeded in making sure that each of our custom exception would inherit MessageException :
public class InvalidCriteriaException extends MessageException { ... }
The service layer would now throw only MessageException-derived exceptions, which get deserialized on the client-side as instances of ErrorMessage. The Java exception has a field called code, who is translated in the Flex class as the field faultCode. So the only thing left to do is make sure that the code field is set to a proper value on the server side.
Using Spring BlazeDS Integration and a custom exception translator
The solution described in the previous paragraph still comes with some flaws. First of all, we didn’t get rid of the try..catch block in the service code. Uh, ugly.
Second, there is a design issue : the service API layer is exposing the service interfaces along with the exceptions, which are now derived from a LCDS exception. This makes the service API layer dependent on LCDS, which is not what we want. The service API should be clean and free of any implementation-specific dependencies.
These flaws were removed once we switched to using the Spring BlazeDS Integration to expose our Spring-based services as LCDS destinations. Along with other great features, Spring BlazeDS Integration comes with the notion of custom exception translators. The translator makes sure that exceptions thrown from the Spring-exposed LCDS destinations are converted to meaningful exceptions for the client, all of this far away from the service code which will be far more simple and clean.
First of all, we create our own exception translator :
public class ExceptionTranslatorImpl implements ExceptionTranslator { public boolean handles(final Class<?> clazz) { return Boolean.TRUE; } public MessageException translate(final Throwable throwable) { final MessageException exception = new MessageException(); exception.setCode(ExceptionCode.SYSTEM.name()); if (throwable != null) { if (throwable instanceof BaseCustomException) { exception.setCode(((BaseCustomException) throwable).getCode().name()); } exception.setRootCause(throwable); exception.setMessage(throwable.getMessage()); } return exception; } }
Then we need to register it in the application context :
<bean id="allExceptionTranslator" class="com.adobe.myproject.exception.ExceptionTranslatorImpl" /> <flex:message-broker services-config-path="/WEB-INF/flex/services-config.xml" > <flex:exception-translator ref="allExceptionTranslator"/> <flex:message-service/> <flex:secured /> </flex:message-broker>
We can now remove all the exception conversion logic from the service code and let the exception translator handle all of these ugly details for us. Much better, isn’t it ?