Raible Designs

The AppFuse Generator

I found the AppFuse Generator project in my comments last night. Richard So seems to have created a nice code-generation tool for AppFuse. It looks like it can create/modify all the files you need to CRUD a database table. I took a brief look at the code and it's all based on Velocity templates, so you should be able to easily tweak things.

This tool does seem to generate the DAOs/Managers - which can lead to more code to maintain. It would be nice if it could be modified to be similar to AppGen where there's a "detailed" version (that generates everything) and a "default" version (which only generates the web tier classes). The default version could use the generic "dao" and "manager" beans. I wonder if this tool supports running/installing the same table more than once? This currently doesn't work too well with AppGen, but shouldn't be too hard to fix.

In reality, I'm pumped that Richard has created this, as well as a project to back it up. I especially like that he's going to try and create an Eclipse Plug-in as part of this project. Nice work Richard!

Studying vs. Doing

My parents are in town for this next week and I expect to relax most of the week, but also squeeze a few hours in each day for Java. I'll probably do a bit of work for clients, but I expect to spend most of my time with Tapestry and JSF. I have to write a chapter that includes these frameworks in 3 weeks and I hope to integrate them into AppFuse by the end of the year.

Last night, I started thinking - I can use this week for 2 things: reading or doing. I could finish reading Tapestry In Action and get a good start on Core JSF. Or I could make the leap and begin implementing them in AppFuse. The latter sounds like more fun. Of course, the books should serve as good reference guides when I need help.

[ANN] DisplayTag 1.0 RC2 Released

Fabrizio, the main man behind the Display Tag, has been fixing bugs and adding features at breakneck speed. Early this morning, he released the final 1.0 candidate for the Display Tag. Good stuff - thanks Fabrizio!

• Download
• Release Notes
• Maven Changes Report
• Demo

Tuesday at ApacheCon

It's now Tuesday morning at ApacheCon and I'm proud to admit I've been pretty lame on the party front so far. It feels great though, I went to bed at 10:30 last night and slept until 9:30 this morning. I pretty much crashed after having such a hectic schedule the last couple of day.

On Saturday night, I was up until 4:00 a.m. cranking out Chapter 10 of Spring Live. I got back up at 7:30 and almost finished it by noon. At 1:00, I arrived at Denver's No Fluff Just Stuff, and moderated a BOF on Comparing Web Frameworks. Then at 2:00, I did a session on AppFuse. Following that, I spent 2 hours finishing up Chapter 10 and sent it off to for editing. 18 pages in 18 hours - oof.

After sending off my chapter, I headed home and had dinner with the family before heading to the airport at 7:00. We arrived in Vegas at 10:30 and went to the Hard Rock for beers. I didn't have any cash so I borrowed some from Jim. After 10 minutes of Blackjack, I was up $120, so I paid Jim back and called it a night. I got heckled as I left the Hard Rock at 3:00 a.m.

Yesterday (Monday), I woke up at 8:30 with a raging hangover. Damn wine chasers - don't seem to work for beer. Bruce didn't take any, got 3 hours of sleep and felt fine. My talk was at 11:00 and I managed to stifle the hangover about 5 minutes before it. The talk went well and the room was packed (approx. 100 folks). After the talk, I grabbed some lunch with Scott, Jim, Jonathan, Howard and his wife.

At 2:00, Dion interviewed me for TheServerSide. At 3:00, I had a meeting with the SourceBeat guys, and had some beers with Michael Koziarski around happy hour. Then I hit an ApacheCon sponsored free-beer thing and later headed to the "Pink Taco" with Jonathan and Dave. I could barely stay awake after dinner, so headed to bed early.

Today, I plan on attending a few sessions and possibly doing some gambling this evening. Sure is nice not having any commitments for the rest of the week. I have a few meetups with folks, but nothing that requires preparation.

Tapestry by Example with Erik Hatcher

It's Saturday morning and I plan on learning more about Tapestry this morning. There's pretty light attendence in the room. Too bad - I bet if it was a JSF talk, the room would be packed. In this talk, we're actually going to build a real application on-the-fly.

Why another web framework?

