Internna - Geared towards Open Source

Step by step: Executable WAR files

2011-08-04T11:36:00.000-07:00

Have you ever executed Jenkins? One of the most valued features it packs is the embedded Winstone servlet container. It allows your favorite CI server to be launched without being deployed to a traditional server (say Tomcat) first. Unfortunately Winstone is not a viable choice for everybody, particulary if the app makes use of the latest servlet/JSP features. Fortunately there are other choices.

Jetty has always had a good reputation in this field. As of today Glassfish and Tomcat also offer solutions for this need. I'll focus on Jetty, basically because it's easy and it works. There are good articles around the net about the topic but no step by step tutorial so let's see all the tasks it takes one by one.

First of all, an executable WAR file is no different from an executable JAR file. That means that it needs an entry in the MANIFEST file that points to the class that will be launched. In this case, the main class has to start the server and deploy the very same WAR file.

The source of the class:

public final class Launcher {
   public static void main(String[] args) throws Exception {
      int port = Integer.parseInt(System.getProperty("port", "8080"));
      Server server = new Server(port);
      ProtectionDomain domain = Launcher.class.getProtectionDomain();
      URL location = domain.getCodeSource().getLocation();
      WebAppContext webapp = new WebAppContext();
      webapp.setContextPath("/");
      webapp.setWar(location.toExternalForm());
      server.setHandler(webapp);
      server.start();
      server.join();
   }
}

The above class was copypasted from here. All credit is due to the original author. It's a clever tweak over the official documentation to point to the WAR file location.

To compile, Maven needs to download the dependencies. Easy:

<dependency>
   <groupId>org.eclipse.jetty</groupId>
   <artifactId>jetty-server</artifactId>
   <version>7.3.0.v20110203</version>
   <scope>provided</scope>
</dependency>
<dependency>
   <groupId>org.eclipse.jetty</groupId>
   <artifactId>jetty-webapp</artifactId>
   <version>7.3.0.v20110203</version>
   <scope>provided</scope>
</dependency>

Notice the scope is set as provided. This will later be explained. For now the class compiles so the next step is to add the MANIFEST entry. This is usually done using the maven-jar-plugin so a WAR file will use the equivalent maven-war-plugin:

<plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-war-plugin</artifactId>
   <version>2.1-beta-1</version>
   <configuration>
      <archive>
         <manifest>
            <mainClass>Launcher</mainClass>
         </manifest>
      </archive>
   </configuration>
</plugin>

Right now the WAR file can be executed....but it will fail miserably. There are two problems, first the compiled class is located inside WEB-INF (as all classes in a WAR file) and second Jetty dependencies are not present in the classpath yet.

The next task is to move the Launcher class to the root of the WAR (classloading behaves the same as a JAR file). Maven can't do this easily so Ant to the rescue.

<plugin>
   <artifactId>maven-antrun-plugin</artifactId>
   <executions>
      <execution>
         <id>main-class-placement</id>
         <phase>prepare-package</phase>
         <configuration>
            <tasks>
               <move todir="${project.build.directory}/${project.artifactId}-${project.version}/">
                  <fileset dir="${project.build.directory}/classes/">
                     <include name="Launcher.class" />
                  </fileset>
               </move>
            </tasks>
         </configuration>
         <goals>
            <goal>run</goal>
         </goals>
      </execution>
   </executions>
</plugin>

The second task is to provide Jetty dependencies. Java does not support JARs-inside-JARs (or JARs-inside-WARs for the matter). The only option is to unzip the dependencies and again at the root of the WAR file (WEB-INF cannot be reached). Remember the scope of the Jetty dependencies from above! Another plugin will help with the task:

<plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-dependency-plugin</artifactId>
   <version>2.3
   <executions>
      <execution>
         <id>jetty-classpath</id>
         <phase>prepare-package</phase>
         <goals>
            <goal>unpack-dependencies</goal>
         </goals>
         <configuration>
            <includeGroupIds>org.eclipse.jetty,javax.servlet</includeGroupIds>
            <excludeArtifactIds>jsp-api,jstl</excludeArtifactIds>
            <outputDirectory>
               ${project.build.directory}/${project.artifactId}-${project.version}
            </outputDirectory>
         </configuration>
      </execution>
   </executions>
</plugin>

Right now the WAR can be executed using java -jar name_of_the_project.war. Unfortunately, the user would notice this on first access, it lacks JSP support throwing a 500 error. To add it another dependency has to be included. This dependency does not need to be unpacked, it's readed from WEB-INF/lib as any other library.

<dependency>
   <groupId>org.mortbay.jetty</groupId>
   <artifactId>jsp-2.1-glassfish</artifactId>
   <version>2.1.v20100127</version>
</dependency>

And that would be it! That would be it if the WAR doesn't need to be deployed to Tomcat any more. Yes, adding that last dependency breaks JSP support in the most used servlet container. Sad. That forces even more work to prepare everything. There's no good solution to this problem, if the JAR is downloaded and copied the WAR will not be deployable otherwise it won't have JSP support. The best workaround is to conditionally add the dependency if the desired outcome is a standalone, distributable, file (so the development process is not affected). In Maven this is achieved using a specific profile. What does it mean in the end? Two things, some refactoring in the POM file (so the specific tasks required by Jetty are relocated inside the profile) and starting the Maven process with the -P flag.

And finally we are there! If you need a complete working example I've comitted the changes to OSSMoney which was my original intent anyway (distributing something that end users could execute in their machines without any knowledge of the Java ecosystem).

OSSMoney Milestone III

2011-07-15T05:34:00.000-07:00

