Enterprise Applications and Development

Oracle JDBC Logging

2010-08-31T08:53:00.001-04:00

During a database upgrade (oracle 10g to 11g) I had to debug a series of JDBC calls. I suspected a performance bottleneck in a database query and decided to look for the offending SQL statement. This is when I started to find how much information there is about JDBC logging. Most places I researched pointed me to p6spy, a nice tool which according to the documentation "intercepts and optionally modifies database statements". This was helpful to determine that the bottleneck was not a SQL statement from our application, but instead a library (open source) which needed metadata information.

P6spy is very useful to determine time and statistics only on Statement calls (and its subclasses). This is done by wrapping these types of objects and gathering statistics around each call. This is possible because of the abstraction provided by JDBC over SQL statements can be replicated by p6spy and then delegated back to the driver of choice. As we installed and run p6spy, we proved it was helpful to confirm what we suspected: Our application was just fine, the new database (11g) was having problems. Furthermore, we were able to detect that the offending API call was the following:

DatabaseMetadata md = connection.getMetadata();
md.getTables();

This type of JDBC call was not something we have control over. Now, most DBAs will demand to know the SQL query causing the slow performance in order to debug it and see what kind of improvements can be done to it. This is something very peculiar because no developer has a chance to change the query generated by the snippet above (this is part of the JDBC driver, specific to oracle). In fact, p6spy will not help either as this is not even a wrapper over Statement calls (well, it really is as you may learn later, but that's beyond the point of this subject). We decided to look into JDBC logging.

Enabling logging in JDBC is a very subtle feature of JDBC, yet a powerful one. There is the ability to add a PrintWriter to your DriverManager. This partially helps and really is of no use if you are trying to look into the internals of the JDBC API. With a bit more of research, we learned about the debugging version of the JDBC driver. It contained logging using the java.util.logging framework. As I worked with this Oracle driver, the following worked only with the proper ojdbc version.

Ensure that you use jdbc5_g.jar (java 5) or jdbc6_g.jar (java 6). This is very important as these drivers contain debugging (and logging) information.
Ensure no other JDBC driver is used.
Add the following system properties: -Doracle.jdbc.Trace=true
Have a properties file with the logging configuration. A sample of this file can be found in the demo download of the jdbc driver distribution.

I also recommend adding a custom logging configuration location using the following:

-Djava.util.logging.config.file

This will allow you to add your own location for the configuration file. The resulting logging file will log even the calls made within the JDBC API which allowed us to discover an internal SQL query to retrieve the name of the tables (from the getTables() method mentioned above). This query was indeed a Statement, but a different one, thus p6spy could not possibly detect.

Hope this helps!

Useful Closures use-cases in Flex

2010-07-19T14:15:00.001-04:00

As flex is based on Actionscripts 3, it is possible to leverage some of the features of an ECMA-based language not readily available in strongly-typed languages. Most Java developers will probably ignore the ability to use powerful features such as closures when the use-case simply makes sense. Consider the following:

Function Handlers
In most cases where a function handler is needed, this tip may be very useful, particularly when you don't want to maintain "any" state within the object you create. For example consider the case of an HTTPService call.

var svc:HTTPService = new HTTPService();
  svc.url = "http://yourdomain/rest"; 
  svc.addEventListener(ResultEvent.RESULT, 
                       successHandler);

In this plain vanilla example, you need to have a successHandler method with the following signature:

public function successHandler(event:Result):void {
    // your implementation here
  }

What if you needed to add a handler with additional parameters. Then you can leverage the dynamic nature of actionscript and write a closure like:

svc.addEventListener(ResultEvent.RESULT, 
                       function (event:ResultEvent):void {
       handleResult(event, foo);
  });

and your new method to handle the result event will be:

public function handleResult(event:Result, 
                               foo:Object):void {
    // your implementation here
  }

ResourceManager use in ActionScript
Most tutorials I read were about the ability to do localization in Flex using the ResourceManager.getString() operation. In the case of binding to changes in the locale (as in the case of English to Spanish change), the recommended way to change is the following:

This way, the app if completely localized. Notice that binding to the value of the returning string is fulfilled by the use of the curly bracket notation. I found few discussion of what happens when the Label is created programatically (in actionscript). BindingUtils is a nice component from the Flex API that is aimed to solve the problem as you write a closure for the chain parameter (destination to be bound to). Here is an example:

BindingUtils.bindProperty(this, 
     "mylocalProperty", 
     ResourceManager.getInstance(),
     {  name:"getString",
        getter: function (rm:IResourceManager):String {
             return rm.getString('mybundle', 'property');
             }
     });

According to the API, the 3rd parameter can be an object of the form {name:"property", getter:"function(host)..." which means that the getter can now be a closure of your choice.

Hope this helps!

Localizing Flex Applications

2010-06-08T13:49:00.000-04:00

In my attempt to localize my flex application, it quickly became evident how simple it is to do basic localization in flex. As soon as I tried to implement more complex features, I realized how complicated it can become (e.g. add special characters, support multiple locales, flex builder problems, etc). In the interest of sharing the wealth, I'll describe the steps I took, so I don't have to keep on repeating some of these in future development efforts. These steps are:

Trade-offs between @Resource and ResourceManager
Configuration of resource bundles following the flex convention.
Adding it to the source path (not necessarily overlapping).
Flex Framework compilation (usage of copylocale)
Problems with FlexBuilder proper compilation of multiple
Special characters within resource bundles (ISO-8859-1 vs UTF-8)

Understanding the Tradeoffs @Resource and ResourceManager

@Resource and ResourceManager and basically the two ways to retrieve localized messages. The choice of either of these depends on the design and requirements of your application. I would imagine that if I have to do a "quick" prototype, the @Resource component is the way to go (although one can argue the need of localization during early prototyping). In constrast, the ResourceManager component provides a far more flexible way to configure the resolution of your bundles as well as the locale to be used to fetch all messages. One other caveat is that if you need to localize a .as file, then you are pretty much stucked with the ResourceManager object. Nothing bad, simply more configuration to add to your source code (with the ResourceBundle metadata tag). I have found that ResourceManager provides a far better approach to localization and will have to have a very good reason to use @Resource.

Configuring all resource bundles

All resource bundles (for those of you who are Java Developers) would be of the form .properties. The flex convention is that it should be in a directory named after the locale name. This is different than traditional Java conventions where the locale is part of the bundle name. The compiler flags can then use the token {locale} anywhere to denote the locale directory of choice.

Dealing with the source path

In most configurations I've seen, there's a need to have the compiler flag:

-allow-source-path-overlap=true

This is not necessarily true. This should be done if the directory containing the folder with the locale exists in the same directory where the source code to be compiled resides. FlexBuilder (as well as FlexMojos) provides the ability to add additional source paths which will allow you to compile just fine.

Flex Framework localization

In case this is your first time localizing an application in your development environment, you will need to do an extra step to properly run your application locally. There is a nifty tool called copylocale which basically allows you to generate a locale for the flex framework in the language of your choice (as long as its supported by the tool). The syntax is something like:

copylocale en_US destination_locale_name

So, in order to prepare your flex environment to use Spanish (Spain), you would have to do:

copylocale en_US es_ES

Upon successful execution, you should see a new directory in the frameworks/locale directory with the name es_ES

Problems with Flex Builder

Everywhere in the documentation it suggested to do the following (including FlexBuilder)

-locale=en_US,es_ES

This didn't work for me in FlexBuilder. I tried the following:

-locale=en_US es_ES

(notice the white space instead of the comma between locale names) and it worked fine. Flexmojos had a different configuration.

Special Characters

Regarding special characters, my main problem was to ensure that all file encoding to be UTF-8 (the default is ISO-8859-1). This is bad if you try to use the escape sequence characters in flex to add special characters. Once you configure file encoding in FlexBuilder (Preferences > General > Workspace), you are good to go. I copied and pasted the proper translation from Google translate. It worked very well (at least for me).

Hope this helps!

My thoughts on RabbitMQ

2010-05-17T22:48:00.000-04:00

It is no mystery that I have been following the Spring Portfolio for sometime now. As I continue to observe the business decisions they are making, its exciting to see how SpringSource is positioning itself to be a powerful player in the Enterprise Development arena. Some months ago, SpringSource announced their acquisition of RabbitMQ and I thought I should get familiar with their choice for messaging solution.

I'm not going to discuss the associated need for a messaging system as a solution to integration of systems (Message Oriented Middleware). Instead I will mention a couple of observations about RabbitMQ.

First, the idea behing AMQP (Advanced Messaging Queuing Protocol) seems to emphasize the idea of interoperability. I have worked in environments where .NET integration was always a requirement, hence WS-* was always a compelling solution in so many ways. The idea of having a standard to establish a messaging contract (as opposed to an API such as JMS) seems a very powerful one. Of course, this makes even more sense when you think that a messaging system in the cloud ought to support a heterogenous environment.

In addition to this, there is already a trend about understanding comparisons between AMQP and XMPP (a favorite choice). I was very pleased to find these remarks favoring AMQP for many good reasons, which I'm yet digesting myself. And today I came across this article explaining High Availability lessons learned in Reddit and how RabbitMQ was a "key" component in their architecture. I have a personal project I have been working on which I can disclose just yet, however I can't wait to start playing with more features from RabbitMQ client and server to implement some of my business requirements.

So far, I just finished installing it in MacOSX (using macports):

sudo port install rabbitmq-server

And the install happened fairly fast. I'll try to post some of my findings as I go. Exciting times ahead!

My Git Configuration

2010-04-28T00:28:00.002-04:00

I have configured Git locally in many places now and I thought of placing a copy of my personal choice (my .gitconfig file). Perhaps this will help me setup my personal environment everywhere I'm using it. I should put this on github at some point. A few things to notice:

I prefer p4merge for merge tool. It's simply awesome, worth to try if you haven't yet.
Vim as my editor. Yes, I don't use emacs.
Yes, I code on a Mac!

My .gitconfig as follows:

[user]
   name = Alberto A. Flores
   email = aaflores@gmail.com
[core]
   editor = vim
[mergetool "p4merge"]
   cmd=/Applications/p4merge.app/Contents/Resources/launchp4merge "$PWD/$BASE" "$PWD/$REMOTE" "$PWD/$LOCAL" "$PWD/$MERGED"
   keepTemporaries = false
   trustExitCode = false
   keepBackup = false
[color]
   status = auto
   diff = auto
   branch = auto
[color "branch"]
   current = yellow reverse
   local = yellow
   remote = green
[color "diff"]
   meta = yellow bold
   frag = magenta bold
   old = red bold
   new = green bold
[color "status"]
   added = yellow
   changed = green
   untracked = cyan
[apply]
   whitespace = nowarn

Spring Roo: Persistence Setup

2010-04-28T00:16:00.001-04:00

I've found Spring Roo to be a great way to learn how to setup configuration properly. As I continue to spend time in configuring my home project, I continue to be amazed at the powerful features that Roo brings to the table. I had written a small application for tracking family chores. I spent about 25 minutes drawing the entities in a napkin, then spent 10 minutes writing a Roo script (file with extension "roo"). Then, I opened a Roo shell and run "script myscript.roo". This created my project, including all the scaffolding for my entities. I had my project running in minutes. After a while, I detected a problem with my entities relationship and wanted to see the persisted data. Of course, I had the the "IN MEMORY" choice, which brought all sort of problems when trying to see the data within.

If you have used Roo for a few minutes only (as it tends to encourage you, to due to its simplicity), you have probably used the HYPERSONIC_IN_MEMORY database configuration. This is good for a first prototype, however once you start adding data, you want to start using HYPERSONIC_PERSISTENT or simply another available database as described with the --database parameters. Roo makes this change a very pleasant experience. I chose MYSQL (since it was already installed). What a pleasant surprised that all I had to do was to write the following:

persistence setup --provider HIBERNATE --database MYSQL --userName --password --databaseName

At this point, all appropriate files were updated. Since I was using git for version control, I was able to see the files updated. Not only was the pom.xml updated, but also the database.properties touched with the new configuration for the jdbc connection. I also noticed that the persistence.xml file was changed from "update" to "create" (I have to change this back to "update" if I want to continue seeing my data after reloads). This was nice as it makes sense to create the schema when it doesn't exist. I opened DbVisualizer and was happily browsing my newly created tables without problems.

In a few words: Bravo Roo!

Mavenizing a Flex Project with multiple artifacts

2010-04-02T00:15:00.001-04:00

I was asked to include a Flex project within the current build process in place (maven2 based). Now, I like maven for many reasons which I'm not going to explain in this entry, however I would like to say a bit about my experience with such a "mavenization" if you will. Most Flex projects I've been involved are developed either directly in Flex Builder (Fb3) and/or compile using an Ant task. Nothing wrong with this approach, however Maven encourages a convention that may not necessarily be embraced in a traditional Flex Application. I hope to explain what I mean by this in the next paragraphs.
In Flex, a project typically is composed of a default application (an MXML file) and possibly Module components, stylesheets (compiled to SWF files), configuration files, etc. If some of these are within the same project, Fb3 will compile each of them and generate their SWF files properly. The "export" release feature of Fb3 is also a nice feature to do deployments from the IDE. Granted, this feature is nice to have, however following the "maven way", I quickly realized that this "mavenization" process will take longer. This was mostly due to the convention that each maven project aims to build ONE artifact and only one. The project I had was building 15 SWF files (some modules, some css files) as well as 17 XML files. This was simply not acceptable for maven standards.

As a first pass, I decided to make the project generate a zip file containing each artifact. This would at least ensure one artifact for this project and ensure users to have a corresponding unzip process where each SWF/XML file can be used in a deployment. Now, the next iteration, I moved from a one maven project style (zip file) to a multiple project (nested) style where each module compiles to and becomes a dependency of the main application project (yet another SWF file). All this setup was nicely done using Flexmojos integration with Maven. Flexmojos is a nice tool for using Flex within a maven setup, however it has bugs of it own (e.g. depending on the packaging style, Flexmojos may do weird things such as compile Modules to non-swf extensions, or compiling flex code twice, etc). When properly configured, using Flexmojos can be a pleasant experience for most maven setup.

My Journey into using efflex

2010-03-25T00:54:00.001-04:00

As I tried to introduce powerful animations to personal RIA project, I came across this project called Efflex. The demos showed a lot of potential. I was very impressed with some of the nice features to improve ViewStack selection (particularly the Flip3D and Cube3D demos). As my excitement drove me to use it, I found so many problems integrating to it, particularly with the following:

There were no SWC files to use (the 2 provided never worked).
Building the source required FlexBuilder as well as to understand the project layout.
Some of the code was not committed, hence the compilation failed in so many ways.
There were dependencies that were not documented.

I took this as a personal challenge and I can happily report that I made it work. I'd like to describe what I had to do to make it happen in case others go through this problem (as I suspect it's the case based on some of the postings I read on the site).
As of the writing of this entry, all what I'm about to describe remains true. I have found some postings with instructions for a old revision of the efflex project. Things have changed a bit, particularly with flex4 and Fb4 (now out). For the purposes of this writing, it's important to point out that all these problems occurred in trying to use the CubeAway3 effect.

Attempt 1: I tried the obvious: using the SWC files found on their site. Of course, this didn't work at first. I was trying to use the CubeAway3D effect. Fb3 kept on reporting compilation errors (primarily on a missing type). As Tink (the author of the library) suggested to use the source code and build it yourself (post found in the efflex site), I tried checking out the source code and importing it into Fb3.

Attempt 2: The import was somewhat troublesome as the source code (from svn) was not complete. I mean, there were missing classes (apparently never committed). Also, I found some classes that required some dependencies that were not documented anywhere. These were away3d, papervision3d and tink (the last one was simply a utility project).

Attempt 3: I imported the source code of away3d. This didn't take much time to fix, other than to ensure that I was compiling for flash player 10. Once that was fixed, I generated a SWC. Success!

Attempt 4: I imported the source code of papervision3d. Luckily this didn't cause much problem either. It was pretty straight forwar, however any documentation on this would have helped (in lieu of a SWC).

Attempt 5: I checked out the source code for tink. This was apparently another utility project developed by the author of efflex. Fine, I accepted his philosophy, so I moved on. Luckily it compiled fine.

After doing all these, I decided to remove the non compiling classes (from the efflex project). I decided that as I checked this out from svn, I can recover them later (when their needed classes are committed). This helped compile and generate a SWC file which I was now able to use. As I tried it, my CubeAway3D effect worked like a charm. It was very rewarding to see my ViewStack more vividly, nonetheless, I think we need to evaluate better how we can improve some of these projects.

Alternate Tooltip for items

2010-03-23T12:02:00.000-04:00

I spent sometime trying to understand ways to add tooltips for items within a <mx:List ..> component. As I naively used the dataTipFunction(), it was pretty evident (at least in my case) that I needed something whereby I can have more control, a more robust solution than the out-of-the-box solution. This is when I decided to use the itemRollOver and itemRollOut events and corresponding handlers.
According to the Flex 3.5 SDK, the List control:

"...displays a vertical list of items. Its functionality is very similar to that of the SELECT form element in HTML..."

As with most things in Flex, the List control extends a base class where a lot of functionality is already defined. In this case, it's the ListBase control. This control, has a property that can point to a Function. This is the dataTipFunction() which enables the tooltip feature of each item in the list. The fundamental problem with this approach is that the generated IToolTip containing the text can not be properly manipulated (say to modify it's location, color, rendering component, etc). In my particular case, I went for a different approach.

