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.

AppFuse used in Rails for Java Developers book

I received an interesting e-mail from Stuart Halloway this afternoon:

Subject: AppFuse rocks! and ...

Hi Matt,

I have been using AppFuse to generate many of the Java examples we use for comparison in the new book. Thanks for AppFuse -- I'd be miserable without it. I'd be happy to get you a comp copy of the book if you want it. (And delighted if you have any feedback on my use of AppFuse... :-) ).

Cheers,
Stuart

Hopefully Stuart and Justin don't make AppFuse and Java look too bad.

If you're familiar with AppFuse (or the frameworks it leverages) and want to learn Ruby on Rails, Rails for Java Developers should treat you well. I've never read one of Stuart or Justin's books, but I've heard them speak. They're both incredibly enjoyable to listen to.

Posted with permission from Stuart.

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.

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.

Using the Java Persistence API with Mike Keith and Patrick Linskey

I'm sitting in a presentation on JPA from Mike Keith from Oracle and Patrick Linskey from BEA. They asked the room how many folks are using (or have used) JPA. About 6 hands went up in a room of 50-60 folks. JPA is definitely bleeding-edge, and based on my experience, it's not quite ready for prime-time yet. I think this is obvious as most products that implement JPA haven't had a final release yet.

Background: Part of JSR-220 (EJB 3.0). It began as a simplification of entity beans and evolved into POJO persistence technology. JPA's primary features are:

• POJO-based persistence model (simple Java classes-not components)
• Support for enriched domain modeling (inheritance, polymorphism, etc.)
• Expanded Query Language
• Standardized object/relational mapping (using annotations and/or XML)
• Usable in Java EE and Java SE Environments
• Support for pluggable persistence providers

At this point, I tuned out to post my presentation from this morning. Most of the talk seemed to be pretty standard, as in they showed annotations, the EntityManager interface, and some JPA QL. Interestingly enough, they used the same entities that Thomas did in our Kickstart application. I wonder if there's a JPA tutorial out there that everyone is building their presentations from.

One interesting thing I heard from Colin is that Spring/Interface21 is looking into creating ready-to-go starter applications. For example, something that allows you to start with Spring + Hibernate right away, or to create something like Salesforce.com with minimal effort. Sounds similar to AppFuse, but who knows.

Spring 2.0 Kickstart Presentation

As promised, here are the details on Thomas Risberg and I's Spring 2.0 Kickstart Presentation:

• Project Home at Google Code
• Persistence Presentation
• MVC Presentation
• How to checkout code from Subversion
• Live Demo (nothing real fancy here, except for clicking on the black and white image changes colors)

I ran out of time during my talk, so I didn't get a chance to implement validation or show the Selenium tests I created. Oh well, I'll know better next time. I talked to a few attendees and they said they really liked the live coding stuff. Unfortunately, the presentation doesn't show me doing that - you'll just have to look at the code on the slides.

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.