Today I'm going on vacation and hence I won't be working on the project for some time. I didn't want to leave without releasing something so I've packaged a WAR file and uploaded it to the repository (http://code.google.com/p/ossmoney/). I couldn't test it, even a little so I hope I didn't break anything important while adding some of the latest features. As always, in memory databases and no installer so it's meant for devs only.

Here's the list of changes since 0.2:

The user can now edit several important entities like accounts or transactions
Transactions can be deleted aswell
Partial investment support (buy, sell, interest, manual price updates) with imports from MS Money
The user can request a backup of the data in QIF format
Several new administration screens
Bug fixes galore

Known issues (I couldn't get them in time):

A Dojo bug (http://bugs.dojotoolkit.org/ticket/13401) renders TreeGrids unusable
Net worth only takes cash into account (investments are not added to the sum)

Wish list:

Some more reports (like spendings in a given category during some period)
Support other investment operations (though I personally don't use any more so...)
A better administration (better CRUD support for base entities like categories)

Anyway, OSSMoney 1.0 right now is nearly finished. I really hope for a September release. Enjoy!

OSSMoney Milestone II achieved

2011-06-17T02:59:00.000-07:00

I've been unable to progress as much as I would have liked with the project. Nonetheless, for the last couple of weeks I've been able to devote some time and improve things here and there. I've uploaded a new build to the project page. As always, it's not meant yet for end users but for fellow developers (in memory database and such things), just for evaluation, you know.

The list of changes for this version can be summarized in:

Credit card account support
QIF file import from MS Money (bank & CC accounts)
Dashboard ported to Dojox Charting
Bills & remainders

Things left for the (near) future:

Reporting
Investment accounts
Administration tasks (in particular allow edits)

And the always useful batch of screenshots:

The new dashboard

The account details page

Creating a new recurring bill

But try it for yourself and report issues or enhancement requests. Hope you enjoy it!

OSS money first developer build available

2011-03-06T01:20:00.000-08:00

So after a month of development I finally have something to show beyond this screenshots:

The current build only works in Firefox AFAIK (I know it doesn't work in Chrome for sure). That's one of the cons of working with a beta of Dojo. Anyway, download it at http://code.google.com/p/ossmoney/downloads/list and try it. It uses an in-memory database and it hasn't been thoroughly tested (and it isn't very error friendly!) so this is not meant for end users. It's just a build for fellow developers (may be someone likes it and decides to contribute to the project).

To use it just deploy to Tomcat (or whatever), access http://localhost:8080/ossmoney-dev.build.29 (probably) and login with jose/jose or register a new user (the username requires more then three letters!).

After this one, I won't probably release any more binaries (till the final one) unless there's some interest in the project out there. After all, I can build my own version and preparing a release takes time (even one like this).

Introducing OSS Money

2011-02-18T05:56:00.000-08:00

Do you like MS Money? I do. A lot. That's the main reason that saddened me when Microsoft decided to discontinue the product. There are several good free online alternatives but I don't like to trust my financial data to anybody but me and my bank. In the Open Source scene there's GNU Cash but...

During the last year I contributed very very little to the OSS scene (just some code to Gmaps4JSF actually) so I decided that I had an itch and may be I should take the opportunity to do something about it. So, without further delays, I've started a new project at Google Code, it's called OSS Money (tribute to the mentioned MS software), and it'll be an expense tracker and budget planner. Right now I've barely scratched the surface but I have something to share. Here's the desktop screen as of today (in Spanish with two currencies):

For those willing to help with the project, it's a multi-language Spring Roo application with a Dojo 1.6 frontend. Right now, I'm not going to provide binaries (very alpha status, feature wise) but checkout the code and let me know your impressions. Or open some issues if you have any ideas!

Test driving Spring Roo..for real

2011-02-02T10:48:00.000-08:00

I had the oportunity to evaluate Spring Roo some time ago but I didn't actually use it in a project till recently. Today, after hours and hours of heavy I wanted to share some thoughts about the tool.

First, it has some AWESOME features:

There's absolutely no way to create a project from scratch that packs a Spring context, Maven, a security solution, REST/MVC and persistence in less time. Everything is very well configured and just works, in a matter of seconds and four commands. Congrats here to the Roo team.

The @Configurable entities (ala Grails) are incredibly useful. Having an EntityManager injected in the model and predefined CRUD methods is invaluable.

I liked

The environment. Both, the command line tool and the STS plugin. IDE integration surprised me, it's well rounded.

So-so things I found:

As mentioned, Roo is fast when creating a new project. It comes at a price though as your commitment with the Spring stack is absolute. Of course, this may be a non-issue for many people as of today.
Roo values Convention over Configuration and in such spirit it makes a lot of assumptions..on your behalf. I've found some of them questionable. For example, in a tool so focused on persistence, why is the authentication provider configured in memory by default? Of course, it works out-of-the-box, but I'm pretty sure that 99.99% of the users will change that. Roo creates a login page for me, great but I was expecting a DB authenticator in there (and User and Role classes!)
Controller scaffolding...yeah. It works and it's fine. It's just that a real application may look like the generated pages...or not. If not, and that seems to be my case all the time, it's not worth the effort. For a rush...a good addition!

But there are things that are PLAIN WRONG:

Roo seems to take a reckless approach to programming. It's not what I would call an error friendly tool, not even by a far margin. Not that Roo fails by itself (seems quite robust in fact) but the user will undoubtedly do it. That's not actually an issue, everybody makes errors. The problem is how easily you can fix them. Any IDE basically provides an unlimited UNDO/REDO capability. Fixing something is a matter of pressing CRTL+Z in most cases.

Things are not that easy with Roo, obviously because it lacks the UNDO command, but in more subtle ways aswell. The generated code cannot be touched (it will be overwritten time and again) and pretty much everything is generated (90% of the code is hidden to the user). And even if it could it would be a daunting task unless you're an expert in AspectJ syntax.

Many many times, it's just better to delete the involved source files and restart the work. Do I have to mention how frustrating this can get? May be it's me, I'm so used to it that I don't really pay the due attention anymore but, lo and behold! check twice before clicking that Execute button with Roo

Will I give Roo the seal of approval then? I'm afraid I won't this time. Right now, it's a fantastic tool to create a project. And good for the advanced architect. But this is not a tool for neophits (a resounding no!) and still needs some work in key areas. But I won't ditch it. It's worked quite well for me! But before diving into Roo just check your knowledge with Spring and AOP in general. Otherwise, Roo will create you more headaches than it will solve.

Escaping Spring EL

2010-12-02T07:02:00.001-08:00

Months without blogging and finally today I've found a reason to write something! It's the first time Spring has failed me big time!!! And doing a trivial task to boot!!!

Let's recapitulate, I'm trying to inyect a simple String property in a bean. The value I have to inyect is: #{fwk:path('/')}. Simple, huh? Well, not so much it seems.

Can you spot the problem right there? I'll help you a little. Spring 3.0 includes an expression language. Fine...if it weren't for the fact that it uses #{} as the expression delimiter. Of course, that can cause a lot of trouble because:

It seems Spring lacks the ability to turn off the EL if you're not using it
It seems Spring lacks the ability to configure the pattern
It seems Spring lacks the ability to escape single quotes inside the expression
The documentation isn't stellar this time

In the end I was able to solve the problem. I'm showing you how, just inject this (it took me several approaches to find it so it's a little useful snippet I guess):

#{ '#{' }fwk:path('/')}

Great, isn't it? Elegant, clear, concise...wow! Now...c'mon!!! Am I missing something here?? Either I've lost my mojo (just this time) or SpringSource has some room for improvement! Please, prove me wrong.

Spring Roo..is it worthwhile?

2010-01-12T08:44:00.000-08:00

It's no secret that attaching a well recognized brand to the name of a product (software or not) is a wonderful recipe to get some public attention. In my opinion, Spring Source (see) abuses it. It's not alone though, just take a look at Google's portfolio. Nonetheless, beyond the name (which I like), Roo looks like a little gem. It's like extracting some of the best parts of AppFuse (project kickstart) and Grails (scaffolding) and joining them in an unobtrusive tool. Let's see how it performs.

Obviously, it goes without saying, Roo shines in new projects as it will help mostly in the first stages of the development. Well, that was like saying that Roo will be specially interesting in a project using both Java and the Spring framework. Whatever...

Let's begin creating a project from scratch then. After opening the command line tool (there's a plugin but I prefer to always use the command line at the beginning to ensure everything will build later on) the user just needs to type

project --topLevelPackage org.internna.test

And Roo will take care of creating the folder structure of a valid Maven web project. Include there the pom file and some sweeties like a fully preconfigured Spring environment and the logging system. Let me stress this, if Roo's only mission would be to help with project creation it couldn't do any better already. Just by doing the above, Roo is useful in any project using Spring. Of course, this includes a trade off, the defaults may not suit you but chances are that the changes you'll need to provide will be minimal (after all, they are, purportedly, best practices) and much less work than doing everything manually from scratch (try the logging setup command). There's something that worries me more though and something important. The current approach is monolithic. Where is the multi-module support?

At this point, I have to admit that I'm pretty glad with the decisions taken about third party products. Maven, JPA/Hibernate, the Spring suite, JSPs all fit my style and that's something I value. People from other environments may find this ecosystem exogenous.

We've seen it already but I will state it clearly here: Roo is a Code Generator. And I do it because I HATE code generators. I avoid them like a plague actually. When I hear the words code generation I flinch. And then? Well, Roo wraps to modes of code generation: passive (once and forever) and active (incremental). For now, I'll stick to the first one and let Roo generate and manage all those tedious configuration files (like, say, persistence.xml) while leaving more advance uses to the future..whenever I feel comfortable. You may not feel the same but beware that choosing the second model, while powerful, it also (tightly) binds the application to Roo.

One last thing that didn't really convince me was the way that Maven is handled. I'm not sure why I have to type perform test instead of the usual mvn test. Or why I must exit the tool to launch a mvn tomcat:run. Obviously there's room for improvement in this area. The integration between both should be seamless.

All in all, it gets the approval seal around here. There are some rough edges yet mainly in the Maven support. And, of course, all the active code generation area is something I need to evaluate very carefully. But it's a 1.0 version and I expect improvements. It's sad they dropped the multi-module support, that bit alone will heavily hamper the adoption for medium to large projects.

IWebMvc 2.0 GA release available

2009-12-22T23:11:00.000-08:00

I couldn't hold it anymore! Spring 3.0 is out, Hibernate 3.5 on the way, the Spring Roo team has posted several release candiates already and JEE6 is finally here (even with a reference implementation). I was risking becoming obsolete right fom the start! And there was still a more important reason, IWebMvc will apply to join the Dojo Foundation in January. I needed something complete to show to the board of members and I wanted to start fresh at this new home (and I'm adventuring here because I don't really have any clue if it will pass vote).

Nonetheless I had many tasks to complete. Several nasty bugs still existed in the final RC (many IE issues, the long-standing RememberMe bug, ...), there was no real documentation and the demo application wasn't really up to date (or working for that matter). In addition I wanted to include last minute features like XSS attack prevention, a revamped chart support based on Google Chart APIs (Dojo charting is more visually appealing but sooo slow)) or RSS feeds. Unfortunately, I had to prune things in the process and the JasperReports support got the axe (I wasn't happy with the end result and it wasn't really useful for anyone).

But everything or at least the great majority of things have been finished or resolved by now (sure, the documentation is still a WiP). But the time for a proper release has come. I've just uploaded the distribution package to the project page. Go, check it out.

Here's a brief list of what IWebMvc 2.0 finally provides:

A full Java stack (with both client and server side)

A Spring/JPA/Hibernate robust and reliable backend

Full AJAX connectivity using DWR

Dozens of attractive client widgets based on Dojo 1.4

A model driven approach to development

CRUD from the start without a line of code

A lean development experience in line with other modern frameworks

It's been a year of development but the result, in my humble opinion, shines. I'm proud of releasing this software project as is and do it with a clear OSS licence like the ASL2 is.

Nonetheless the development doesn't stop here and I'm already planning v3. See you there.

My TODO list for 2010

2009-12-12T03:00:00.001-08:00

It's that time of the year again! A lot of good wishes most of which won't ever see the light of day, of course :-) But no more introduction, here's my task list for next year:

Spring 3.0
IWebMvc2 is rapidly approaching a final release (I'm two bugs short). I'm already thinking in features for 3.0 and the new version of Spring tops the list. I'm specially interested in the new @REST/MVC support as I want to test an AJAX approach based on Jackson views.
JEE6
Continuing the trend IWebMvc3 will be fully JEE6 compliant. The interesting parts of the specification are the new dependency injection JSR, the new validation model, web fragments, the web profile and (why not?) asynchronous servlets.
Maven 3 / Spring Roo
What am I looking for actually? Scaffolding? No, not really. I'm more in the search for a project management tool that works at source level, integrates well with an IDE/third party tools (Hudson, Sonar) and saves me time applying all those things common to any web application like security, logging, testing, validation, you name it.
Open Source work
I'm not going to abandon IWebMvc/IWebJTracker development, of course. But in addition I want to extend my commitment with Gmaps4JSF (you like MapSicle?) I may even join Hazem in his new adventure
Google projects
Probably the source of most interesting news this year has been hands down, Google. I'm going to closely follow Guava, GAE, Closure, Chrome and may be, just may be, GWT.
HTML 5
I'm not sure if next year will complete the transition but obviously you can't miss this train.
OSGi
I want to test Glassfish v3 OSGi capacilities. And Spring products as well. A project that has always appealed to me has been classworlds...may this is the time?

So what is yours?

FishCAT testing for v3

2009-12-08T01:27:00.000-08:00

Last week the latest installation of the FishCAT program came to an end. FishCAT is the GlassFish Community Acceptance Testing program, that is, a community program run by Sun to QA GF (in this case v3) that gets participants from around the globe ().

I like to join it each time for several selfish reasons. After all, Netbeans + Glassfish is my preferred development platform and if I'm going to use it extensively I want to ensure that it suits my needs. In addition, neither IWebMvc/IWebJTracker nor GMaps4JSF were working in GFv3 back at the start of the program. That, of course, forced me to use Tomcat as my main development server. Fortunately Glassfish shares code with Tomcat so having something working in the later means good news to solve the problem in the former.

The process is really simple, when you find an issue you post a message in the mailing list and after a preliminary revision you're asked to post a bug report in the tracker. Just this initial check was enough to fix the Gmasp4JSF issue (a bug with the application code that traversed the folder structure below /, a subtle difference with Tomcat which wouldn't complain and just set the path to /) so it's a crucial step. There's an obvious commitment with the project and an internal dev is immediately assigned to the issue and you can see steady progress right form the start.

Here's a brief list of pros:

The people at Sun top the list without doubt. I haven't ever seem a team of such positive and passionate folks. Special thanks go to Judy Tang and Jan Luehe who were always helpful!

The importance given to the bugs. FishCAT is not a PR project. Sun really wants external devs to participate and puts resources to fix the issues reported. Kudos to the company here. They really understand how to run this kind of activity.

They helped me as much as I helped them. Yes, I reported several nasty bugs in the deployment and web container components but in the process I got advices and could fix several hidden issues of my applications as well. It was a clear win-win situation for all of us.

GFv3 will be the first EE 6 implementation available and that's a feat worth some testing.

Tens of developers from countries as different as Germany, China, South Africa, USA or Spain to mention some

GMaps4JSF and IWebMVc will fully work in the final release of GFv3!

I have one con though:

For God's sake, please upgrade the network infrastructure! And that twentieth century issue tracker as well! Some days just posting a bug was such an exasperating task..

All in all, a very positive interaction indeed. I hope to see some of you next year!

IWebJTracker progress update

2009-11-27T04:26:00.000-08:00

It seems to me that as of lately I just post about IWebJTracker/IWebMvc2 progress. I guess that I don't have time for more...a pity. Nevertheless here goes another update.

Next IWebJTracker milestone will be mainly based around integration. The project more or less handles issues already but it needs to communicate better.

The first step in this path is providing friendly URLs. IWebJTracker has them now (for example, /project/IWEBJTRACKER will load the dashboard and automatically open the project). A bookmarking option has been also added (though I have to improve it...I'm not happy with the result yet)

The second step is RSS, my preferred way to get updates on things I'm interested. I've added support to the framework and now every action should be pusblished to a feed.

And the last step would be, something that can't be missed in an issue tracker, email support. I've added the Javamail connector but I haven't yet decided the interception points. Right now, IWebJTracker only emails the user to confirm the registration process. It's a matter of adding more templates.

But the user is not the only target and continuing with the Java & Open Source focus, the tracker can now get updates from the remote APIs of Hudson:

And Sonar (data extracted from Nemo):

Of course some other areas have received attention as well. For example, the My Projects tab now includes a timeline chart:

And..not really coding related...I've designed a logo for the project! I do not accept critics about this ;-)

I hope you like the changes. As always, comments and help are welcome!

Yet another...issue tracker

2009-11-02T00:00:00.000-08:00

I started the development of IWebJTracker because I needed to demonstrate the public and myself that IWebMvc was a good enough framework that simplified development of 2.0 applications. Application Lifecycle management has always been an area of interest for me so an issue tracker seemed like a good candidate to code.

The truth is that in the midtime some things have happened that affect the project (for example, Jira has a new version and price scheme and JetBrains has released a new product in this space, YouTrack). So the market situation is this:

There are very good commercial solutions (Jira, FogBuzz, YouTrack)
There are very good Open Source solutions (Trac, Bugzilla)

But, IMHO all that doesn't change anything. I still miss an open source bug tracking system written in Java and that deploys to Tomcat out-of-the-box. So that's why IWebJTracker may still make some sense to someone down the road. Even more so if Subversion and Maven are also their target.

But, make no mistake, all the above alternatives are better than IWebJTracker. Not only because they're more mature (remember this is a first milestone what I'm releasing today) but because they have a team of people (probably way better coders than I am) helping with the development. Remember that this is a one-man project coded during free hours. No more, no less.

If you still want to try it out, bear with:

The fact that this is not production ready
It has obvious flaws (no notification system yet, for example)

Last, I would like to publicly thank you the rest of the people that make possible IWebMvc first and IWebJTracker later: the DWR team, the dojo team, SpringSource, Scott Schiller, Alex Gorbatchev or Jordi Sellés among others.

The download is available at the project page. And more or less resembles like this:

As always feedback, opinion or help is appreciated. Look for me on the mailing list.

Jira 4 raises the bar...

2009-10-07T05:27:00.000-07:00

In case you've missed it, the announcement. Impressive, isn't it? Obviously I can't compete! A team of engineers and thirteen months of developement..starting with Jira 3. Admittedly, I'm a lonely developer, I've been working for three months during my free time and I started from scratch! Nonetheless, I won't despair...at least IWebJTracker will be fully Open Source and it doesn't look that bad actually (given that I'm not a designer, of course). Take a look at the main screen for an issue (as of now):

And somehow I've managed to keep things under control (which is always good if other developers decide to help):

I'm really looking forward to releasing a first milestone and see the acceptance it gets from the community!

The problem of Open Source

2009-09-22T09:50:00.000-07:00

I've just had a meeting. The topic of today was finding a way to replace a software tool in use in some random area of a client. It's a testing tool but they have tweaked it to become a robot, like say AutoIt. Not that I'm against of new uses for software but, really, using a testing application to create robots to manage windows created by your own code instead of using a batch process is a little bit over the top. But I digress as the problem, of course, is other.

The problem is money. Licenses in fact. The issue is they're paying some royalties to another company (one that develops and sells software) and they're uncomfortable with the situation. Nobody says it like that and so the official excuse is the programming language of the scripts, VBA. But nonetheless, it's obvious to everybody.

And so they've asked me if I knew of any Open Source library written in Java, free (as in beer) with a good community (support is crucial remember?) that could handle their use case. Right there I stopped paying attention. I have some wishes myself.

But, at least, I got something positive out of it. I got to think about why and/or how have we reached this situation? The outlook is indeed grim. Somehow nobody feels like paying for software anymore. Everybody expects to find some OSS project out there that resolves all kind of problems but, of course, just a minority of people (let alone enterprises!) consider donating code or contributing to any project. And worst, probably us (open source developers) have helped to create this kind of environment. Right now, Open Source and gratis are synonyms in the mind of many people. What was that about birds and beers? Heck, nobody really cares.

Even worse is the disgrace that plagues the OSS world: whining users. Because too soon free is not enough and people demand more and more and more. Bandwith, documentation, examples, a forum, mailing lists, developers to answer promptly their question, enhancements, side projects...you name it. Sorry, I forgot to mention, free again.

So our work and time is now expected to be altruist...and then cost us something in the process. But it never works the same the other way around. Sadly, it's sometimes becoming a burden. Too hefty.

A rhetorical question, when will people awake and realize this is unsustainable? I've notice a trend, each year less and less people choose Computer Science as their studies. Can't help but think that they are not that wrong.

They say generics are stupid...

2009-09-10T01:07:00.000-07:00

Who am I to blame? This how my class declaration ended up being:

public abstract class AbstractProjectManager
   <C extends ConnectionDetails, M extends Module<P, M> & DomainEntity,
   P extends Project<C, M>> implements ProjectManager<C, P> {
...
}

With other niceties such as:

public interface Module<P extends Project<?, C>, C extends Module> {
...
}

Now, I keep looking at them and thinking "if I have to do this there's something terribly wrong going with this design!" :-)

