Sunday, January 30, 2011

SmartGWT and GWT RPC Integration

I am currently finishing my Capstone project for my MSE at Carroll University. While the application I am writing itself doesn't have a lot of twists in it, I decided to use this opportunity to experiment with some different technologies.  I'm using GWT, SmartGWT, and Hibernate in the application.  I've used Hibernate and GWT pretty extensively in my professional career, but the twists I've added for this development are to configure Hibernate using the JPA standard, and to use GWT Designer for mockups.  I've already posted about my experiences with GWT Designer.

I haven't really used SmartGWT before.  My experience has been with the ExtGWT library, which I loved.  I chose to use SmartGWT on this build because it is fully LGPL, while Ext is dual licensed.  While working with SmartGWT I've found some things that I was not expecting.

One of the selling points of SmartGWT is that it has built in support for 'Data Binding' with Tables and the like.  This is done through DataSource objects.  The problem is, the published DataSource implementations don't work with GWT RPC. And the DataSource base class has dozens of methods (Just take a look at the JavaDoc).  It really isn't clear how to define your own custom data source, or the work it will take to do so.  This was a sticking point for me because I really like the GWT RPC mechanism, and I had already come up with a nice security model, which I posted about here.

It took a while, but I finally found a post about integrating GWT RPC on the SmartClient Forums.  The post is a bit dated and says you need to compile from source, but that is not the case.  The version of SmartGWT I am using, 2.4 already has the clientCustom flag built in.  The developer who posted this also supplied 5 files, Including a GwtRpcDataSource abstract class, and a sample implementation.  The class comments well what you need to do to implement your datasource. With this setup, a new GWT data source can be defined by implementing 4 methods.  

I hope this post helps others find the solution much faster than I was able to.

Saturday, January 8, 2011

dynaTrace Enlightenment

My company recently sent me for dynaTrace training.  dynaTrace is a tool that allows you to instrument your code in real time in order to measure and monitor performance.  I'm not going to go into detail about what it can do, you can read all about it on the dynaTrace website.  If your company has the money, however, I highly recommend it.  It is impressive to say the least.

One of the things dynaTrace offers is the ability to see all the exceptions being thrown in your application, not just the the ones being propagated to your code.  This is important in our applications because we use third-party libraries, and we don't always know what they are doing.  In instrumenting the application we are working on, we found that Spring was throwing hundreds of thousands of exceptions and burying them.  Now each one of these is small in cost, and the application works as expected.  The cost of the exceptions, however, was starting to get expensive - one, two or even a few hundred probably wouldn't be cause for concern, but hundreds of thousands?

So What was the cause?

This application is also a Web application that uses Struts2.  The application was set to use annotation-based configuration.  But when we looked at the Exceptions, it appeared that Spring was ignoring the configuration and attempting to configure itself using other methods, throwing exceptions, and then trying the next one. Multiple exceptions occurred every time the application accessed a Spring managed bean.

As it turns out, there is another flag in Struts 2 to set that says, "No we really, really want to use this configuration."  Once that flag was set, the exceptions disappeared.

So What's the Point?

In todays development environment, we are heavily reliant on 3rd party libraries in order to leverage previous code and get things done faster.  Many applications use dozens of libraries from many different sources.  In some ways, this is a necessary evil.  Could you imagine the time it would take to write a Web application completely from scratch?  I mean completely, no application container, no MVC, nothing.  Start with the sockets to listen to requests.  So, as engineers, we decide to use a component created from another source that matches the criteria we need.  We use application containers, M-V-C frameworks, JavaScript toolkits, Persistence mappers, Logging libraries.... The list goes on and on.

While all of this is generally a good thing, sometimes its not because we don't truly know what's going on in our black boxes.  I think tools like dynaTrace are going to become more popular as companies look to improve quality while still enjoying the advantage of third party software.

That's it for now, it's time to go figure out why the Struts taglibs are adding 500 ms to our page rendering times....