Instead, I used the itemRollOver and itemRollOut events to properly operate on a customed IToolTip. Using the ToolTipManager.createToolTip() I was able to not only create my custom tool tip, but also put a position to it so it will not block what I'm mousing over. Now, yes, this was more work as I had to manage the livecycle of the IToolTip instance (only a few lines of code), but I was able to do so much with it (e.g. delay the showing of the tooltip).

My Review on Spring-Roo

2010-03-13T23:25:00.000-05:00

So I gave a presentation about Spring Roo recently. Hopefully this means I'll get a kangaroo. I felt it went pretty well. I decided to share some of my remarks as I think I learned more by presenting than by trying it. As I can not put a presentation on my document (yet), I'll show the text of my slides and will explain some of the things I discussed while presenting.

Describing Roo

Rapid Prototype tool for the Java Platform.
Non-Invasive approach to development.
Proper use of open source frameworks.
Handles Infrastructure configuration
Intelligent Code Generator (Active vs. Passive Generators)

I basically defined Roo as a tool that can help you learn (if you are new), refresh (if you are Spring savvy), or simply complement your current skills. Although Spring has made a tremendous job in keeping us away from traditional J2EE development (EJB, xDoclet, Ant, etc), managing Spring configuration is extremely easy with Roo. No need to understand a complete Transaction Strategy in the beginning. No need to understand how to setup i18n configuration, nor how to setup a JPA provider. I also took time to explain about Roo's powerful shell and how it synchronizes with changes you can make with the IDE (managed asset).

Installing Roo

JDK 5.0 or greater
Maven 2.0.9 or greater
Spring Roo Binaries

In this slide (very short) I essentially emphasized how wonderful I managed to work with Roo at home in a machine where I didn't have admin privileges. This opened some eyes as I sensed some of my audience had the same problem. Furthermore, the idea of the shell was very compelling to some folks. Also, I noticed that hitting the "Tab" for hints was a nice feature to have. I could immediately tell most of the folks in attendance would prefer command prompt whenever possible.

Roo Concepts

Under the covers, Roo uses AspectJ and Java
Changes are done at the byte-code level
Strong use of Inter-Type Declarations (ITD)
Leverage the power of Privileged Aspects
Annotations are defined with Source-Only Retention Policy

