Raible Designs

The Colorado Software Summit in Keystone

This week I'm speaking at the Colorado Software Summit in Keystone, CO. I love this conference because it's so close to home (only an hour drive) and because it's so relaxed. The organizers, Wayne and Peggy Kovsky, do an excellent job of organizing the show. I've never felt more cared for as a speaker, including the fact that they plan and communicate with speakers for the preceding 6 months to the show. Not only that, but it's in one of the most beautiful places in the world. Check out the view from our condo this morning.

If there's any sessions you'd like me to attend and blog about, let me know!

Equinox (a.k.a. AppFuse Light) 1.7 Released!

This release's major new features are upgrading to Spring 2.0, Hibernate 3.2, an Ajax + Spring MVC version, an Acegi Security + Spring MVC version and Struts 2.0 as an optional web framework. It's highly likely that the "extras/security" package can be installed with other web frameworks, but it's only been tested with Spring MVC. Furthermore, this release provided all of the different combinations that Equinox provides - all 50 of them!

All of the frameworks used in Equinox, as well as most of its build/test system is explained in Spring Live. A summary of the changes are below (detailed release notes can be found in JIRA):

• Added extras/spring-ajax with examples of ajaxified displaytag (with AjaxAnywhere), in-place editing (Script.aculo.us), in-page updates (DWR) and lightbox (Lightbox gone Wild) popups.
• Added extras/security with Acegi Security integration for authentication and authorization.
• Automated creation and testing of all possible combinations for distribution.
• Converted from JSP to Facelets for JSF/MyFaces option.
• Integrated Ajax4JSF into JSF/MyFaces option.
• Added Struts 2.0.1 as web framework.
• Upgraded to Spring 2.0, including improved XML syntax and JSP Form Tags
• Added Cargo settings to pom.xml so it's possible to run web tests from Maven.
• Changed dataSource bean to use a connection pool.
• Added popup calendar (using jscalendar) to Spring MVC and Struts 2.
• Added OpenSessionInViewFilter for Hibernate and OpenPersistenceManagerInViewFilter for JDO/JPOX.
• Fixed foreign-language encoding issues with Spring's CharacterEncodingFilter.
• Changed from DAO to Dao to be more consistent with other projects.
• Dependent packages upgraded:
  • Canoo WebTest 1393
  • Cargo 0.8
  • Commons Validator 1.3.0
  • DWR 1.1.1
  • FreeMarker 2.3.8
  • jMock 1.1.0
  • JPOX 1.1.1
  • Hibernate 3.2
  • MyFaces 1.1.4
  • Spring 2.0
  • Spring Modules Validation 0.5
  • Struts 1.2.9
  • Tapestry 4.0.2
  • WebWork 2.2.4
• Dependent packages added:
  • Acegi Security 1.0.2
  • Ajax4JSF 1.0.2
  • AjaxAnywhere 1.2-rc2
  • Facelets 1.1.11
  • Struts 2.0.1

Download. For more information about installing the various options, see the README.txt file.

Demos:

• Spring · Spring + Ajax · Spring + Acegi
• JSF + Facelets
• Struts 1 · Struts 2
• Tapestry
• WebWork

Thanks to all the users of Equinox for making this a great release!

P.S. I'm fully aware that this project's name conflicts with an Eclipse project.

Abbie and Jack - October 2006

Abbie and Jack had their picture taken at school this week. The picture turned out so cute, I couldn't help but post it. It's hard to believe that Abbie was born 4 years ago and Jack is just over two. They sure grow up fast!

Confluence installed for AppFuse 2.0 Documentation

The last item on the AppFuse Roadmap for 2.0 M1 is setting up the documentation system. I'm still undecided on whether Confluence or DocBook is a better system to use. However, I am certain that using a wiki to document an open source project is the lowest barrier to entry. For more on this topic, see my post from a month ago. In an ideal world, Confluence could be used as an authoring tool, and everything could be exported to DocBook for storing in SVN. Even better, pages that are "core" to AppFuse could be automatically saved in Subversion, and built using Maven's DocBook (or Confluence) support. Who knows, this is still new territory for me, and I feel like I'm losing momentum just thinking about it.

So far, I've installed Confluence 2.2.9 at http://dev.appfuse.org, but this will change in the coming weeks. I plan on eventually moving it to appfuse.org and leaving the demos on the demo.appfuse.org server. Hopefully there won't be too many 404s when we make the change.

Currently, I have Adaptavist's Builder installed for managing/manipulating themes. I've done some work with the default theme, but I think we can do much better. One cool thing I did find was the Page Tree Plugin that allows for Ajaxified tree menus like Stripes has.

Thanks to Atlassian and Adaptavist for the free product licenses.

Integrating Facelets and Ajax4JSF with MyFaces

I spent a few hours tonight integrating Facelets into an AppFuse-based application. The integrating was fairly easy thanks to the work Thomas Gaudin did back in January. For the most part, it was just a matter of 1) replacing <fmt:message> tags with #{text['key']} tags, 2) replacing the <%@ include file="/common/taglibs.jsp"%> at the top of each page with Facelet's namespace tags and 3) renaming the pages from *.jsp to *.xhtml. The only thing that tripped me up was I thought the "c" namespace was the same as JTLS's URI, but it's actually a whole new URI. Thanks to the Facelets developers for a much-needed fix for JSF.

