Raible Designs

RE: Five things I hate about AppFuse

Karsten Voges has written a nice critique of AppFuse titled Five things I hate about AppFuse. I started a new JSF+Hibernate project with AppFuse yesterday, so I definitely feel some of his pain. Let's examine his points one-by-one:

1. It's nice to choose between the usage of JSP 2.0 or before, but making the changes (to all jsps and the web.xml) every time I build my app sucks.

I absolutely agree. I spent a good hour modifying build.xml, web.xml, etc. to switch my app from JSP 1.2 to JSP 2.0 yesterday. You can modify your build.xml to permanently switch to JSP 2.0, but it doesn't get everything. I'll create a separate script for 1.9.3 and the upcoming 1.9.4 to make this cleaner.

2. Seperating the classes in web, services and dao is good, but I hate the building of jar-Files for the different layers. Just take the classes under dao and service and copy them into the war or move them over to the webapps folder as it is done with the web classes!

Yeah, I've proposed doing this a couple of times on the user mailing list. It always gets shot down by existing users. I'm sure it'd be possible to write a script to do this, but it'd be no fun to write.

3. Eclipse crashed with OutOfMemory errors. Always when trying to open the build file. The build file is really, really long, with lots of stuff in there. IMO 50% of it could be deleted.

Hmmm, I rarely have OOM errors with Eclipse, but I also used Bruce's tip for increasing Eclipse's available memory. If you're using Windows, here's how to bump up Eclipse's memory.

4. Generation of Hibernate-Mapping files. I really hate it to look within a jarfile how the Hibernate mapping file looks like. It is nice to get it generated, but I prefer to be able make adjustments to it by hand to try out things quickly. And it is quite hard to enter special SQL statements in an Hibernate file, if it gets overwritten all the time.

You can create/modify the Hibernate mapping files by hand if you prefer. From the FAQ:

If you have an @hibernate.class tag on a POJO - hibernatedoclet will generate the mapping file into build/dao/gen. If you have a mapping file (*.hbm.xml) file for your POJO in the src/dao/**/model/* directory, it will overwrite the generated version. If you don't want to worry about the two conflicting - just remove the @ sign from @hibernate.class in your POJO and put your hbm.xml file in the model directory.

No build.xml modification are need for this to work. The "package-dao" target will include these mapping files. If you want to get rid of the hibernatedoclet process, you can do that- but make sure and run it first - and then copy all of the generated hbm.xml files into your model directory.

5. I don't like to get my struts.xml merged from many sources. I like to have one struts-config file holding all my struts configuration.

I agree this is kinda painful, but so is developing with Struts. You should be able to move the generated struts-config.xml into web/WEB-INF and remove the <strutsconfigxml> from build.xml to get the behavior you're looking for.

As far as throwing out the build.xml, I'm actually planning on doing that with my current project. I will keep it in place for the development phase, but I hope to move the application into a large build system once I'm done. Since it's all Java code and XML in the end, this shouldn't be hard to do. I did it when migrating to Maven 2, so I know it's possible. As far as Karsten's opinion of Maven 2, he may be right - but I hope to make a strong effort to make it very useable when using AppFuse. In fact, I hope to make it possible for users to use their IDE their entire time, with no need to run any Maven commands. Of course, that could be a pipe dream - only time will tell.

As far as sounding like the BileBlog, the more you rag on AppFuse, the better. Remember, screaming users are a good thing.

How do you sell good technology to average developers?

I received some interesting questions from someone who attended my talks at the Spring Forward conference last week. Below are the questions and my responses:

One of the things I'm working through in our hidebound stick-in-the-mud biggish company is: if you concoct a brilliant framework around the really right technology, how do you make it usable by mere mortals, that is average to below average developers?

Document, document, document. Assume nothing when you write the documentation (on a wiki or whatnot). Newbies love step-by-step tutorials. If your kick-ass framework is any good, you should be able to automate and hide complex pieces so they never need to know about them until they're interested.

I think AppFuse really helps in this regard, but I'm dealing with people who most naturally will use ColdFusion or ASP with no separation of concerns whatsover. They are are pretty blown away by lightweight J2EE and thus tend to reject it out of hand as being hippies' wet dreams.

I had a class a couple weeks back that was 1/2 PHP developers. They didn't like the idea of Java either - mainly because they're used to doing UI development and such. PHP, CF and ASP developers are UI developers that would prefer not to compile/deploy code. So you need to do things that make their job easier and allow them to be UI developers. Create a Generic DAO and Manager using Generics that allows them to CRUD any object - so they won't need to write backend code. Heck, you might even separate responsibilities so they're doing mostly web development. Of course, with web development, you'll still need to write Controllers and such. If you can use something like Maven 2 + the Jetty Plugin, there's no deploy cycle. Save, refresh your browser and voila - change is there. That's what these folks are used to and that's what they want to see when developing Java. Getting rid of the deploy cycle is an excellent idea IMO.

What do you think? How do you make Java development easier for developers of a company "switching to Java"? I've had a fair amount of clients in recent months switching from .NET or PHP to Java. It's a rare case that developers are actually happy about the move. Of course, when I'm done telling them about all the great frameworks and tools they can use, they're even more petrified. There's just too many for them to keep track of, especially if they're new to the stuff. AppFuse definitely simplifies things, but I doubt it makes development as simple as plain 'ol PHP or .NET. Then again, after you learn how to use the frameworks in AppFuse, it can be extremely productive to develop with (and scalable to boot!).

Spring 2.0, AppFuse and Equinox

Spring 2.0 was released today. I hope to do an AppFuse 1.9.4 and Equinox 1.7 release in the near future - both containing the latest and greatest stuff from Spring 2.0. Hopefully the 2.0 release shows up in the Maven repo (here or here) in the near future.

Thanks to Interface21 and all the Spring Developers for such a stellar product.

Update: More Spring-related releases - Spring Web Flow 1.0 RC4 and Acegi Security 1.0.2.

New weather.com site built using AppFuse

From Jeff C (a Sr Developer for forgetaway.com, a new unit of weather.com) in Lightweight Java Development with Webwork, Spring, and iBatis:

Our new site, ForGetaway.com, launched 2 weeks ago, and its built on WebWork, Spring, and iBatis. Using those 3 frameworks as the backbone of the site was a great experience. I think that combination of frameworks can be considered lightweight, especially from a development standpoint.
...
Even the development/testing process is quick. Thanks to Matt Raible's AppFuse (which was used to get this app started), we have a sweet build.xml file that allows us (on our dev machines) to reload our app by having the build script talk to tomcat. So, even when a properties file or java class or static field changes, its just a matter of running the reload task in the build.xml file and tomcat reloads the app with all changes in under 5 seconds. Yeah, rails is probably quicker, but i can spare 5 seconds of my time to let my changes get reloaded by tomcat.

Reloading your application in Tomcat to see your changes sucks. However, AppFuse 2.0 will allow you to use the Maven 2 Jetty Plugin, which aims to eliminate the whole deploy cycle. This plugin is powered by Jetty 6, which has been rewritten for Continuations, NIO, Servlet 2.5. Hopefully we'll start to see more appserver plugins written for Maven 2.

I love hearing success stories like Jeff's. That's why I (and many others) work on AppFuse - to simplify Java web development. We know that it's more painful to develop web applications in Java than in scripting languages, but we continue to do it because tools like AppFuse make it enjoyable. Even though tools and languages are important for simplification, I believe that most project's success is determined by people. If you have good people, effective processes and a lack of politics - a project should have no problem being successful, regardless of the tools.

Did you know the new SourceBeat site is also powered by AppFuse? We chose the WebWork+Spring+Hibernate combination and were quite pleased at how easy it was to develop everything. We had 90% of the site done in the first two weeks of development.

In other AppFuse-related news, the demos have been running solid for 70 days straight. I'll admit that's not a very log time, but it does prove there's no memory or connection leaks in the software. The number of currently active sessions is as follows:

• /appfuse (Struts): 456
• /appfuse-jsf: 206
• /appfuse-spring: 105
• /appfuse-tapestry: 94
• /appfuse-webwork: 178
• /spring-kickstart: 17
• /struts-resume: 36
• /wiki: 256

The default session timeout is set to 10 minutes in AppFuse.

Windows Vista

I spent some time this past weekend playing with Windows Vista. By playing, I mean I tried to install it on a couple machines. The first lucky recipient was my MacBook Pro. I attempted to install it as both a clean install and as Windows XP upgrade in Parallels (Build 1884 RC). No dice - I got a blue screen of death with both installs. It didn't even make it to the "copy files" phase. Next, I tried it on my Windows box. Rather than blow away Windows Media Center (the kids would kill me), I installed it in VMWare Server. Amazingly enough, it worked without any issues. While both VMWare and Parallels label their Vista support as "experimental", it seems that VMWare is doing a much better job. I wonder when VMWare is going to release their VMWare Server for the Mac?

After installing it, I discovered that Windows Media Center is included in Vista, so I'm guessing I could easily upgrade Windows Media Center w/o losing any functionality. I played around with the OS a bit and after about 10 minutes decided I liked the look of XP better and the look of OS X way better. It seemed very sluggish as well, but I'll attribute that to the 768 MB of RAM I gave it in VMWare. Will I upgrade? Probably, but at this point, I don't see a whole lot to get excited about (at least from an end-user perspective).

Maven, Cargo, Struts 2 and working outside

Life is pretty good today. I'm currently working outside - in a courtyard area near the 30th Street Station in Philadelphia. There's 4 restaurants in the courtyard, all with outside seating. It's 72°F and beautiful. I plan to work for a few hours, then hop on the 5:00 train to NYC.

The reason I'm writing this post is to point out a few useful tidbits I've picked up today. First of all, Andrew Glover has written a developerWorks article on Cargo titled In pursuit of code quality: Repeatable system tests. In this article, he shows how to use jWebUnit as well as DbUnit. While the article uses Ant, Andrew mentions that Cargo also works with Maven (and has a Java API too).

Equinox uses jWebUnit, Maven and Cargo, but it doesn't currently support running Cargo from Maven. The major reason for this is I tried to automate running jWebUnit tests from the antrun-plugin and couldn't get it to work (I only tried for 10 minutes). Does anyone have any insight for including jWebUnit tests alongside your regular tests, excluding them from Maven's "test" phase, and running them in the "integration-test" phase? The good news is AppFuse 2.0 uses Maven as well, and we have Cargo + Canoo WebTest working just fine. BTW, did you know that Mergere’s Maestro (a free product) includes Equinox? If you're looking to learn Continuum and you're familiar with Equinox, downloading Maestro is probably a good start.

Speaking of web testing, I've been playing with Selenium lately. I was able to easily integrate it into Thomas and I's Spring 2.0 Kickstart application thanks to these Maven and Selenium integration instructions. The only issues I've run into so far are specifying an initial URL that works in Selenium core as well as Selenium IDE and integrating Selenium with CruiseControl. If you're interested in learning more about Selenium checkout Catching up with Selenium on InfoQ.

Last, but certainly not least, Struts 2.0 was released today. I've already integrated this into the Struts version of AppFuse 2.0. If you like living on the bleeding, you could dig in and try it out today. Unfortunately, I haven't had a chance to put a whole lot of documentation together yet. I hope to install Confluence on appfuse.org sometime this week to start documenting how bad-ass AppFuse 2.0 will be .

Speaking of 2.0 releases, wasn't Spring 2.0 Final supposed to be released yesterday?

Comparing Web Frameworks Presentation

I've uploaded my Comparing Web Frameworks presentation I delivered today. This presentation is still somewhat outdated - all the stats I have in it are from February of this year (2006). I've also updated the Equinox framework-comparison page to have links to some more readable papers.

Spring Forward 2006 - The Keynote

After a 1 and a 1/2 hour cab ride, I arrived at Spring Foward 2006 just in time for the opening keynote. It looks like I'll be doing a 2nd talk this afternoon as Clark Richey was unable to make the show. I was given a choice of talks, and I chose "Comparing Web Frameworks" because that's a fun talk to do.

Thomas Risberg introduced the show (and the new Philadelphia Spring User group site), and now Colin Sampaleanu is talking about Spring. Spring 2.0 is fully backwards-compatible. There's a huge user base that demands full backwards compatibility so their old code still works. Spring 2.0 will run on your existing infrastructure: Java 1.3, 1.4 or 5. It'll run on all major application servers, as well as a simple servlet container.

The first major new features in Spring 2.0 are the simpler (extensible) XML configuration, as well as new AOP mechanisms.

XML Configuration in Spring 2.0

• Ability to define new XML tags to produce one or more Spring bean definitions
• Tags out of the box for common configuration tasks
• Problem-specific configuration (easier to write and to maintain)
• XML schema validation (better out of the box tool support, code completion for free)
• Exploits the full power of XML (namespaces, tooling, etc.)
• Backwards compatible (full support for <beans> DTD, complete interoperability b/w classic and extended configuration)

JNDI Lookup example (Spring 1.2.x):

<bean id="dataSource" class="...JndiObjectFactoryBean">
    <property name="jndiName" value="jdbc/StockData"/>
    <property name="resourceRef" value="true"/>
</bean>

In Spring 2.0:

<jee:jndi-lookup id="dataSource" jndiName="jdbc/StockData" 
    resourceRef="true"/>

AOP in Spring 2.0

• Simplified XML configuration using <aop:*> tags
• Closer AspectJ integration (pointcut expression language, AspectJ-style aspects in Spring AOP, @AspectJ-style aspects in Spring AOP that are fully interoperable with ajc compiled aspects)
• Build on strengths, eliminate weaknesses
• Preserve ease of adoption (still zero impact on development process/deployment, easier to adopt)
• Benefit from the power of AspectJ
• Spring and AspectJ are still separate projects, but work close together since both projects' leads work for Interface21

AOP is about pointcuts:

• Pointcuts give us the tool to think about program structure in a different way to OOP
• Without a true pointcut model, you only have trivial interception
• By integrating AspectJ's pointcut expressions in Spring AOP, it's a much more powerful AOP framework

Hot on the heals of Spring 2.0, Spring Web Flow 1.0 will be released. It's a full Spring subproject and part of Spring's web stack. Using SWF, you can capture a logical flow of your web application as a self-contained module, at a higher level. Another interesting project is Spring LDAP. It's a Spring subproject that simplifies LDAP operations - based on the pattern of Spring's JdbcTemplate. It encapsulates nasty boilerplate plumbing code traditionally required for LDAP.

Finally, Spring 2.0+ will support OSGI. So what is OSGI? It's an industry driven framework specification, with multiple implementations. It has a dynamic omponent model, based around the idea of bundles. It's a full component model with classloading (for isolation and versioning), lifecycle control definition, etc. It's the foundation of Eclipse's plugin architecture.

Why do you need Spring-OSGi? Spring-OSGi is an integration library for Spring in OSGi environments. For those that need it, allows a more powerful component programming model. Without Spring having to re-invent the wheel, ApplicationContexts become bundles that are able to import and export services with full isolation and integration into OSGi lifecycles. The project is moving along rapidly, with large amounts of interest and involvement from vendors such as BEA, Oracle, IBM members of the OSGi foundation and the general public.

Finally, don't forget about The Spring Experience 2006. It's 3 days, 55 sessions across 5 tracks, including: Core Spring 2.0, Core Enterprise 2.0, Core Web 2.0, Domain-Driven Design and Just Plain Cool.

Lessons learned from using VMWare, Ubuntu and Maven 2 in a Training class

Last week I taught a Spring 2.0 training class in Milwaukee, Wisconsin. This class was different from previous classes because I made a VMWare image of Ubuntu for students to use when doing the labs. They also used Maven 2 and all the computers were without an internet or network connection (yikes!). Eclipse was used for the IDE and Maven's Jetty plugin was used for any web development activities. I'm pleased to say it worked out pretty well, but there were a couple of things I thought I'd write down for others trying this approach.

First of all, this was my first experience using VMWare in a classroom setting. In the past, I've had students setup their own environments. I've also built machines at the training facilities - and had their staff ghost the image for students. I think having students setup their own environments is a good idea, but I've had mixed results. There's always some folks in class that have no interest in knowing how things are setup and would rather everything "just works". These folks are usually disappointed when they have to spend 20 minutes installing a bunch of software. There's always a couple who don't read the instructions thoroughly and install things in the wrong locations. And then you have the folks that want to work on their Linux or OS X laptops. I can generally work it all out b/c I know Windows, Linux and OS X - but this is generally not a good avenue for instructors unfamiliar with multiple operating systems.

The second method - building a machine at the training facility (or client site) and having it replicated - works very well. However, it's often difficult to get private courses (at client sites) to use this method, and students don't get to walk away with anything. The VMWare option, however, allows you to burn the image to a DVD and give students everything from the course, including the computer they worked on.

I've thought of using the VMWare earlier this year, but never seriously considered it until I spoke with Howard Lewis Ship at this year's OSCON. He said he'd used it for a couple classes, and it worked great. He gave me a sample DVD and I used it to start creating my DVD (thanks Howard!). The nicest thing about using this DVD was we were able to brand it for students, as well as setup all 18 machines in the classroom in less than an hour.

Here is a list of issues I found with using a VMWare setup in the classroom:

• I downloaded the Ubuntu 5.10 image to begin with. After upgrading to 6.06 and installing all the standard Java development software (less than 100MB), my image was 8GB. I was able to shrink it to 4GB and zip it to 2GB, but it's still quite large. Maybe installing 6.06 from scratch would slim things down.
• On my home machine (dual core AMD with 3GB RAM), the VMWare image ran very fast, with no noticeable performance issues. I used VMWare Server at home, and VMWare Player during the class because it didn't require a (free) serial number. I had it set to 768MB of RAM at both locations, but the machines were noticeably slower (and close to unusable) in the classroom. The classroom machines were 2.5GHz with 1.5GB of RAM.
• Since I knew most developers would be Windows users, I gave students the option to have me build their Windows environment. One student took me up on the offer and the only painful part was getting the Maven repo to the students machines. I had the Windows setup software on the DVD, so I was able to use that, but then needed to copy my local Maven repo to a thumb drive to transfer that. In the future, I'll put the Maven repo (only 36.5 MB) on the DVD.

All in all, using VMWare in the classroom turned out to be a good experience. It's likely we'll use it for most of our classes, but we'll also fall back to setting up a Windows environment for those students who don't like Ubuntu. As far as using Maven 2, it's been working great too - most of the students didn't even know it was used b/c they did everything in their IDE.

New Tutorial: Integrating JBPM into AppFuse

Ameer Ahmed has written a tutorial titled Integrating jBPM into AppFuse. If you're interested in using jBPM in your project, you may want to check it out. I'm sure Ameer would appreciate any comments on his work.