I felt that this is where I spent most of my time (aside from the Demo I gave). I explained the concept of ITD as it was fairly new to some of the audience. Also, I had to explained a bit about Privileged Aspects. I had sensed (from the previous presenter) that the audience was not well versed in AspectJ (nor AOP), so I took my time here to help the audience understand that a "cross-cutting" concern does not necessarily apply to business logic. It was a good discussion. After answering some of the questions I had, I turned to build an application which some of us have been talking about building, of course this time it was a lot faster.

Value Proposition

No vendor Lock-In
Zero performance/memory overhead
Zero deployment footprint
Consistent applications across teams
Leverages investment in the Java Ecosystem
Small learning curve, great to learn proper usage of Spring.

I felt I needed to present why is the "Roo" proposition a good one. As a convert to Roo, I liked the lack of vendor lock-in. I also appreciate the great "use-case" for AspectJ in the context of this tool. It makes complete sense. I also stressed the point of how to help "entry" level Engineers to learn powerful concepts which could take days to read on their own.

Further Topics

Dynamic Finders
Integration with JMS and Email
Integration with Webflow
Integration with Spring Security
Custom Add-on's
Roo Architecture Patterns

As my presentation took longer than anticipated, I didn't have the chance to discuss these, however I had purposely left it in case I would have finished early. I suggested a future discussion of this topics, particularly about "Dynamic Finders" and some of the architectural choices which Roo encourages (e.g. No DAOs, Optional Service Layers, etc).

I sensed good feedback, and once again I learned the obvious: One learns more by sharing than by reading.

Lessons learned at 360Flex

2010-03-11T22:34:00.000-05:00

It's time to reflect a bit about the latest 360Flex. This was a good time to learn about Hardware integration with the Flash Platform. Here we have integration with Arduino boards (via as3glue or merapi). Also, I learned a bit about JComm as well as how these sensors can send Event objects whereby one can react and listen (think credit card readers, robots, etc). Nice possibilities that make so much sense for thick client applications using Adobe Air... Very exciting.

I also learned about Reflex, a new open source project aimed at building lightweight components for the Flash Platform. Unlike Flex, Reflex components do not extend UIComponent, thus allowing components to have less clutter. Most of these is achieved by virtue of Sprite objects This means that custom UI components simply do what they need to do without all the properties (that are hardly used yet consume space in the Flash Virtual Machine when loaded). With the much heated debate between HTML5 and Flash, it is certainly possible that Reflex can make companies in the mobile device industry (e.g. Apple) believers in the Flash Platform (again) since lightweight components really means less SWF file sizes and, potentially, less energy consumption. Very compelling value proposition!

I also learned about the Swiz Framework, Robotlegs and the Mate framework. So far, I had a chance to play with Swiz and I'm liking it very much. I've been suggested to also try Robotlegs, so I'll give it a try in the next few weeks. Very cool days coming ahead for me. Can't wait to try these!

Last, but not least, I was very impressed by some of the changes in Flex 4 (that is not Spark). I heard a presentation from Deepa Sabramanian (now a Product Manager of the Flex sdk) presenting these changes. I was very happy to see some of the compiler optimization, the Text Engine framework as well as some of the integration with Pixel Bender. Very nice demo showing possibilities. Very exciting!

In summary, I'm looking forward to experiment with the some of the frameworks shortly.

Monkey Patching in Flex

2010-03-10T15:23:00.001-05:00

I recently attended 360Flex. It was an excellent conference. I thought I knew some Flex, but I was certainly not aware of how much others are doing with Flex, Actionscript and the Flash Platform in general. Very interesting concepts. One of the nice concepts I recently learned while at San Jose was "Monkey-Patching". Fortunately, I had the chance to practice how to use it after the conference and learned so much about the internals of some Flex components. Here is what I did.

First, let me explain the obvious. "Monkey-Patching" is the concept where one can extend or modify runtime code (for a further explanation, please refer to wikipedia). In this case, we are leveraging the dynamic nature of the ActionScript so as to learn some of the internal operations that occur in the Flash Platform, particularly as pertaining to our Flex code.

As I've been working on Module loading using the ModuleManager class, I decided to try to "Monkey-Patch" the ModuleManager.as found in the mx.modules folder. I quickly learned more than I knew about the code. I decided to add trace() calls before each method. Then my code revealed a lot nice goodies about the Module loading mechanism provided. I won't deprive you from the thrill of looking for these, but enough to say that there's some caching (internal) that happens should you try to load the same module twice. Needless to say, I was very excited to see what else can I do with this.

Among other things worth mentioning (where I heard the term "Monkey-Patch"), I learned about this project Reflex. It's a framework that it's all about using the Flash Platform (not flex). It's an action-script framework that is meant to reduce the overhead generated (or introduced) with Flex and make component lightweight, thus making faster downloads of SWF files, possibly reducing power energy (so essential in this mobile revolution), etc. The possibilities are endless. I'm very excited to see where this project goes and will try to watch it.

Understading some of Roo's magic

2010-02-16T22:11:00.010-05:00

I must admit that I was among the many developers I know who are very skeptical about Aspect Oriented Programming (AOP). I've written many aspects myself, some which I now define as "entry-level". I had not seen a clear use-case for aspects other than the basic "auditing", "logging" or "security" use cases. So, a few months ago I started to play with one of the latest tools from SpringSource, namely Spring-Roo. To my surprise, Roo was not only meeting my expectations, but also made me a believer on yet another good use case for AOP. The use case of tooling support. I'll try to explain some of the magic which Roo brings to software development using AspectJ.

Consider for a moment the following entity:

public class MyPojo {
  private String name;
}

This entity can easily be coded using any IDE, however Roo allows you to create it with a command line shell. Once this is done, the average developer will rely on source generation features (from an IDE) to generate Setter/Getters (so as to conform with standard JavaBean conventions). This is where the concept of Inter-Type Declarations (ITD) in AspectJ can be of great help. Consider the following aspect:

public aspect MyPojo_Entity {
  private Long id;
  private static int sequence = 0;
  
  /** 
   * Constructor with arguments
   */
  public MyPojo.new(String name) {
    super();
    id = new Long(sequence++);
  }
   
  /**
   * ToString method.
   */
  public String MyPojo.toString() {
    return "Sequence: " + id;
  }
}

You can see that this aspect is now introducing a new constructor as well as a toString() method for the entity MyPojo. The resulting bytecode will now have a toString() method which can be called anywhere. Also, it will enforce the constructor to be called with an argument. This notion of ITD can be used to introduce new methods as well as private properties. Now, let's finish this aspect:

public privileged aspect MyPojo_Entity {
  private Long MyPojo.id; 
  private static int sequence = 0;

  /**
   * Constructor
   */ 
  public MyPojo.new(String name) {
    super();
    this.name = name;
    this.id = new Long(sequence++);
  }
 
  /**
   * Retrieves the id of this pojo
   */ 
  public Long MyPojo.getId() {
    return id;
  }

  /**
   * Retrieves the name of this pojo
   * @return the name of this pojo.
   */ 
  public String MyPojo.getName() {
    return this.name;
  }
 
  /**
   * Sets the name of this pojo.
   * @param name the name to set.
   */ 
  public void MyPojo.setName(String name) {
    this.name = name;
  }
 
  /**
   * Default toString() method.
   */ 
  public String MyPojo.toString() {
    return "Pojo [id="+this.id+"]: " 
          + this.name;
  }
}

As you can see, we not only introduced the methods needed to make MyPojo compliant with JavaBean standards, but also added more attributes and methods (e.g. to help persisting it). Furthermore, if you look closer, the aspect definition now uses the privileged keyword. A privileged aspect basically grants access to private attributes and methods of the class in question, thus we can use the this.name for this purposes without problems.

If you look at the generated code from Roo, this is exactly how Roo makes magic happen. In fact, Roo also injects an EntityManager as well as hashCode(), equals(), as well as other methods based on the cross-cutting concern. It's defitenetly worth checking out Roo for a good test-drive, not only of the tool, but how to use AspectJ effectively.

Removing Unused Workspaces from Eclipse

2010-02-11T11:41:00.002-05:00

Workspaces in Eclipse is one of those features that are often unused or not used enough. Personally, I find it extremely helpful to use them, particularly when working on different branches. There are times when you need/want to delete some of these workspaces from your workspace list. Here is how you can do this:

Go to the Eclipse directory where you installed Eclipse (I'll refer to it as $ECLIPSE_HOME from here on).
Open the file $ECLIPSE_HOME/configuration/.settings/org.eclipse.ui.ide.prefs with your favorite editor (obviously not Eclipse).
The key RECENT_WORKSPACES should have a comma separated list of all previous workspaces your IDE has used. Remove them as needed/wanted.

Needless to say, this should be done while Eclipse is not running. At this point, you can safely remove the directory where the workspace resided. BTW, these instructions work well on the SpringSource Tool Suite (STS).

Spring: @Autowired Constructors

2010-01-30T00:38:00.002-05:00

Since the introduction of Spring 2.0, I have seen a trend where developers use the @Autowired annotation very often. I must admit, I like a combination of annotations with some XML declaration, however I'm still debating whether making a decision of using @Autowired scales well in the long run. I would like to show how this feature can seem unintuitive. Furthermore, even tools like SpringSource Tool Suite can get confused at times.

Consider the following two POJOs:

public class FirstPojo implements Pojo {
  /**
   * Default constructor, no argument
   */
  public FirstPojo() {
  }
  // Other methods and logic here
}

public class SecondPojo implements Pojo {
  /**
   * Default constructor, with one argument
   */
  @Autowired
  public SecondPojo(Pojo firstPojo) {
  }
  // Other methods and logic here
}

Notice that one contains a constructor which is annotated with @Autowired. What this means is that you can potentially have the container define such a bean as follows:

Can you see the problem there? Now our declared XML claims that the SecondPojo has a constructor with no parameters, even though we can clearly see that such is not the case. It's hard to explain the average user that such behavior is possible due to Spring-AOP and how these kind of beans are really proxy objects. When the container detects an @Autowired constructor, the Spring-AOP infrastructure ensures that such constructor exists (so as to execute whatever logic is within that constructor). Also note that all dependencies are also @Required (as per the docs). Furthermore, it looks like the SpringSource Tool Suite (as of the writing of this entry) also has problems detecting this "feature" as normal behavior. See JIRA issue IDE-1042 for more information (looks like it's planned to be fixed on the soon to be 2.3.1 release).