After I got Facelets integrated and working, I dove into integrating Ajax4JSF. Two hours later and I have the simple repeater demo working. What took so long? I spent an hour staring at (and googling for) the solution to the following error:

PhaseListenerManager.informPhaseListenersBefore(74) | Exception in PhaseListener RENDER_RESPONSE(6) beforePhase.
java.lang.NullPointerException
        at com.sun.facelets.FaceletViewHandler.writeState(FaceletViewHandler.java:759)
        at org.ajax4jsf.framework.renderer.AjaxRendererUtils.writeState(AjaxRendererUtils.java:850)
        at org.ajax4jsf.framework.renderer.AjaxRendererUtils.encodeAreas(AjaxRendererUtils.java:740)
        at org.ajax4jsf.framework.renderer.AjaxContainerRenderer.encodeAjax(AjaxContainerRenderer.java:128)
        at org.ajax4jsf.ajax.UIAjaxRegion.encodeAjax(UIAjaxRegion.java:210)

The solution turned out to be removing the FaceletsViewHandler from faces-config.xml:

<view-handler>com.sun.facelets.FaceletViewHandler</view-handler>

Also, it seems the following is required in web.xml:

    <context-param>
        <param-name>org.ajax4jsf.VIEW_HANDLERS</param-name>
        <param-value>com.sun.facelets.FaceletViewHandler</param-value>
    </context-param>

Hopefully this helps others googling for the exception above.

Implementing the AppFuse DAO layer with Spring LDAP

This week, I've been helping a click kickstart an application using AppFuse. The first order of business was re-writing the backend to support LDAP. They'd like to keep the Hibernate implementation in place, but they'd also prefer to have the option to use LDAP. Since a database will still be used to manage entities outside of User and Role, the LDAP implementation I have continues to maintain a userId and username in the database.

I'm pretty impressed that I was able to get 90% of the functionality completed in 2 days. Of course, it wouldn't have been possible w/o the excellent Spring LDAP project, nor the good ol' Acegi Security project. I'm deploying on Geronimo using the Apache Directory Plugin for LDAP. Getting a custom UserDetailsService working wasn't too difficult, but I am still having some issues with CRUDing LDAP:

• I get an Undefined Attribute Type error when modifying the non-String attributes in a User. This is quite strange since all the attributes are stored as Strings in LDAP.
• I get the same error when trying to remove a user from a role.
• There's no LdapUnit (like DbUnit) to delete/insert users and roles before running tests. I tried to use the LdapTestServer from Acegi, but no dice.
• Since the project has two versions (Hibernate or LDAP) in the source tree, the LDAP and Hibernate tests won't both pass. This is because the schema for LDAP only has 2 columns in the app_user table, while the Hibernate version of the table has all columns. The simplest solution seems to be removing the not-null constraints on most of the columns in this table.

If anyone has experience implementing User->Role CRUD in LDAP with Spring LDAP, I'd love to hear your thoughts on these issues.

RE: Experience First-Hand the Most Productive Way to Develop Enterprise JSF Applications

In Experience First-Hand the Most Productive Way to Develop Enterprise JSF Applications, Steve Muench writes:

If you are a developer responsible for creating enterprise J2EE web applications that work with database data, this new step-by-step tutorial should be eye-opening for you.

The tutorial does indeed look nice, but at 69 (printed) pages, is it really a tutorial? Seems more like a book to me.

Equinox 1.7 will include all framework combinations

Whenever I've done an Equinox release in the past, I've just uploaded the main zip file to java.net. This made it difficult for end-users because they were forced to install any optional frameworks themselves. While I've usually been successfull doing this, many users have had issues. Therefore, Equinox 1.7 will include *all* combinations as part of the release. See the Equinox Roadmap to see what still needs to be done for 1.7.

How many combinations are there? 35! That's right - there's 5 web frameworks (+ FreeMarker and Velocity for Spring MVC) as well as 5 persistence frameworks. CruiseControl is spitting out the combinations if you'd like to try them now. When I wrote the script to create everything this weekend, I was a bit worried about combining them and all getting all the tests to pass. Amazingly enough, all the tests passed on the first try. Thank you Spring, you separate layers quite nicely.

If you're interested in how this all works, take a look at release.xml. This file handles the artifact creation, as well as testing and uploading to java.net. I was hoping to create Maven 2 archetypes for all the combinations as well, but it doesn't look like it can be automated. I'd love to figure out a way generate archetypes from an existing project.

MyFaces + Facelets vs. Shale

At some point, I plan on replacing the JSF+JSP combination in AppFuse with JSF+Facelets. However, I'm wondering if this is just an interim step to a more full-featured framework like Shale and its Clay templates. Has anyone out there tried both Shale and MyFaces+Facelets? If so, which one worked best for you?

Should we use Shale for the JSF framework in AppFuse or is MyFaces + Facelets good enough?

Can JSP-based components (particularly Ajax ones) be used with Clay and/or Facelets? What's the best Ajax-enabled component library available for JSF? I know there's more everyday, so I'm looking for first-hand, real-world experience here. Thanks in advance for any advice or stories you'd like to share!

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.