On the other hand no one seems to complain about the overall quality of the code...

So the development of IWebJtracker continues at a good pace

New Gmaps4JSF plug-in architecture

2009-09-05T01:46:00.000-07:00

Chances are that if you have ever needed to add some kind of geolocation to a "enterprise" application you have met GMaps4JSF. For those who haven't the name says it all really but, nonetheless, I will translate for the lazy, Google Maps for JSF, that is. There are other alternatives, and good ones, like say Richfaces but AFAIK this is the only one that works wirh JSF 1.1, 1.2 and 2.0, with or without AJAX, with or without Facelets and so on. Basically it works everywhere.

The library is pretty complete as it already supports the map component and several children like markers, information windows, event listeners, street views et al. But it didn't span beyond what Google offers. Till now I should say. The thing is a client asked (some time ago) to provide some map functionality that unfortunately wasn't covered by Gmaps4JSF. I tried a pure Javascript approach first but, obviously, the results were not elegant in an otherwise pure server side application. Then I tried patching the library. In the end I did the job but this solution had also many drawbacks, the main one being that future releases would be incompatible with the changes and would leave the client stuck with an old version and without access to bug fixes. This was unacceptable. So I asked Hazem Saleh, the author, about a third way, creating a plugin system that could allow me and others to create new functionality without touching the core. We quickly agreed of course :-)