• HTML should be HTML
• JavaScript Embraced
• Reusable components
• Free developer from dealing with plumbing
  • Request/Response
  • Session/Application Scope
  • URL Mappings (nice, but leads to ugly URLs)
• Event handler driven
• Asset handling
• Line-precise error reporting

Erik says its one of the few frameworks that embraces JavaScript so much. I dig this b/c I think JavaScript is important for web development. Look at what the GMail guys have done with JavaScript. It'd be wicked cool to have this sort of thing open-sourced so we could all create GMail-type interfaces.

Dirty Laundry

• Heavy Duty - can be overkill for small/simple app
• Potentially steep learning curve. More of an un-learning curve. The Servlet API isn't in your face - so all that knowledge is useless.
• Not widely accepted - managers haven't heard of it
• Some awkward conventions (i.e. abstract classes)
  • and some non-intuitive necessary tricks
• Unit testing tough - do you unit test your swing app's listener methods?
  • Tapestry Test Assist should solve this problem
  • Howard's caught the TDD bug, so this should get better
• Lousy URLs - there's a patch on the wiki to fix this
  • Tough to do hit/stat tracking
  J2EE declarative security
• Example applications
  • Workbench and VLib included with Tapestry
  • Better Pet Shop

Workbench Demo - DatePicker component does do i18n (very cool!). Client-side validation does one-field at a time, like WebWork does. I prefer the "all messages in one pop-up" approach that Commons Validator has. Pallete component looks very cool - you can move and re-order items from a multi-select on the left to a multi-select on the right. Chart component looks pretty cool - you can generate graphs very easily. Unfortunately, it's not part of Tapestry, but you can see how to do it in the Workbench app. If you want to see an online version of the workbench, I have it setup on my server.

Repositories for components: Tacos, Tassel, T-Deli and a few mentioned on the wiki.

To bring a component to life, you simply add a "jwcid" to an HTML tag. You can specify initial values for page properties using <property-specification initial-value=""> tag in your template's .page file. The value is implicitly an OGNL expression, and you can define lists using "{'value1', 'value2', 'value3'}". This is great for prototyping before you have a backend or even a page class. To remove elements in a page, specify jwcid="$remove$" on an HTML element and it'll be removed at render time. The restriction is you can't have Tapestry components inside a $remove$ component.

If you don't want to use abstract methods (and hence classes) in your page class, you can use getProperty()/setProperty() methods. However, the recommended way is to use abstract methods.

Templates - two different types. You can put the @component stuff directly into your page - or you can use jwcid's and refer to a name that's defined as a <component> in your page-specification XML file. The Border component can be used to do page decoration like SiteMesh. You can use the Shell component to declare stylesheets/scripts on a per-page basis. This is something I do a fair amount, so it's nice to see it's built into Tapestry.

Internationalization - Resource bundles are component specific (one .properties per page). In a .page, you use <message-binding>. In a template (.html), you use attribute="message:key" or <span key="">. The "key" attribute can't be used on any ol' HTML element, only on the <span> tag. In .java, you use getMessage() and format(). You can also define a custom message source (i.e. read messages from a database). I'm impressed with how easy it is to do i18n in Tapestry. It's also cool that i18n is built-in for templates. Just include a locale extension on your page and it'll be rendered for users with that locale. For example, home_fr.html will show up for users with the French Locale.

Engine - gets all requests. Visit class - POJO that acts as like an HttpSession. You can configure it in the .application file. You can talk to your "Visit" class in a template using "ognl:visit". To call methods on it, just use "ognl:visit.method". Majority of services originate in the Engine. Generally override createXXX methods. Engines can be pooled or created on a per-session basis.

If you override the createXXX methods in Engine, you change the behavior for:

• message source
• global and visit
• property configuration
• template and component sources

contrib:Table - to override use <tr jwcid="columnColumnValue@Block"> - where "column" is the name of the column. Using this, you can easily put links and such into a table cell. Built-in TableModel can be used to talk directly to a JDBC DataSource. The TableModel is smart in that it only brings back the rows it needs to display. Add an exclamation point to the beginning of a column name to turn off sorting for that column. i18n is built-in for headers - the name of the column is simply looked up as a key in the page's .properties file.