Now, my personal feeling is that this @Autowired behavior is due to the mixing of declarative XML with annotations. Not necessarily a bad design from SpringSource, but simply a consequence of Spring's goal of helping with simplicity. @Autowired is really simple to use, but without full understanding of what's really happening, it can be confusing in the long term, particularly when a project grows in the number of managed beans. A good strategy (mostly maintained through the discipline of code reviews) is to choose this @Autowired constructors to also be detected with yet another annotation (e.g. @Component, @Service, @Repository, etc). If a bean already has an @Autowired constructor, it only makes sense to continue annotating the class (at the class level of course) with one of these stereotypes annotations so as to make it very clear how this beans is to work and how it's dependencies be injected. Interestingly enough, SpringSource Tool Suite seems to like this approach and can even graph it nicely.

Spring 3.0 and

2010-01-28T00:46:00.008-05:00

I have used Struts1 and Struts2 extensively for years. With that background, I can appreciate some of the things that Spring-MVC brings to the table such as Dependency Injection, clean integration with Bean Validator (JSR-303), smooth Integration with different View Technologies, among others. Furthermore, Spring-MVC has been making improvements through out each release that has made it a more robust framework, including the latest REST support. Like every framework, there is always a "gotcha" in a feature and such is the case for <mvc:annotation-driven />

<mvc:annotation-driven /> is a nice feature, however depending on how you are used to organize your Spring-MVC files, it can prove to be confusing. I'll try to explain my findings as clear as I can.

As you know, Spring-MVC will expect a <servlet-name>-servlet.xml Spring configuration in the WEB-INF (unless configured otherwise in web.xml). If you also load an application context via Spring's RequestContextListener (hereto known as the root WebApplicationContext), the servlet XML (WebApplicationContext) will inherit the beans from the root context. Although this is a known fact, the problem comes when the servlet XML is not able to read any @RequestMapping metadata from beans (@Controller objects) detected in the root WebApplication Context. The logs clearly show that the beans are detected, but not the metadata.

This means that in order to use <mvc:annotation-driven />

you have two choices:

The servlet XML now needs to contain <mvc:annotation-driven /> and be able to detect the @Controller objects so it can refer to the metadata in those controllers to use (e.g. via <context:component-scan /> ). All these within the same XML file or via imports.
The root XML needs to have the declarations as mentioned above (<mvc:annotation-driven /> and <context:component-scan />).

I prefer to use the first one, and make my scan reach only the packages that are specific to the design of your servlet, however I can see how option 2 may be a more compelling option for small applications. Interestingly enough, that's how all sample applications using <mvc:annotation-driven />

are configured.

For further reading of this new features, take a look at JIRA issue SPR-6524 where Jurgen Hoeller and Keith Donald explain their thoughts on why <mvc:annotation-driven /> is supposed to behave like this.

Hopefully this helps some!

XML Validation within Eclipse

2010-01-26T11:15:00.001-05:00

  Working with XML can be a wonderful experience. Most people I know (in the industry) don't consider XSD/DTD validation a task that is challenging enough so as to spend time and/or effort to either learning it or writing to it. This feeling changes rapidly as tooling support (e.g. IDEs) produces hiccups when XML validation generates errors that can not be understood by the same engineering staff. For example, have you ever had the infamous problem reported through Eclipse's console:

cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'custom-filter'.

  By default Eclipse has XML validation on. This means that it will look for a DTD of XSD to validate your XML file. The message above indicates that there's an XML element named custom-filter that can not be resolved with any of the XSD that Eclipse is aware within it's catalog registry.

  Now, most people I know turn off XML validation so as to not to deal with this problem. This is simply a terrible idea and bad practice. XSD definitions provide much richer ways to describe XML constructs, including comments. When the setup is properly configured, it can be a very handy tool (even for learning purposes). Craig Walls wrote a blog with instructions in how to add a new Catalog entry in Eclipse. The post can be found here.  Note that you may find the same problem if you have an older version of Spring Source Tool Suite (STS) and are upgrading via the update site. The way I dealt with this is typically a full rebuild of my project so that STS (or Eclipse) can allow XML tooling to magically occur.

Hope this helps!

Dynamic Web Projects in Eclipse

2010-01-25T23:22:00.002-05:00

As I fixed a maven war project to more effectively use the Web Tools Project (WTP), I realized I could share the configuration I used with the hope to help others get some light as needed. I'll be assuming you are familiar with the .classpath file as well as the .project file (which Eclipse uses heavily) to setup the dynamic web project. Furthermore, I'll assume you are familiar with the notion of a "nature" within the Eclipse environment. Lastly, I would like to refer readers to the official Eclipse FAQ. In particular, I would like to refer you to the section where the sharing of the .project and .classpath files in version control (e.g. subversion, git, etc) is considered a good practice. Note that these tips will also work with the Springsource Tool Suite (STS)

The first thing you need to worry about is to make sure you have all bundles installed from the Java Enterprise Update Site. Notice that this is different that the standard Eclipse distribution. If you successfully installed it, you should have the ability to create a new "Dynamic Web Project" from the new Project menu. Once that is in place and you created a new "Dynamic Web Project" take a look at the .classpath file. It has some entries of type "classpathentry". It should look something like:

The kind of classpathentry "con" means "classpath container". It's the way WTP will resolve classpath entries as you deploy your Dynamic Web Project via Eclipse. Now, take a look at your .project file. It should look something like:

There could be other buildcommand entries or other nature entries, however these are very important to have in order to enable all tooling support for a "Dynamic Web Project". Now, the one file that has some more information is found within the .settings folder. This file is named org.eclipse.wst.common.component. This file is very interesting. It shows how Eclipse (or STS) will deploy the project to the Server of your choice (e.g. Tomcat). It should look something like:

Hopefully, this file speaks for itself (as far as to understand how WTP deploys this project as an "exploded" war). Notice that I'm using a traditional maven directory structure for defining a webapp. As these files are in place, you should be able to execute the "Run In Server" command (from the "Run" menu) and, assuming you have a server configured, you should be able to see your web application running via Eclipse. Of course, this means you could not only "Run" but also "Debug" whereby all your breakpoints and other debugging tools would work seemlessly.

Developing on Windows and jps

2010-01-20T20:00:00.001-05:00

In the last few months, I have been forced to develop using a Windows environment. I must admit I miss most of my linux/unix command prompt usage, among which is the "jps" tool. For those of you not familiar with it, jps is a "process status" tool and is part of the jdk. According to the documentation, this is an unsupported tool and comes with no guarantee, however I've found it to be a simple tool that can come in handy in certain situations as the one I'm about to describe.