Hands on with the task I devised a possible alternative. As Gmaps4JSF is Maven based it needed to be a new module. That was pretty clear from the start. I then tought about diving it even further and force the creation of new subprojects inside this module. Two problems remained, the first being the distribution (because I didn't want to require a new JAR download for each new plugin) and the second the integration with the core (because it should be seamless for the user).

The former issue was solved by using the Shade plugin. I tried the Assembly plugin before but felt short soon. Both Maven plugins allow the developer to group project artifacts and apply some rules in the process. The sahed plugin fitted better because it allow us to combine all JARs in a single one AND merge XML and text files to obtain a unique tag library as the result.

The later was solved by designing a very simple (we want other people to contribute!) plugin architecture in the core. Just one interface (three methods) is enough to determine how a plugin interacts with the rest of the environment. So to build a new plugin you just need to follow these steps:

Get the idea
My first two plugins were ported from the gmaps-utility-library project (drag zoom and tabbed max content). There are many other.
Create a Maven module
Inside the Gmaps4JSF use the maven archetype to create a new module under the plugins folder. Add it to the parent POM if so you desire.
Declare the attributes of your component
Just copy&paste one the available components and edit the attributes you need (for example, latitude and longitude).
Implement the Plugin interface
You have examples available so it should be pretty straightforward. You have access to the parent component (where your component is nested) and the map (both in JSF and Javascript).
Register the plugin
Just add one line (for each plugin) with the name of the implementation class to a plugins.txt file in your META-INF directory.
Create an example
Nothing sells an idea better. It's just a simple JSP page.

And that's all really. If you decide to contribute an addition to the project drop a line in the mailing list. There are many interesting extensions to the map API so now you have the opportunity to colaborate without the fear of having to understand the entrails of JSF or the code of Gmaps4JSF. And for the rest, enjoy the current work!

IWebMvc2 Final Release Candidate available

2009-08-26T01:33:00.000-07:00

So, I've finally sit down to fix all the issues in IE and added some features required by IWebJTracker (like built-in grid filters and order by). I've uploaded a version with all the patches. Quite improved IMHO. And faster but beware that miracles in IE are beyond my capabilities. As a side effect it also works in Opera 10 Beta 3 in my tests and that's good as well.

Not everything are good news though as I've introduced a (very visible) nasty bug that happens when the Locator tag file is compiled. It just happens once and it's resolved by hitting reload on the browser but the first impression (a Tomcat error page) is horrid, I know. Sigh..

From now on I'll try to devote more time to the issue tracker and less to the framework. Let's see how it turns out.

Enjoy!

IWebJTracker...a teaser

2009-08-18T12:04:00.000-07:00

Just some screenshots so you get a taste of the current state of IWebJTracker:

IWebJTracker is/will be the first application built using IWebMvc2. I hope it will become a full ALM solution but at least it will be a Java oriented issue (bug) tracker. Open source, of course :-)