Exception handling - Bail out by throwing an ApplicationRuntimeException. This tosses you to the default exception page, which you can override and "pretty up".

Validation - it's robust, but it can only validate <input type="text">. Erik thinks that Tapestry's validation framework could be much simpler and easier to use.

Dynamic Templates - can implement a IDelegateSourceTemplate and pull templates from a database or content-management system. To register your new TemplateDelegate, you can just register an <extension> in the .application file and point it to your class.

Page Lifecycle - initialize(), PageRenderListener(), PageValidateListener(), PageDetachListener(). Can use an ExternalCallback and ICallback to set properties on one page from another. Callbacks look very cool and there's a lot of discussions about them on the mailing list. The VLib app has a fair amount of callback examples.

This was definitely a good Tapestry session - thanks Erik.

Ant Hacks by Erik Hatcher

The first session I attended was Erik Hatcher's Ant Hacks talk. The first half of his talk was about Ant in general and was most of the stuff covered in Java Development with Ant. The good stuff was the 2nd half when he covered all the new stuff in Ant 1.6. Steve is working on an update to Java Development with Ant - shoujld will be a lot thinner. Below are some notes I took on what's new in 1.6.

• <image> task. Requires Java Advanced Imaging API
  • Performs image manipulation
• <import> task
  • No more entity ref includes needed - can use Ant properties for file reference now.
  • OO Nature
    • mix in imported build files - call super on imported file by specifying depends="${ant.project.name}.target" where the project.name is specified in the imported build file. Only targets that are overridden will get prefixed with namespace.
    • target overriding - main build file takes precedence
    • "abstract" targets - requires main build file implementation
• <subant> task - Recurses tree
  • Two modes: 1) same build file in each sub directory 2) crawl a tree and run same build file on all subdirectories
• Can have targetless build files. Everything outside a target gets executed before any targets
• <presetdef> - Use the same task and optionally repeat. Define the options once, give it a name and refer to it later. Can override attributes later in the build.xml file. Only works for one task at a time.
• <macrodef> - bye bye antcall. Much faster than antcall - does all the same things
  • You can specify attributes and elements as part of the definition. Tasks are wrapped in a <sequential> tag.
    • attributes are referred to in tasks using @{attribute}
    • elements are simple placeholders using XML <element/>
  • I could really use this stuff in AppFuse to replace the compile-module and test-module targets
  • "spawn" a new attribute on <java> - allows process to live past when Ant dies
• <scriptdef> - allows you to use all kinds of scripting languages - i.e. Groovy, JavaScript, etc.
  • the project, attributes and elements are given to you - so you can easily grab them in the scripts
  • helpful to know Ant's API when writing
• <antlib> - componentizes definition of types and tasks
  • anything that defines stuff - put in antlib.xml (i.e. <taskdef>)
  • mostly designed for Ant task distributors because they can package an antlib.xml with a namespace
  • has root element of <antlib> instead of XML
    • xmlns:antcontrib="antlib:net.sf.antcontrib" - brings in all tasks into your project

I really liked Erik's talk because AppFuse was inspired by his Java Development with Ant book. Its build.xml file was intially based on Erik's sample app and therefore, the first half of his talk pretty much pointed out tips and tricks that I'm currently using. The 2nd half of his talk was highlighting the new features of 1.6 - which he's suggested I adopt in the past. I've never had much desire (or time) to dig in and update AppFuse's build.xml file to 1.6. However, after attending his talk - it seems like it should be pretty easy to do. Good bye <antcall>, hello <macrodef>.

Later: One of the coolest things I saw in Erik's talk was how his Ant logging was color coded. I asked him about it and all your need to do is specify "-logger org.apache.tools.ant.listener.AnsiColorLogger" in an ANT_ARGS environment variable. Good stuff!

Denver's No Fluff Just Stuff starts today

It's time for another NFJS conference. I attended the one in June and had an awesome experience. I doubt I'll cover it as much as I did last time, that's just a lot of work - not to mention my cell phone's data bill was $300! As I look through the sessions, I'm noticing that it's a great thing to attend 2 of these conferences - b/c you can skip all the sessions you saw the first time. Since there's usually 2-3 good ones per time slot, reducing that down to 1-2 is nice.