During my initial maven build, the test phase was throwing exceptions due an incorrect configuration. As I tried to delete the target directory, windows reported the folder was in use. Cygwin's "ps" command didn't reveal much. Window's "Task Manager" wasn't really saying much either. This is where "jps" brought light. Jps reported the SurefireBoot.jar still hanging in there (apparently due to some unrelease resource). Unfortunately, the problem became even more serious as the reported PID was not that simple to kill (using Cygwin's kill command).

As I researched some more on this, I came accross the following post where the issue of the TMP environment variable fixed some problems. As soon as I did this (setting the environment variable), I was able to resolve my problem (in my case, it was an issue with proper security in the TMP folder and its subfolders). This was not a "show-stopper", but certainly a nice to know as this TMP folder is not only used with jps, but also with jvisualvm, another nice free tool from the jdk.

Flex: DateTimeAxis and ColumnChart components

2009-12-31T07:25:00.027-05:00

I love flex. It is a framework where you can do great things, however there are a number of "gotchas" as with every framework. Not necessarily a bad thing, so long as it is documented properly. This is what I found when using the ColumnChart component within the data-visualization framework of flex in combination with the DateTimeAxis for the xField. I had an object using the following structure:

public class MyChartItem {

    public var time:Number;

    public var amount:int;

}

Notice that one of the properties represents the current time. It's represented by a numeric field (Number type). This model should allow for an exact representations of time when serializing a remote object back to its counterpart in ActionScript.
Of course, I choose to use a DateTimeAxis to let me render this numeric "xField" within the ColumnSeries. It was configured like this:

I wanted to display data every second however the time property would be in milliseconds (epoch time). My surprise was that as the bound dataProvider object was updated, no chart was being displayed. I struggled with this for some time until I placed the mouse over the graph. Flex was showing the data points summary of the chart, but no graph!

Upon further research, I found this piece of documentation which brought a lot of light to my development. From the Flex documentation.

"Some series use the value of the dataUnits property to affect their rendering. Specifically, most columnar series (such as Column, Bar, Candlestick, and HLOC controls) use the value of dataUnits to determine how wide to render their columns. If, for example, the ColumnChart control's horizontal axis has its labels set to weeks and dataUnits set to days, the ColumnChart control renders each column at one-seventh the distance between labels." (Flex Docs)

Ah! So it was a problem with the way the flash player was computing how to render the chart control. In particular, flash was thinking that each Column in the chart should be of one-thousandth distance. So I continued looking and found the "dataInterval" property in the "DateTimeAxis" API:

"If, for example, the dataUnits property is set to "hours", and dataInterval property is set to 4, the chart assumes your data occurs every four hours. This affects how some series (such as ColumnSeries and CandlestickSeries) render their data. It also affects how labels are automatically chosen." (Flex API)

After setting my "dataInterval" to 1000, I was back in business and my graph displaying properly again. Lesson learned: never boast that I know Flex. I can only say I can use flex and have found some tricks to make User Interfaces look fun.

Tiles2 with Spring without Spring MVC

2008-10-27T12:27:00.005-04:00

In the process of making my application OSGI enabled, I came to the conclusion that it would help me better to have Tiles2 to be managed by Spring. This is so as to have more control of the Tiles2 configuration instead of the configuration needed in web.xml. This is when I found the TilesConfigurer class from Spring. Here is a snippet of for my configuration.

Now, this means that web.xml no longer needs the Tiles2 listener but simply let Spring's Servlet configuration do the initializing for you. If you are using Spring MVC, this is already done, if you are not, you may need to use RequestContextListener or the ContextLoaderListener so that this tilesConfigurer bean is placed in application scope similar to what the Tiles2 configurer does out of the box.

Warning: leaving the Tiles2 listener (along with the configuration above) will still try to load the tiles.xml from the default location (WEB-INF folder) so you may be overriding the work already done by Spring's SpringBeanPreparerFactory. Take a look at the generated logs for further detail. Once you have this, now you have control (in Spring) over Tiles2. I wanted to add a custom TilesDefinitionsFactory so I created my own as follows:

package myPackage.MyTileDefinitionsFactory;



public class MyTileDefinitionsFactory extends UrlDefinitionsFactory {

  public Definition getDefinition(String name, 

                     TilesRequestContext ctx)

    throws DefinitionsFactoryException {

    Definition tileDefinition = super.getDefinition(name, ctx);



    // add you own logic to modify/update template and/or tile



    return tileDefinition;

  }

}

With this new factory, now we were able to introduce custom menus, tabs, and other widgets to screens based on roles and/or other business ruls (e.g. workflows). Furthermore, we were even able to change the backing template (eventhough the Tiles2 documentation says you can not change the template of a tile dynamically, this did the trick). There are many other possibilities opened with this approach that I'm sure some will find useful.

One more thing to keep in mind, you need to setup the property useMutableTilesContainer to true so as to be able to great dynamic tiles. As you read the Tiles API, you can potentially create your own tiles dynamically as well as simply modify existing ones. I found this approach to be a very powerful one when integrating Tiles2 with Struts2.

Hope this helps!

Generics and DAOs

2008-10-09T10:30:00.010-04:00

Since the coming of Hibernate 3, I have started to refactor a lot of code that I simply didn't need anymore. Among these, my data access objects have always seemed repetitive. Repetition (in my opinion) calls for code refactoring. The hibernate tools project aims at fixing this problem by providing a "Dao Code Generator" which can certainly help. Additionally, other tools out there offer similar solutions, however one must understand how much the JVM will have to use in working with our "dao-centric" application. Can we do better?

With the introduction of Generics in Java 5, I found a good way to make good use of this generic approach to DAO's without breaking my application logic. Consider the following code:

package sample;



public interface GenericDao

<T, PK extends Serializable> {

/**

* Persists the new instance object into the

* persistent store.

* @param newInstance - the instance object

* to persist.

* @return the primary key of the T object.

*/

PK createEntity(T newInstance);



/**

* Retrieve the an object that was previously

* persisted to the persistent store using the

* primary key passed in the parameter.

* @param recnum - the primary key of the

* persisted object.

* @return the object instance.

*/

T getByRecnum(PK recnum);



/**

* Deletes an entity from the persistent store.

* Note that all cascades associated in the

* persistent object (JPA) are applied. If

* orphans are needed, you must brake the

* association first before deleting this

* entity.

* @param recnum - the primary key of the

* entry to delete.

*/

void deleteEntity(PK recnum);

}

This interface defines a generic contract for data access to an object of type T with a primary identifier (primary key, if you will) named PK that is of type Serializable (more on this on some other post). Now, consider the following hibernate implementation:

package sample; 



public class HibernateGenericDaoImpl<T, PK extends Serializable>

      implements GenericDao<T, PK> {

  private HibernateTemplate m_hTemplate;

  private Class<t> m_type;



/**

* Default Constructor for this implementation.

* @param type - the type of DAO to generate

* @param hibernateTemplate - the template to

* use.

*/

public HibernateGenericDaoImpl (Class<T> type,

         HibernateTemplate hibernateTemplate) {

  m_type = type;

  m_hTemplate = hibernateTemplate;

}



/**

* {@inheritDoc}

*/

@Override

public PK createEntity(T newInstance) { 

  return (PK) m_hTemplate.save(newInstance);

}



/**

* {@inheritDoc}

*/

@Override

public T getByRecnum(PK recnum) { 

  return (T) m_hTemplate.get(m_type, recnum);

}



/**

* {@inheritDoc}

*/

@Override

public void deleteEntity(PK recnum) {

  T entity = getByRecnum(recnum);

  if (entity != null) {

    m_hTemplate.delete(entity);

  }

}

}

This implementation of the GenericDao contract uses Spring's HibernateTemplate which is a thin layer on top of Hibernate. It basically uses the template to perform operations on object model T. Of course, you can add more generic methods as needed, but the idea is the same. Possibilities are endless. Now, with the following Spring's configuration:

And the following service code:

package sample;



public class BarService {

private GenericDao<Foo, Long> m_fooDao;



/**

* Default constructor with injected dao

* @param fooDao - the dao to inject.

*/

public BarService(GenericDao<Foo, Long> fooDao) {

m_fooDao = fooDao;

}

}

This means that the Service code can now have an injected dao that is generic. With these generic approach to DAOs, you now avoid writing custom code for each model object (in our case, of type sample.Foo). Now, my strategy for ensuring that my application will not turn into a critical state was to make sure that all our unit-test passed after the code refactoring process had finished. My code coverage percentage certainly decreased as I removed custom implementations of unneded DAO and encourage the use of the generic Dao

Keep in mind that Generics are supported in other languages as well, so this approach can certainly be re-used (if at all).

Struts 2 Validator on Forwards

2008-09-30T12:10:00.008-04:00

As I had to add some complex features to our working Struts 2 application, I had to deal with already built in validator functionality in Struts2 that could be complex. Specifically, when dealing with conversations-like scenarios, this problem can really be a big one if the validation associated with the forward request is applied via annotations, xml or the validate method. I thought to share some snippets that hopefully will someone. Consider the following:


package sample;

public class MyValidatorInterceptor1 
     extends AnnotationValidationInterceptor {
 /**
  * Method that is triggered in prior to calling
  * the intercept() method. This method allows
  * to control whether the intercept is disabled
  * in certain condition.
  */
 @Override
 protected boolean applyInterceptor
            (ActionInvocation invocation) {
  boolean certainCondition = true
  if (certainCondition) {
    return false;
  }
  return super.applyInterceptor(invocation);
 }
}

This interceptor implementation as described above enhances the provided AnnotationValidationInterceptor from Struts 2 to disable the interceptor on demand (based on some condition). It's important to mention that the code above extends the class AnnotationValidationInterceptor as base class so as to not take away current functionality offered in Struts 2 (validation annotation). Additionally, the doIntercept() method may be overridable to perform additional validation that can be applied per class. Consider the scenario where you define your want to add validation complex validation per method and disable all required validations in XML. This certainly introduces many possibilities. Now, it will be worth to mention that struts.xml will need to have this as well to be useful.



<struts>
  <interceptors>
    <interceptor name="dynamicValidator"
                    class="sample.MyValidatorInterceptor1"/>

    <interceptor-stack name="myInteceptorStack">
      <interceptor-ref name="exception"/>
      <interceptor-ref name="alias"/>
      <interceptor-ref name="params"/>
      <interceptor-ref name="servletConfig"/>
      <interceptor-ref name="prepare"/>
      <interceptor-ref name="i18n"/>
      <interceptor-ref name="chain"/>
      <interceptor-ref name="modelDriven"/>
      <interceptor-ref name="fileUpload"/>
      <interceptor-ref name="checkbox"/>
      <interceptor-ref name="staticParams"/>
      <interceptor-ref name="params"/>
      <interceptor-ref name="conversionError"/>
      <interceptor-ref name="dynamicValidator">
        <param name="excludeMethods">
          input,back,cancel
        </param>
      </interceptor-ref>
      <interceptor-ref name="workflow">
        <param name="excludeMethods">
          input,back,cancel
        </param>
      </interceptor-ref>
    </interceptor-stack>
  </interceptors>

  <default-interceptor-ref name="myInteceptorStack"/>
</struts>

Note that the configuration now uses almost all interceptors defined in the paramsPrepareParamsStack except the validator one. This is one architectural part of Struts 2 which I find it very compelling. You can grab any part of the interceptors, swapped with your custom ones and provide meaningful processing according to your needs.

Now, the validator code above deserves further explanation. Consider the case when an action forwards control (with the result type redirect-action). The forwarder action may not necessarily know whether the forwarded action is really validated or not, and hence the validation process will still be applied. In such case, one may need to allow some processing to decline validation on the subsequent action handling (such as placing a token on request/session/valueStack for starters).

The Domain Model and Struts 2.x

2008-09-26T12:15:00.001-04:00

A couple of months ago I had a new requirement where I had to display the look (ui) of only a few of my components in my Struts 2.x application. Specifically, I had to display some dates as date-time while others had to remain the same. I started to hold down for a minute and decided to think how best to tackle the problem. I hate to touch a lot of code for no reason and as many know, changing the domain model code is typically not a good idea.

Struts2 MVC and Converters

In the good old days of Struts 1.x, one would have to register a special Converter object and register it so that BeanUtils can use it when ActionForms are populate via the ActionServlet (wao, I can't believe I had to learn all that). This was a good way to provide good conversion across all your application, however this approach forces the Converter to be applied in all objects of the same type.

As an MVC implementation, the controller should be able to have a way to know what conversion process to use in each action mapping processing session. Struts 2.x provides a way to do this in a clean way with the use of the StrutsTypeConverter class. After creating your own converter class, you can register your converter globally (in a file that must be named xwork-conversion.properties). Alternatively, you can create a -conversion.properties file at the same package level where your model object resides and now you can have custom conversion per property. The latter approach is a powerful feature as it allows you to define a properties file with key,value pair listings. Each key represents the name of the java property of the model object and its value is the fully qualified converter class name. This approach for conversion is very appealing for the following reasons:

Does not mix Struts2 code with Domain Object model code (not even annotations), thus offering a non-intrusive approach to the rendering of the object.

It encourages a development environment where this file can be generated, overriden or even replaced at build time. This scenario is very appealing for companies that do customizations of a product thus encouraging a "configuration management" approach in the presentation tier.

It allows you to provide a different converter per property, leaving the model type unchanged.

I was able to successfully display each property as needed and progressively move each component that was required.

Powered by Struts 2.x

2008-09-24T12:45:00.010-04:00

After working with Struts 2.x for some months now, I feel more comfortable in commenting on some of the features that I feel have been helping me as well as some others that I feel needs some attention. In writing these, I hope that I may be able to learn some from those who may wish to attempt correcting me.

Overall Configuration

The basic file needed is one named "struts.xml". Properties (constants) can be overridden using a struts.properties files. This file takes priority and this is an interesting approach and this seems to mixed well with Maven environments (as well as Ant, of course). You can modularize your application including files of the same type (same DTD) as struts.xml. The one thing I don't understand is the use of DTD over XSD. Not exactly sure why they haven't adopted XSD as the latter are simply more powerful.

Rendering Engine

The fact that you don't need to JSP for your views has been a significant change for me. I know that you can avoid using JSPs using Struts 1.x but the amount of code (and configuration) could be very tedious. With Struts 2.x support for Velocity and Freemarker are already built-in. I've been using the latter for sometime now and I simply love it.

Now, if you consider the "hype" that OSGI is bringing to the JEE world, a templating engine technology (e.g. Velocity, Freemarker) over JSP technology is more appealing as this will allow OSGI environments to resolve proper templates based on the OSGI headers (within each jar). Struts 2.x comes with bundled with a set of predefined templates that the classloader picks from, thus encouraging this pattern (but not demanding it). I see this as a strategic architectural choice which ought to be observed when considering OSGI powered applications.

Servlet Technology and Controllers

Struts 2.x uses Servlet filters (instead of Servlets) as the driving force of the application. This can be good and bad for several reasons. I have found it to be good thus far. Filters can give you the feeling that "intercepting" a controller is simpler (filtering the request). Struts 2.x has default interceptors for different things such as those that parses the parameters and placed them into the value stack, double token submissions, etc. You can always implement your own.

You have a clear option of which interceptors to use and their ordering. This is a powerful feature that if misused can prove a big problem. I recently found a bug on the way I had configured our interceptors. You can do nesting of interceptors so I was repeating the same interceptor multiple times thus doubling my round-trips to the database. Implementing your own is very trivial.

Additionally, Struts 2.x advertise thread-safety POJOs as your actions (Struts 1.x should remember that this issue can make you rely heavily on request/session attributes). I have found that the nature of making this action objects thread-safe are by virtue of having a "request" scope. Since you have an option to use Spring for dependency injection, you configure/annotated your POJOs with scope "session" and block this behavior. I've found this a problem in some cases. I'm still investigating this issue, but does bring something to the table. You can effectively perform IoC in the way Action (controllers) are used as part of your MVC.

IDE Tooling - The good, the bad and the ugly!

As most fairly new frameworks tooling is what helps the adoption of a framework. Struts 2.x lacks this component very much as there are not that many IDEs with out-of-the-box support for Struts 2.x. As of the today, there are few who show some promise, none of which I would recommend investing (yet!). I am a fan of Eclipse, and I have to say that the WTP project works just fine with Struts 2.x and developing with it has been a breeze. Configuring struts 2.x within eclipse is somewhat trivial and I expect IDE plugins to simply help with XML editing.

I have spent a lot of time reading the struts-core source code and I simply like it. I think its a good practice for any developer trying to understand the framework and I'm sure you'll find it very readable, well commented with few problems (although I'm sure there are some). Overall, my experience with Struts 2.x has been very pleasant and I have good reasons to recommend it as a choice for development of new enterprise applications.

Introduction to Struts 2.x

2007-10-11T22:35:00.002-04:00

I finally had the chance to work on a project using Struts 2.x. As I wrote code my code from scratch, I had to admit that my background from Struts 1.x worked against me in some cases where in others it helped understand basic concepts. All in all, I was very pleased with my experience with Struts 2.x. Granted, documentation is still under progress, however I found the email list to be a great tool to be informed and to receive answers to my specific questions. Although I don’t think I can possibly write about every feature I used in Struts 2.x, I can certainly write an introduction for those who are either new to MVC or trying to move from Struts 1.x to Struts 2.x

Reasons to Migrate

First I need to emphasize that unless you strictly have a good reason (and budget) to change your current MVC architecture, then I would recommend to switch to it. The migration is not as trivial and depending on what kind of code in your presentation view (JSP, Velocity, Freemarker, JSTL, etc) your migration may or may not be that transparent. One thing is for sure, Struts 2.x migration is not meant to be a “drop-in” replacement, so expect several gotchas as you move along. Also, note that regardless of your background, Struts 2.x can also be an appropriate MVC choice for a new application (depending on your needs, of course). If your moving from Struts 1.x, know that both can coexist during your migration, so you don’t need to break your existing code, however the process can become very confusing and unless absolutely necessary would I recommend it.

No Struts 1.x is required to start, in my opinion, however decent understanding of MVC (as with most frameworks) is always a plus. You want to also understand EL expressions (and now UEL as well). Understanding of additional concepts such as JEE Filters, Dependency Injection, Servlet Specification are going to help to get you going really fast, however note that if you have done any JSP work before, you’ll learn that with the Value Stack (Struts 2.x), now you have to account for a new “scope”. It’s not hard to understand or use, however one must understand where the values are coming from.

Using Struts 2.x

At a minimum, you are going to need the following jar files within your lib directory. These come as part of the struts2 distribution:

struts-core-xxx.jar
xwork-xxx.jar
ognl-xxx.jar
freemarker-xxx.jar

Of course there are other libraries needed. These are dependencies to the struts 2 framework (e.g. Collections, BeanUtils, Digester, etc). Although these are not part of the Struts2 project, these are reusable components that are part of the Jakarta Commons project. If you are not familiar with it, I highly recommend spending time on them. All required jar files come as part of the distribution. Of course if you are using maven, you don’t need to worry about any of these (maven places all needed dependencies within the lib directory).

Now you need to setup the org.apache.struts2.dispatcher.FilterDispatcher filter in web.xml. This filter should go primarily mapped to all “/*” (web.xml filter mapping). Now to your struts.xml file. This file needs to be in your classpath. Even if you try to put it somewhere else using a context-param in web.xml, other things will break. To be on the safe side, just put it in your WEB-INF/classes directory. As for “struts.xml”, I’m going to let you read some more on it in the official documentation since it’s pretty self explanatory, however a good thing to know is that the concept of “package” inheritance is widely used (similar to the one used in the tiles framework). This hierarchy allows you to have pre-configured elements in your configuration (e.g. validation, interceptors, etc) that are ready for you to use (thus the convention over configuration). You can change, modify, reuse any file. A good practice to learn is to checkout the source code and see how files are read. Warning, the source code uses maven, so unless you are familiar with how maven uses resources, this may be a bit unusual. Looking at the source code has helped me tremendously in picking up Struts 2 fast.

If you come from a Struts 1.x background, you may want to be aware that type conversion is done for you automatically. So there is no need to play around with custom converters (registered in BeanUtils, or custom processing to process conversions), however this conversion may/may not affect the way your validation occurs. This means that errors detected in the conversion process are managed as “fieldErrors” which in turn can be displayed using the appropriate tag. This may/may not be the desired behavior, but it a much better approach to Struts 1.x where strong typing properties in Form objects didn’t work well with certain validator types.

I hope to write very soon a lot more about specifics features within Struts2 as I find them, specially about the migration process which I’m sure it would be a lot more interesting. In the mean time, checkout Struts 2 and start playing with it. According to the goals of the project, you are supposed to be able to write a web application a lot faster (which I tested to be true) as well as to make it coexist with a Struts 1 application (also tested to be true). Have fun!

Learning about AOP

2007-10-07T22:40:00.000-04:00

I was told that once I start writing code in AspectJ and learn in depth Aspect Oriented Programming (AOP), it will be difficult to look at Java source code again in the same way as before. And now, the more I get into it, the more I realize how important it is to have this knowledge as part of your skill set. Until now, I had heard a lot about AOP and, just as anyone else who has used the Spring Framework, I thought I knew all I would ever need from AOP. Then, I was presented with a challenge where Spring support was not enough so I was faced with the opportunity to learn AspectJ's language constructs to address my client's concerns. I was very impressed with the things I was able to accomplish with this extension to the language and in general I highly recommend everyone to take the time to learn it and use it often.

One of biggest goals and hopes of every Software Architect is to design and lead a software development effort that can scale well. This means that maintenance should be more than technically feasible, but rather simple enough within budget. Experience proves that despite every effort of preparing for every change, it is difficult to address every potential concern that will rise in the future. Specifically, when these concerns appears spread out through the code base. This separation of concerns is what is referred to as "cross cutting concerns". AOP provides an API that allows you to write code to address these "concerns" in a desirable manner.

Aspect Oriented Programming (AOP)

Cross cutting concerns are address by way of, what is referred to as, "Aspects". Just as much as an Object models an Entity, an Aspect models a "Cross Cutting Concern". Getting familiar with these concepts takes some time, however as you take the time to write your own Aspects, it will become very easy to follow.

Every Aspect contains an entry point, a Pointcut. This basically describes how is the crossing concern identified. For example, the concern may be "all Constructors calls (from a specified package) must passed through an Authentication process prior to instantiation". So, the Pointcut will be all "calls to the Constructor within the package in question". This Pointcut description, interestingly enough, is one of the reasons where Spring AOP couldn't help me (Spring can not manage objects that are created somewhere else - e.g. Hibernate's Proxy objects). These Pointcuts delegate processing to a handler called Advise which is where most of the logic occurs. An Advise reflects the concern that is trying to be addressed. Continuing with our previous example, the Advise will be "before calling the constructor call check authenticating roles else throw an exception". Additionally, an Aspect may have multiple Pointcuts and each Pointcut will have a minimum of one Advise.

AspectJ

In the Java Programming language, AspectJ provides the ability to use these concepts in terms of objects. In general, AspectJ is an extension to the language. Originally developed by Xerox-PARC, it is now maintained by the Eclipse Foundation. The following code in AspectJ reflects the sample we have discussed thus far (for an object class name Foo):

public aspect AuthenticatedConstructorAspect {
pointcut constructorCheck() : call(* *.Foo());

before() : constructorCheck() {
// Do some coding (e.g. throw an Exception, etc)
}
}

Conclusion
In general, aspect oriented programming provides a great strength to your development efforts if used appropriately. It can become a strong part of your development efforts if used properly and can scale well since it can be plugged in as a requirement is enforced.

References

Rethinking the Enterprise

2007-10-04T16:40:00.000-04:00

Some years ago, I took a "Data Structures" class in college where I felt I received more than what I had signed up for. During my lectures, my professor challenged us to think outside the box constantly. On one occasion, a midterm exam was promising to be hard for the whole class. I was particularly puzzled with a bonus question (worth a lot more than the usual). Although I felt prepared for the exam, I was somewhat troubled, even upset at the question. If I recall correctly, the question was something like:

(x-99)(x-98)(x-97)... (x-2)(x-1)

And we were asked to calculate the product when "X" was 15. This puzzled me for a second since my first reaction was "why do I need to solve this in a Data Structures exam?". To my despair, I made the decision that I would spend 1 minute in trying to solve this question, since these midterms were known for being extremely long and difficult to finish. A few days later, during our next lecture, one of my classmates took the courage to ask the reasoning behind these "absurd" question. Our professor kindly explained that such question was to help us understand a principle that we had to remember if we were to succeed as Engineers. Thinking outside the box is not as simple as you may think and often times it requires a great determination to just do simple things. Although the answer may be simple, too much knowledge can lead us to add complexity to a simple problem, thus our skills are poorly used. By the way, the answer to question above mentioned was zero (if your need a detail explanation, please send me an email).

Simple and Plain concepts
Similarly to the incident I had in college, I attended a seminar not that long ago where the speaker spoke about this same exact principle. The approach he took was probably more eloquent than what I would like to be, but I feel he made a good point. This had to do with Enterprise Applications development. If you have noticed, the first word "Enterprise" is a simple word, yet as soon as one adds the second (Applications), a developer can start associating different technology concepts (EJB, Spring, .NET, Ruby, PHP). Normally, one is biased about a familiar technology, yet no one has even discussed anything about requirements. I met once an Engineer who had already designed (or at least he thought he had) an Application using EJBs without understanding the problem domain and/or requirements. This made me think in how we, as Engineers, are using the knowledge we have to develop simple solutions and avoid adding complexity to a business problem. I really stress this point because there seems to be an untold fear to learn/use different technologies and we seem to prefer to add more complexity over using the appropriate approach to solve a problem.

Facing our Engineering Fear
So why should you use EJBs? Do you fully understand what are the benefits of using these? Is .NET perhaps a better approach to the company's goals? Would you recommend building an application in RoR (Ruby on Rails) over J2EE (or .NET)? If not, could you number such reasoning? What is our real bias about the technology we choose to use when solving a problem?. Interestingly enough, I've found Engineers using a set of technologies that are known well, not necessarily because they are the best, but because is convenient. Engineering staff must understand the tool set available to them when solving problems, and unless required, not "re-inventing the wheel".

From the management perspective, there are very few cases when a developer may start working off a clean repository. This means that there is an existing asset to be maintained and/or extend. Management is skeptical about investing in such a change. In fact, it will take a lot of convincing to help management realize what is the really added value to a product in a potential "re-architecture" phase. Although this is understandable in most cases, an Enterprise Application can certainly benefit from a fresh new code base when situations allow them. This however should not make us believe that such architecture is the only and true way of solving every Enterprise Business need. A simple example is the case when Hibernate may not be the solution to every persistence problem. There are valid cases when JDBC is a perfect example. Or in the case of .NET, is the MS Oracle Client better than the ODP (Oracle Data Provider) for connections to an Oracle database?

The Hope of the Enterprise
To have a broader view of different technologies can certainly help us see an Enterprise Application from different perspectives. Being willing to learn new technologies can only help us and the Enterprise, but ultimately is up to us to drive the effort. So, when thinking about the Enterprise, one must think about the problem domain, and not only the tools available within our domain knowledge, but also what other alternatives available to solve the problem effectively. As scientists, we have a responsibility not only to solve technical problems, but to also use the most effective methods to do so. So read on documentations, download and test many frameworks and prepare yourself for we are the true hope of the Enterprise.

Leveraging Persistence with Hibernate

2007-10-01T15:14:00.000-04:00

Most Applications today depend on some sort of persistence layer to maintain state. When developing applications using JEE, the Java Database Connectivity specification (JDBC) empowers developers to use a database as the persistence repository of choice. With the JDBC API, most development efforts become technically feasible as it provides standard CRUD operations to a relational database. Unfortunately, programming with this API can also become cumbersome and repetitive in most cases. The question that remains is "Can we do better?" - It turns out that the answer to this question is "of course!". In fact, there are many other things we could do that is "better", however, for purposes of this entry, I'd like to discuss role and concept of Relational Mappers (ORMs) in the enterprise, and more specifically, Hibernate.

Object Relational Mappers with Java

Although Java is an Object Oriented programming language, the JDBC API lacks the ability to relate to a relational model in a database in a complete object oriented way. This is where Object-Relational Mappers (ORMs) help. Generally speaking, ORMs help model a relational database in terms of Objects that represent a business phenomena. This mapping is maintained in some configuration file (e.g. XML file, annotation, etc). In addition to this kind of mapping, ORMs also provide additional features such as caching, query language support, RDBMS independence (more on this below) and what I like the most, tools to build and monitor this layer among others. Now, having said these, an ORM is not the answer to all solutions. There are times when straight JDBC programming may be more effective, however I've found easier to maintain code written using an ORM than without. Not to mention how elegant the code looks.

Learning Hibernate

Hibernate is an Open Source ORM framework, now part of the JBOSS family of products. As of the time of this writing, Hibernate 3 is the latest release with improved features and nice tools for automatic configuration file generation, code generation, code/table verification, reverse engineering, etc. The documentation is very clear and easy to follow and they now use JIRA to maintain all bug reports. One important thing about Hibernate that I consider strongly is its large number of support for other RDBMs. This means that as long as the code reference Hibernate's API for persistence, an application can be migrated to different databases. This also improves scalability and promotes loose coupling to database specific code. Starting Hibernate for the first time is very simple, but just as much as every other framework, it can become cumbersome if configuration is not designed properly. So, besides being open-source and "elegant", what are some of the reasons when I would suggest to use Hibernate?

Advantages of using Hibernate
Hibernate is a very mature ORM framework, widely used in Enterprise applications. This is not by accident but because it adds value to an application from different perspectives. Here are some of the reasons I would recommend Hibernate:

Object Orientation - Hibernate allows development using object oriented constructs when dealing with persistent objects. This means, you can take advantage (programmatically) of associations, polymorphism and inheritance. Depending on your current data model, there may not be a big difference in how a database is represented in terms of objects, thus using Hibernate is a great improvement in your code. I understand that with EJB3, this may not be a unique advantange to Hibernate, however for legacy applications (EJB2, JDBC), this is a clear option.
Transparent Persistence - Hibernate maintains all mappings between database tables and objects. This means that all interactions with the database can be done with objects instead of the JDBC API. This level of abstraction adds no more overhead than the average JDBC code. The ability to now write code to objects, without writing SQL code to read/write/delete to a database makes persistence transparent. This means that the persistence layer is now delegated (at least significantly) to Hibernate.
Support for polymorphic queries - JDBC supports native SQL when building queries. This can become difficult to maintain and cumbersome to extend. Hibernate's polymorphism support for object mappings allows developers to write queries using the Hibernate Query Language (HQL) using polymorphic objects which can improve the level of abstraction used for modeling data in your queries. Additionally, Hibernate's API promotes object orientation when dealing with queries. (See note below for disadvantages to consider about this feature)
Database independence - depending on your business model, an Enterprise Application may need to be deployed in different RDBMs. This is typically dependent upon a business requirement, or a client customization. For this scenario, Hibernate adds value to your application due to the level of abstraction added over the database. This reduced dependency means increased portability of your application. In constrast, nothing in JDBC promotes code to be database neutral and it's up to the developer/architect to ensure portability.
Optimized Performance - Hibernate has a powerful caching architecture that allows developers to write code with fewer trips to the database. This is done by virtue of the cached mapped objects as these are "hydrated" from the database and reused when others needed. This kind of caching is difficult to accomplish using straight JDBC.

As an Engineer, one must remember that Hibernate is a tool and not a solution for every problem. Once you used it once, it is very tempting to use it again in every scenario, however one must understand the disadvantages associated with every framework.

Disadvantages in using Hibernate
Depending on your needs, Hibernate may or may not be what you really need. This all depends on different factors (e.g. budget, deadlines, current assets, etc). One must consider all factors before deciding to use Hibernate (just as much as with any other framework).

Learning curve - Depending on your current staff, learning Hibernate may be difficult, specially if the application in question is heavily dependant in persistence using already another ORM solution, JDBC or even EJB. Mainly because Hibernate has a lot of publicity does not mean one has to spend budget on it. Although the documentation is very clean, there are many concepts to understand in Hibernate (e.g. dirty checking, caching, lazy-loading, get vs load, etc).
Mappings to the Database - The main assumption that all ORMs do is that every table can be modeled to an Object. This is, for the most part true, however you can certainly find cases when representing tables in objects is not necessarily simpler, specially if the database model is not normalized, or poorly designed. Additionally, some DBAs would prefer to use database specific constructs (e.g. triggers, stored procedures) to handle some business logic which may contradict with your intentions in decoupling business logic from persistence. In general, you should not assume that a database can always be represented in terms of objects without understanding all requirements. I recommend getting familiar with the object-relational impedance mismatch for further reference.
Performance Bottlenecks - Complex database model may prove to add performance bottlenecks to certain queries (specially if they are polymorphic in nature). Hibernate does an excellent job at building joins for you automatically, but is not able to improve the performance of those queries as a database would do (e.g. analyze the execution plan). This is the kind of optimization that is expected to be done manually. If an Application demands this type of queries in most cases, I would probably consider JDBC instead of Hibernate. It is true that you can also run SQL queries with Hibernate, but if most of the application is doing straight SQL, then we are not using the tool properly (thus defeating the purpose of the ORM).
Complex queries - Hibernate provides the "Hibernate Query Language" (HQL) which allows developers to write queries very similar to SQL with object orientation (polymorphism). Depending on the type of inheritance chosen to persist certain schemas, queries can grow in complexity, thus adding complexity to the nature of the query. One could write native SQL queries and make them more efficient than HQL (a DBA should be able to help you here). Once again, this all depends on the type of application that we are dealing with.

Conclusion

Hibernate is a very mature and powerful ORM that in most cases, adds value to your application. Depending on your requirements, Hibernate can reduce the complexity of code maintenance as related to persistence. When dealing with complex data models, one must carefully consider the advantages of using Hibernate (just as much as with any other framework).

A Review of the MVC pattern

2007-09-26T08:55:00.004-04:00

Tight coupling among software components is one of the common problems in large enterprise applications. This is due to the large amount of data and the way in which this data is represented to users of the application. In practice, it's very easy to fall into the problem of writing unorganized code that, although it delivers a product, it does not maintain any known convention or standard. This only contributes to the problem of extending application functionality (scalability) which is almost certain to happen. Many design patterns are used in the industry to solve different business problems. Among these, the Model-View-Controller (MVC) pattern is one that if often misquoted and misused. In using the Struts Framework for building web-based applications, it is crucial that every developer understand this pattern.

In the MVC patterns, a clear distinction is made between three different components. These are the Controller, the View and the Model. Each of this components help segregate and centralize certain functionality of our code away from each other (loose coupling), thus scalability and re-usability is feasible. The following figure provides a small representation of how this components are meant to interact:

Figure 1 - Diagram of the Model-View-Controller Pattern

In this pattern, the Model component is a representation of some business data. This is also known as "domain model" and is specific to a business. It can also serve as a representation of a "real-world" process that the application is identifying or hold the state of a business entity. The View component is a specific display of the model component in the user interface (UI). This is also known as the "presentation layer" of the application. Thus, if the model component is a BankAccount object, the view component may be an HTML page containing account balance and transactions, or a frame of UI widgets representing the account holder personal information. Note that for both of this examples, the model knows nothing about the view, however the view needs to know some about the model component in order to display it. This direction in dependency is an important concept in this paradigm which encourages loose coupling among components: Developers programming in the model component do not depend on the presentation layer.

Changes to the model component (information holding business data) are handled through the Controller of the application. This means that if the view component has a function (e.g a button, or a drop-down) that needs to be triggered in order to execute an update on the model component, the view communicates this event to the controller component who executes this change and updates the model component. This level of redirection ensures the controller to handle the proper action per view according to business needs. For example, a bank account number may need to be "read-only" to customers but to staff members, this may be an editable field. In this case, it is up to the controller to decide whether the action of updating the account number should trigger an update operation on the model component and is up to the view component to determine if this functionality is even displayed to the user.

In the context of the Struts Framework, the MVC pattern can be represented using the following diagram. Note that the three components of this pattern appear in the same order as in Figure 1:

Figure 2 - Struts implementation of the MVC pattern.

Struts is focused on web-based Enterprise Applications and is heavily based on Servlet Technology. At the core of the controller component is the ActionServlet object. In general, this servlet forwards control to Action objects (to perform CRUD operations on the model component) or to another view component. This ActionServlet knows how to associate view components with specific Action objects through one or more XML files loaded during the servlet initialization process - init() method. Thus changes to this XML file typically represent a reload of this ActionServlet. In this approach, developers are left to insert code in the Action objects of their choice in order to perform changes in the component. When objects need to be placed in the presentation layer, the controller also uses this Action objects to place this model in proper scope (page, request, session, etc).

Struts also provides different tag libraries to help in the rendering of the model components in the presentation layer (view), however, it is left to the developers to decide how to display the data by virtue of the MVC pattern. This means that JSP, velocity or any other rendering engine can be used as part of the presentation layer. As for the model this can be any representation of the domain model of the application such as an entity bean EJB, a Java Bean using Hibernate (Session in View) or Data transfer objects to partially represent a domain model object. Other components can also be plugged to controller component such as resource bundle configuration, menu capabilities, tiles, etc. This pluggable architecture mixed with other configurable features (e.g. validation) has made Struts a preferable option when choosing to use the MVC pattern as part of the architecture of a Java Enterprise Application.

Loose coupling between components is the key concept. Different frameworks are available in the open source community, among which some offer an MVC architecture for Java Enterprise applications, however keep in mind that, as quoted in Martin Fowler's "Patterns of Enterprise Application Architecture":

"The value of MVC lies in its two separation. Of these the separation of
presentation and model is one of the most important design principles in
software, and the only time you shouldn't follow it is in very simple
systems..." (page 332)

So, keep these in mind when using Struts. Additional features offered by the framework should not be confused with the objective for which Struts was designed. Overuse and/or additional design without careful planning can prove to reduce scalability thus reducing the value of the product in the long run.

Introduction to Struts 1.x

2007-09-15T08:53:00.000-04:00

Some years ago, I was asked to add a new feature to an existing struts-based application. The feature would include some form validation, form pre-population as well as some embedded logic depending on the authenticated user. Double submissions were also a big concern and had to be detected and avoided. These, among others, are many of the tasks where Struts can be extremely helpful. Sure, there are many things that experienced developers will find as shortcomings (just as any other tool has weaknesses), yet Struts continues to grow from these and is now a well-defined Java Framework for building Enterprise Applications using a Model-View-Controller (MVC) architecture.

One thing to remember is that Struts is not the only solution, is only one of the many. Specifically, it's one commercially popular in the Java programming language. There are other solutions available such as WebWork (now merged with Struts to make Struts2), Spring MVC, Swing, JSF (which is now the official MVC specification from Sun MicroSystems), Stripes, JFace, OpenBravo, etc. Alternatively, other programming languages (such as Ruby on Rails) have an MVC approach of their own. In general, it is the pattern (MVC), not the tool (Struts), that we must remember brings success to an Enterprise Application.

If you are a newbie, be aware that Struts is now branched in two different projects: Struts1 and Struts2. The first one aims to continue development on the original Struts Framework. Struts2 is the new approach for MVC development as developers from the Struts and WebWork2 (OpenSymphony) communities joined forces to provide a cleaner (and simpler) way of developing web-based applications. You may want to consider choosing one first (as suggested on their official site) if you have never used either version as both bring to the table fundamental differences. Unfortunately, as a newbie you are going to need to have some understanding of basic technologies. Although the Struts documentation suggests some of these, I would list the following as the key technologies to understand:

HTTP Request/Response Cycles
Properties Files and Resource Bundles
Servlets, Filters, and Web Containers (e.g. Tomcat, Resin, Weblogic, WebSphere)
Java Server Pages Technology (JSPs, Tags)
XML
Model-View-Controller Pattern

Reading about these shouldn't be difficult for the average developer. The challenge will come later when a developer uses Struts in a real case scenario. It is fundamentally important to remember that Struts is a tool and not the "only" tool to generate Enterprise Applications. Often times, I've found source code where developers have misused Struts by forcing their many features to address a business problem already solved by other technologies (e.g. JSP, Filters, etc). Start with small sample projects and work your way up. For the curious newbie, I've found the JAD decompiler (while developing using Eclipse) to be a great tool for development of Struts Application using your favorite IDE (so you can look at the needed source). This source code is available anyway, but with this tool you can view only what you need, when you need it. Tracing the ActionServlet Servlet object in the org.apache.struts.action package can prove to be a very insightful experience... Enjoy!

Before Struts, your would have to extract each parameter of a request using a "getParameter()" method of the ServletRequest object. Struts encapsulates this with their ActionForm object, thus learning the life cycle of this class is essential when dealing with incoming HTTP requests. Also, prior to Struts, you would also have to write certain logic to learn how to forward a request to another Servlet for further processing. Struts solves this with their ActionServlet and one or more XML configuration files that drive the application flow. Double submissions of HTML Forms were handled by some hack in between Servlet calls. Struts solves this problem by using a "token-per-request" approach and the methods isTokenValid(), resetToken() and saveToken(). In general, Struts provides an Object Oriented API which helps visualize these problems and many more as objects.

In my experience, learning about the Model-View-Controller pattern is the key to using Struts successfully. This understanding, coupled with adherence to good and useful programming practices (which I plan to address in a different blog entry) will help you appreciate Struts better. So read about this and other practices and use this framework to do what is meant to do: "...to create/help web applications utilize an MVC architecture" (Reference)