Say it with me...GE-NE-RICS

2009-07-25T09:52:00.000-07:00

Sorry, I'm in a bad mood today. It must be an uphill battle I guess. I've seen people confused with generics (I'm talking about Java here). They seem to get the concept and can use generic collections pretty well. Once teached they happily write:

Set<Something> somethings = new HashSet<Something>();

And for some unforeseeable reason they're happy with themselfs and proud of using generics. Some of them even attempt to understand advanced concepts like erasure (a concept that shouldn't even exist by the way). And, in fact, they do. Now, that's the end of the story. A dead end indeed.

For the great majority generics are something, revolving collections (and comparators..or was that TOO advanced?), made by Sun so everybody can use them later in their applications. Nobody seems to go one step beyond and try to develop generic classes of their own. Go figure!

So say we are designing a client application that needs to connect to several types of servers. A downright mediocre architect would write:

public interface Server {
   Object openConnection(Object connectionDetails);
}

He will argue that the specific types are unknown at the moment. Utter crap, of course. While an old school, barely capable, one would instead put something like:

public interface Server {
   Connection openConnection(ConnectionDetails connectionDetails);
}

Better no doubt. But it suffers the same issue, namely downcasts. Downcasts are obviously not elegant but they also pinpoint problems and bad practices. Avoid like the plague.