This afternoon, I'm planning to attend sessions by Erik Hatcher and Stuart Halloway. Erik for Ant 1.6 and Subversion (maybe even Lucene) and Stuart for "dynamic, reflective languages". Since much of AppFuse's build.xml is based on Erik's Java Dev with Ant sample app, it'd be nice to figure out how to take advantage of 1.6 features (especially since 1.6.2 is required). I've never seen Stuart speak before, but I've heard he's excellent.

Saturday I plan on learning more about Tapestry from Erik (in a 3-hour session!). Since adding Tapestry to AppFuse is my next open-source development effort, this weekend and ApacheCon are good opportunities to learn more about it. I know, I should just buck up and read the book (I made it to page 100 a couple of weeks ago, nothing since), but it's tough to find the time.

I'll probably skip out tomorrow afternoon and work on Spring Live since Chapter 10 is due by Monday and I'm not done yet. Sunday, I'll be talking about AppFuse making open-source easier. "Brain, get ready to be stuffed."

[DJUG] Web Services and Geronimo

We're finally getting started at 6:25 and we were supposed to start at 5:50. Good ol' projector issues. This time it was a bent pin.

J2EE 1.4 introduced the first web services component type (SE) and augments EJB specification (2.1) to expose SLSBs as a web service endpoint.

Writing J2EE 1.4 web services ("endpoints")

Two J2EE components to implement a web service:

• JSE (JAX-RPC Service Endpoint). New component, new deployment descriptor. Looks like a servlet, acts like a servlet. Run's in a web container like a servlet. Isn't a servlet.
• SLSB. Exposed as web service via deployment descriptors.

JSE is easier because it's (mostly) POJO based. EJB might be preferred if you already have EJBs or you need transaction management. However, the SOAP client calling the EJB web service does not participate in the transaction (at least the spec does not define it).

"Mandatory" transaction attribute not allowed in EJB endpoints because SOAP client can't propagate transaction.

JSEs are similar to servlets:

• Instances run in the web container
• follow servlet lifecycle
• Must have a public no-arg constructor
• Can add servlet filters just like you do normally

Steps to writing a web service JSE:

    1. Write remote interface (the service endpoint interface) - must extend java.rmi.Remote and throw RemoteException
    2. Write implementation class
    3. WSDL Document
    4. Deployment Descriptors (web.xml and web-services.xml)
    5. Create WAR File

J2EE 5 will allow you to turn any POJO into a web service - no interface needed. Apache Axis can be used to generate the WSDL for you with Ant. You map the implementation class as a servlet, with a servlet-mapping and everything. The difference b/w JSE's and servlets is you can only map one JSE to one URL.

Writing web service clients. Client model is defined by the JAX-PRC 1.1 spec. You can write web service clients using three JAX-RPC techniques:

1. Generated Stub - Easiest. Done at development time. JAX-RPC is invisible to your code. Stub classes hide it. Runtime implementation will be tied to a vendors JAR because vendor tool will generate class based on WSDL.

2. Dynamic Proxy - Most Portable. Done at runtime. Your code asks JAX-RPC factory to create stub at runtime that implements SEI (Service Endpoint Interface).

3. Dynamic Invocation Interface (DII) - No Stub Necessary. Useful for tools - e.g. dynamically retrieve WSDL then show user on a GUI what services are available and allow user to select what should be called. Client sets URL, methods to invoke and required parameters.

Future of J2EE web services. JAX-RPC 2.0 (JSR 224) in the works. The goals of JAX-RPC 2.0 are several:

• Make writing WS simpler by using metadata and annotations.
• If you write an endpoint interface, your implementation class won't have to implement it.
• Remove requirement to define a remote object.
• Better support for document-centric web services.
• Integration with JAXB.

Tom's presentation was quite good for his situation. There was a *ton* of technical issues and he had to show his presentation on Chris Huston's Powerbook. This meant no demos since he had JBoss 4.0 and everything else setup on his Windows laptop. After flailing about for the last hour - he admits its time to buy a Mac.

Apache Geronimo

1. Apache Software License
2. Uses other BSD-derived, open source projects
3. Initial manifestation as a J2EE 1.4 application server 4. J2EE 1.4 certified (in-progress)

Started a year ago in September. The main motivator for Geronimo was there was no BSD-derived license for an open-source application server. The GPL license requires you to contribute code back if you customize a product. BSD allows you to do anything, you just have to give credit back to the originator. Sounds like the proper license for AppFuse to me.

The heart of Geronimo (the kernel) knows nothing about J2EE. It's designed to do just about anything you want it to do - it's just a configuration away. Jakarta project at Apache makes up a huge portion of ASF projects. Many of these projects are pieces of the J2EE puzzle. However, there wasn't any glue to hold it all together. Geronimo re-uses a *lot* of existing (best of breed) open source projects.

Geronimo still doesn't support Tomcat. The main reason is because 3 of the Jetty committers are part of the Geronimo team. Jetty was the first component every deployed in Geronimo. According to Bruce, someone is working on integrating Tomcat right now. You'd think this would be pretty easy and only take a couple days to do. Maybe I'm wrong.

Geronimo is NOT another lightweight container, web framework, or AOP framework.

It IS designed for long running servers. Its designed to tolerate partial component failures. System oriented services.

Geronimo Kernel - Fundamental Core

• Small memory consumption ~ 150KB code
• Component Registration
• Component Configuration
• Integrated Repository
• Lifecycle Control
• Dependency Manager

Now Bruce is going on about Maven and how it works. ZZZzzzzz. Maven schmaven. He does have a good point though - it works great for building and managing multiple projects and their dependencies. Geronimo has 30 sub projects - yow.

A lot of concepts and architecture in Geronimo is derived from Maven. Hmmm, I wonder if that means it's slow.

What are GBeans? They're a J2EE managed component (a JMX MBean), which are basically simple objects plus some metadata. Used to bridge JSR-77 lifecycle requirements. GBean wrappers allow just about anything to be plugged into be plugged into Geronimo. Implement the GBeanLifecyle interface: doStart(), doStop(), and doFail().

Bruce is now showing us the DerbySystemGBean that's used to stop and start GBean w/in Geronimo. Bruce has a lot of good things to say about Derby and thinks it's a much better database than both MySQL and PostgreSQL. That's a pretty strong statement, but since he met with Derby's architect last week, I tend to believe him. I'm assuming since I got AppFuse working with DB2 that using it with Derby would be pretty easy too.

Bruce says there's supposed to be a Geronimo release this week. I thought they were supposed to be done with Geronimo by this year's ApacheCon?

Now we're looking at an XML file that's a GBean configuration file. It looks like Spring is going to get some competition for long class names. And if you thought Spring's XML was verbose - Geronimo puts it to shame! I'm not saying this is a bad thing - it's just an observation.

GBean Archive - A JAR file that contains persisted GBean instances, GBean metadata. The Java classes in the GBean can reside in the JAR or be dependencies in a central repository.

GBean Descriptor - dependencies and configuration are defined in XML.

Repository: Structured collection of JARs. Designed to work in conjunction with Maven (pluggable implementation). Every JAR has a unique group and artifact id. Default repository is local file system, others allow auto-download.

Observation: Bruce's presentation is interesting - he seems to be targeting folks that want to dig into Geronimo and customize it. I think most developers just want to use it and would be more interested in seeing a demo of deploying an app on Geronimo, rather than how to integrate Derby or Jetty into the server. If it's so easy to plugin a component, why hasn't Tomcat been integrated? Maybe it's just me, I want to see it run and deploy apps to it - that's about all I want to do. In most cases, I shouldn't need to customize it. It's nice to know that it's an option though.

Basic Configuration Builder: Deployers are J2EE specific (JSR-88). If you have standards-compliant deployment descriptors - your application should deploy on Geronimo. Rather than calling them deployers, Geronimo uses "Builders". The Builders /deployers create configuration objects containing GBeans. Most complex Builder is J2EE deployer. It implements a JSR-88 deployment specification and accepts JARs, WARs, EARs, and RARs. You can also add in a deployment plan in XML. From this, a Geronimo Configuration ARchive (.car) is created. The nice things about these builder is you can do deploy-time optimizations, before the application is started.