Generics to the rescue. Yes, you can do better! Believe me! That's what generics are really for. Not for collections but for you! For your designs! Let's refactor that interface of us a little. What would we need? Well, we know that a connection to the server is needed and that the server implementation and hence its connection are only known by the subclass in particular. So a FTP client has to return a different connection object that a Subversion client. Fine. Starting were our old good architect left the code we could try to modify it a bit. For example:

public interface Server<T extens Connection> {
   T openConnection(ConnectionDetails connectionDetails);
}

I know what your going to say...does that even compile? But looking at it more closely the changes are really minimum. We are just declaring a generic server that has one unknown parameter. But not completely unknown , at least we know it will be some kind of Connection object. But didn't we have that already covered with the old example? Yes..and now. Let's see an implementation. First we are going to use an abstract base class with some minor checkings:

public abstract class AbstractServer<T extends Connection> implements Server<T> {

   protected abstract T doOpenConnection(ConnectionDetails connectionDetails);

   public final T openConnection(ConnectionDetails connectionDetails) {
      ..do some checks...
      return doOpenConnection(connectionDetails);
   }

}

The only interesting bit of the above code is the way we carry the generic parameter down the hierarchy. Till when? Until the final Server implementation:

public final class SubversionServer extends AbstractServer<SubversionConnection> {

   public SubversionConnection doOpenConnection(ConnectionDetails connDetails) {
      ...
   }

}

See the difference now? The openConnection returns a specific class so the compiler checks the types for us! No more downcasts in the process! No class cast exceptions at runtime. And finally something to be proud of to show to your colleagues ;-)

PS.- In case you're wondering where that code actually comes from I'm happy to announce that I've started a new Open Source project at Google Code: IWebJTracker. It's in its infancy right now but with time it will become an issue (project?) tracker built completely in Java. Think of Trac or Project Tracker. Why I'm doing it? For two reasons: first so IWebMvc has a poster child application, second because there are no good OSS Java issue trackers. And by good here I mean with good Maven integration..Sonar...Hudson...see where I plan to go?

PSS.- Any help is gladly welcome :-)

IWebMvc2 Release Candidate 10 available

2009-07-19T02:22:00.001-07:00

For the last month or so I've been able to devote some time to IWebMvc2 and now it pays dividends. I've just uploaded a new Release Candidate and I'm well on track for a final release at the beginning of September.

This new version has several interesting upgrades.

Obviously the most notorious are the two new widgets: Multifile upload and Gallery. The former allows the user to upload a number of related documents and group them in the server as one entity. Documents can be added or removed as needed. It's been built from scratch as I wasn't happy with the matching widget in version one. Visually:

Gallery is a direct consequence. It will show all the images from a MultiDocument in a slideshow manner. It's a direct port of the same widget in IWebMvc or a ThumbnailPicker from Dojo.

But the improvements do not end here. I've invested a lot of time to increase performance. The use of Hibernate batch has, at least, halved the boot time (DB populate has gone from over a minute to less than a few seconds) and offers a better response overall. The client has benefit from the new crop of browsers greatly and the demo application runs smoothly on FF 3.5 and Chrome 2 (IE continues to be my bane).

Other minor issues include:

This release is based on Maven2 instead of Ant+Ivy
Dojo 1.3.2, SoundManager2 upgrade et al
Sonar quality assurance (including core refactorings and new unit tests)
And add the usual bag of bug fixes..

Of course, this is the first publicized version in a while so you may have missed...

The link widget:

Or the poll widget...

Or the many other...just check and enjoy!

Quality assurance with Sonar

2009-07-10T02:56:00.000-07:00

It's incredible how unknown a tool like Sonar is yet. I guess Gradle suffers the same destiny. After all, they're both similar in their intent, improve the quality of your software. It seems lots of people know about unit testing (not so many about code coverage), less know about tools like Checkstyle or FindBugs (static analysis of code) and just a minority are aware of other esoteric metrics like cyclomatic complexity. And even the few that use all of them do not extract all the value that a dashboard provides. That's what Sonar handles, it will take your project and stress it showing the results in a visually appealing site. With no extra work from you, the only requirement is to use Ant or, preferably, Maven.

But seeing is believing so I'll try to convince you showing the whole process and what kind of enhancements you'll be getting. As the demo project I've chosen IWebMvc2. I've nearly finished the development by now so it's a perfect timing to improve quality. In addition it's a complex web application made of three different sub-projects so something must arise. IMHO the quality of the code is pretty good, in theory I just want proofs...did I just say humble? ;-).

The first task is downloading the project and installing it. It's trivial believe me (well as long as you know how to unpack an archive...). To run Sonar just go to the bin folder, select your OS and execute the provided script. Trivial again. Sonar show be accessible (although empty) at http://localhost:9000 by now. Go there and login with admin/admin. Select configuration and under Quality Profiles click on Sonar way with Findbugs: set as default.

Next step is to build our project and include the Sonar phase. This is done typing:

mvn clean compile sonar:sonar

Pretty easy, wasn't it? If the project was built successfully the console was updated and shows something like:

A quick glance reveals a row per project analyzed indicating the number of rules violated and the coverage of the unit tests. There's a little bug with the latest JDK and Cobertura that reports 0% coverage always. As a workaround use JDK6_Update13 for example. The build time reflects how long ago was this information retrieved (not how long took the build itself, tricky). One click on the project shows the dashboard (this is a trimmed version):

Here's the bread and butter! All kind of metrics! From the whole project. The graphic displays the number of modules (JARs) and the relative size of each one. It's used to drill down and get module specific statistics. In fact, every link allows to navigate to new pages with deeper details.

Our task is to improve the quality of the project (bit by bit) so we can navigate to the Violations section and get a detailed report of the problems:

The rules are divided in several areas, some are require while others are optional. Selecting one rule gives the complete list of locations where the code fails to comply. Selecting one of those locations highlights the code:

In the above example Sonar has detected a private method that is never called. For performance and maintainability it should be removed altogether. Now, this is not true at all because I KNOW this method is called using reflection. So I should just ignore this error (caution! static analysis tools are not perfect!). Otherwise I could simply open an IDE and correct the mistake.

Of course Sonar remembers previous scenarios and can track the project life cycle (time machine they call it). Ideally you should be tying Sonar with a Continuous Integration server (out-of-the-box includes a Hudson plug-in).

I'm not gonna lie, quality requires effort. Even if you're an outstanding programmer. Sonar will just help (a lot actually) by providing visual and reporting tools but expect a slow (sometime tedious) climb to the top. Fortunately, in the end, it pays dividends.

Finally...Maven

2009-07-07T10:13:00.000-07:00

I've always been a happy Ant user. Even more so since Ivy has been available. Obviously that puts me in one side of the fence and I've been a very proactive supporter of that kind of project configuration. I must admit that included some rants about Maven here and there. In my biased opinion Maven lacked the flexibility that Ant provided and it was all about dependency management which was handled fine by Ivy. Probably my lack of confidence (knowledge) with the tool had some influence there too.

Four things made me reconsider my position: Hudson, Sonar, Netbeans 6.7 and the amount of time I was spending writing scripts. At work I had to install a CI server a couple of weeks ago and I was not using CruiseControl if at all possible (bad bad memories, I guess). That left Hudson as the best option (well, for me). I spent some time through the documentation and quickly realized that Maven was quite more straightforward than Ant this time. I needed a quality tool as well and Sonar has always been on my radar. Sonar works (again) out-of-the-box with Maven and requires some extra configuration with Ant. Being the lazy developer that I am I decided to test Maven with one project and see the results.

My first impression was pretty favorable. Migrating a simple Java project was a breeze and setting the job in Hudson trivial. I had the statistics online in less than half an hour. Finally I was understanding what was so good with Maven. It was not transitive dependency management, it was Convention over Configuration with the added benefit that other people where writing very interesting plugins for me. With absolutely no work on my side I had an automated build, quality control (testing plus quality assurance) and Jetty running. By now, I was in love with Maven. In more detail:

Zero configuration
So much time lost with Ant refurbishing the same scripts time and again...

Dependency management
I found Maven quite easier to handle than Ivy. I really really missed the master configuration of Ivy though (it saves time when you don't want transitivity for any reason).

IDE support
Today all major IDEs include seamless integration with Maven2. Latest Netbeans release, in particular, works wonders (the reactor plugin is awesome). Ivy support is scarce by contrast.

Redistribution
I've had to invest quite some work, many times, to offer Ant+Ivy scripts along with different project files (Eclipse, Netbeans, IDEA) to appease all kind of users. Not any longer. POMs are treated as first class citizens everywhere now. With the added benefit that I'll be able to upload the builds to the central repository.

Future
I'm under the impression that things like OSGi will be pretty much simpler with this approach.

All in all, I'm leaving Ant. For good. I can't say anything but praises about Ant, it's been years of comradery. And yes, it's a somewhat sad situation but I can't help seeing it obsolete, overridden..

Web framework comparison - Prototyping

2009-05-24T13:05:00.000-07:00

Some may say I have a biased opinion on the topic at hand. True. I hereby declare that I have a clear preference for dojo+DWR+Spring MVC. But I happen to have a cruel client as well and when they asked me to prepare a comparison between several modern web frameworks they purposely left Spring behind. The aim here was to build quick prototypes of enterprise applications to test new ideas proposed by the business people. Obviously they current architecture is a little bit outdated and not suitable for the task.

They gave me a blank sheet to start although they did mention Ruby On Rails and GWT. The first one was in the origin of everything, a new board member had recently joined the company and in his former position they were using RoR for the task. The second was probably due to the fact that several projects had spawned recently with Flex+BlazeDS as the client side technology but noone was really sure if it was the right path.

Given this requirements I selected Seam, AribaWeb and Grails as well.

Obviously this is not an apples-to-apples comparison. Ariba and Seam are both full Java stacks. RoR and Grails are server side backends very oriented to relational database repositories. While GWT is a RIA tool to layout views in pure Java with some communication middleware, like say, dojo+DWR or, as already mentioned, Flex+BlazeDS could be.

But it makes for an interesting analysis anyway.

The criteria to elect the champion contain the following points:

Learning curve
We are talking about three hundred programmers that haven't ever coded in anything but JSF 1.1. Let's make the jump feasible.

Prototyping
How suited for the task is the project? A scripting language seems better to throw something quickly even though it's not maintainable later. On the other hand, a good IDE with good component integration, a drag'n drop visual editor and a preview screen makes stupidly easy to churn pages.

Productivity
How good are the APIs and third party libraries? How much code and configuration is needed to kick start a project? How easily is to connect client and server development?

CRUD
Enterprise applications today always need to interact with a persistent backend.

Killer features
Selling points for the upper management. What does this framework better? Where does it really shine? What unique characteristics does it put on the table?

Weakness
And what about these...?

Maturity, popularity
Is it a safe choice? Will it be around in the not so distant future?

There were others but neither as interesting (licensing, standardization) nor useful to you (migration, code reusability) so these make a good list. I'm not posting the tabular data for two reasons, first it depends heavily on the weights you assign to each column and second it's subjective and I don't want to start a flame war.

But here are my personal conclussions.

In the first round both RoR and GWT fell off the roaster but for very different reasons. In the case of RoR it scored very well in every technical category but, even if I could use it, the truth is a company like this is pretty commited to Java/JEE and such a rupture means time and money. And they're both scarce this days. Maybe for highly innovative teams in core areas but not as a general purpose tool. GWT didn't fare equally well. First for a RIA builder it lacks a decent widget library. Then I like DWR remoting better(biased again?). And finally it shuns standards like a plague. With this conditioning you're better served by Flex. Any day.

The second round saw, and this was a suprise, Grails fail. Grails happens to have the same punch as Rails and then some more. A great ORM that simplifies greatly CRUD operations (nothing really can beat code generation and a book.save()), scripting capabilities, joint compilation, Spring et al. Unfortunately it lacks a matching client plug-in. Flex is not there yet and dojo is too much work for a solution specifically looking for speed of development. The syntax is concise but many times awkward and in general Groovy/Grails still lack maturity (IDE support is minimum, plug-ins quality varies greatly, too many bugs yet). I guess you get used to Java's 24 months release cycle with bullet proof quality. Groovy is different in this aspect. I have good feelings about it (more with SpringSource behind the projects) but it takes time.

The two final candidates provide the full stack, client and server. Seam is IMHO more powerful and a safer choice in general. The people behind Seam are the same that participate in several JSRs and other high profile projects like Hibernate. JBOSS has always been a very active OSS player and the quality of the components (EJB3, Richfaces, JBOSS Tools, Hibernate) is out of question. There's very little bad I can say about Ariba. It's new (very new) in the OSS space and the look&feel is not spectacular (subjective I know). That last bit was important because you want the wow factor when showing a innovative project to the final user. I have to admit that JSF weighed in favor of Seam here but in the end it was a worthy winner for us this time. Kudos to them!

Book review - Spring Web Flow Web Development

2009-05-12T03:05:00.000-07:00

This article was promoted to JavaLobby as well

Right now there are two trends to develop web applications, either you choose the RIA model or a conversational approach. In the former, say Flex with Cairgorm, both the model and the state is handled by the client. In the later, the server manages the scope sending a view to the browser which acts as a renderer. Of course, interactivity has improved over the years and nowadays partial requests are a must to improve user experience. Spring WebFlow is the SpringSource approach to a server side (work/page) flow management for web applications and Spring Web Flow Web Development, the book, (I could think of better names!) tries to explain how to leverage it.

The task is not minor because, let's face it, Java is a very complex platform and to start with WebFlow you should have a good understanding of JEE (at least JSF and the Servlet APIs), Spring and MVC in general. AJAX is welcome as well. The book, of course, can't help you there (you'd need a whole collection for that). This is not for novices! Fortunately a lot of people have learned JEE and Spring through the years and it's a matter of learning Webflow step by step but in depth.

Now, here the book shines. I like the formating, very clear and clean, and the language, simple and direct. I would have changed the chapter structure a little though. I missed individual chapters for persistence (Security has one) and Spring MVC (Faces has one) and I would have reordered some things here and there (configuration is scattered) but that's subjective and overall the steps make sense. The concepts (flow, action, state, transition, continuation) are well defined and you get a grasp pretty soon but some times the book is too comprehensive like when enumerating the methods and fields of the available variables (messageContext, flowExecutionContext et al). This makes for a hard reading but it will be invaluable as a reference book to some. I prefer IDEs for that task though. In the same sense I missed more diagrams and graphs (I'm not referring to UML class diagrams here). In a book about flows it should be pretty easy to plot concepts using some circles here and there. In my mind, circles are not less valuable than XML snippets (the book has tons of these don't worry) and the reader will gladly accept some pictures to clarify concepts (and thank you for them). Nothing too fancy, this one (extracted from the book) is more than enough:

In summary, the book is extensive and a great tool to learn first, and as a reference guide later, to Spring Webflow. It's dense and it explains lots of concepts in depth. Be warned that to extract all value this book requires previous knowledge of complex notions, among them: Spring, JSF, AJAX, persistence/ORM, Security, unit testing and probably more. The authors have made the effort to introduce all these libraries/skills when they're first used but that just lessens the burden (a bit). All in all, an easy candidate to recommend to those who need to extract all the power that Webflow 2 has to offer or teams that are about to start a new project and need an initial push with the technology.