Everything above the System Services and Kernel is hot swappable. You can remove the J2EE Configuration and replace it with something else like Pico or Spring. This means that you'll be able to swap out servlet containers w/o shutting down the server. That's pretty damn cool. If the system services and kernel are stable, and no JVM dumps occur - this means that your Geronimo server could be running forever. Sounds awesome.

High-availability (clustering, etc.) has not been built into Geronimo yet. This is primarily because this is not part of the J2EE spec. Developers are focusing on gaining 1.4 compliance, then they'll start looking at the fancy features.

Wow - good presentation Bruce. I feel like I know more about Geronimo than I ever wanted to know.

As I was getting ready to post the above transcript, I noticed that Geronimo 1.0 M3 was released. According to Bruce's presentation, this is the last release before 1.0. Nice work gents.

How do you unit test your Velocity pages?

I've started working with an additional client this morning and one of my first tasks is to figure out the best solution for 1) unit testing the UI and 2) unit testing Velocity templates. It's funny how the blogosphere makes life so much easier. Today was my first meeting with the client and they wanted to know if there was a way to test Velocity templates. Yesterday, I saw a headline in NetNewsWire about unit testing Velocity. I glossed over it b/c I didn't have any use for it. When they mentioned it today - I remembered it, searched on java.blogs and found JUnit Testing Velocity. Folks might think that reading blogs leads to reduced productivity - but I think it leads to more efficient productivity.

I think I'm going to implement something using the JUnit/Velocity stuff above and jWebUnit. jWebUnit will be used to test the WebWork actions and their interaction with the Velocity templates. Anyone had experience (good or bad) using this approach on their projects? Any other alternatives you've used to ensure error-free Velocity pages?

I like jWebUnit because you can easily switch locales and test against ResourceBundle keys for i18n. I don't think this is possible with Canoo's WebTest. The nice thing about Canoo's WebTest is they're migrating to HtmlUnit (rather than HttpUnit), which supposedly has a lot better JavaScript support. Both jWebUnit and WebTest currently use the Rhino js.jar - which throws exceptions for perfectly good JavaScript code.

BTW, anyone know why searching for "appfuse" on JavaBlogs causes a 500 error?

[ANN] AppFuse 1.6.1 Released

This release is primarily a bug fix release, but it also contains a slick "AppGen" tool for generating full CRUD (with sample data and tests) from a POJO. AppGen essentially automates everything you do in the tutorials. I still encourage users to read through and do the tutorials in order to learn the code that is being generated. This feature basically reduces the amount of files you need to create/alter for CRUD from 16 to 2. Better yet, rather than generating the DAO and Manager (as well as the tests), it just uses generic methods in the base implementations. This eliminates the need (and hopefully desire) to create so many DAOs and Managers. In most cases, you can simply use the "manager" bean in your Actions/Controllers and call its respective methods. Thanks to Hibernate for making generic CRUD possible with only a handful of methods. Now you should be able to simply concentrate on the web-tier and only modify/create backend classes when you need special behavior.

• Download
• Release Notes
• Learn more about AppFuse
• Live Demos:
  • Struts + Spring + Hibernate
  • Spring + iBATIS
  • WebWork + Spring + Hibernate

To upgrade your 1.6 based application, I recommend performing the following steps:

• Download 1.6.1 and extract it to your hard drive.
• If you've renamed your packages, use the Rename Packages Tool to rename packages in 1.6.1.
• Use Beyond Compare (Windows only) to diff the your project against 1.6.1.

This is how I've always done my AppFuse upgrades for Struts-Resume. It takes a couple of hours, but it's a lot easier than me trying to create an upgrade package.

I'll be talking about AppFuse this weekend at Denver's NFJS Conference. Next Monday I'll be in Vegas at ApacheCon. I've never done two different talks back-to-back before, let alone at two different conferences. Should be fun.