I Didn’t Want Others to Overlook this Framework.
JAXenter speaks with ‘Seam in Action’ author Dan Allen on his work with Arquillian and Weld Maven as part of Seam 3, and how he came to be involved in Seam in the first place.
Dan is an employee of JBoss by Red Hat working on the Seam and Weld projects, a member of the JSR-314 Expert Group (JSF 2.0), the author of Seam in Action and a frequent speaker at major industry conferences. His presentation at JavaOne 2009 earned him the JavaOne Rock Star award. But he’s best known by colleagues for his passion for free and open source software, particularly Linux and Java enterprise technologies. You can keep up with his discoveries by subscribing to his blog (http://mojavelinux.com) or following him on Twitter (http://twitter.com/mojavelinux).
In part one of our two part interview with author of ‘Seam in Action’ and JavaOne Rock Star Dan Allen, Jan Groth and Andreas Eigenmann ask him how he first came to be involved in the Seam project, what he’s currently working on for the Seam 3 release, and his role as Seam Community Liaison.
Jan Groth: Dan, for those who don’t know you, could you tell us who you are and how you got involved with Seam?
Dan Allen: I’m going to be a little long-winded in my response, but I think it’s important to communicate what led me to Seam because it says a lot about the software itself. I didn’t select it arbitrarily.
More than a decade ago, I took the liberating plunge of wiping Windows off my computer and installing Red Hat Linux for the first time. Knowing that I had a say in what powered my machine, for better or for worse, was something I knew I could never live without again. If I didn’t like it, or I had a way to make it better, I could change it. Not only do I still run Linux (and my wife too,) I now work for Red Hat, a company that supports the Open Source operation system, develops Open Source software for middleware and spreads the Open Source model (even to entities like the US gov’t.) I work on the middleware part. I’m fortunate to be able to work full-time out of my home in Maryland (USA) on the Weld, Seam and Arquillian project teams and growing the JBoss Community. I also get to travel to conferences to meet the community and help them reduce their technology debt by learning about these Open Source projects.
But like many JBoss developers, my involvement began in the community. I had been jumping from one job to the next trying to find software that I could stand to work on. But much of it seemed to be these heavy architectures that required the coordination of at least three developers to add a new form field or screen to the UI. It was the typical story, either EJB 2 on the backend or JSP pages littered with SQL statements and thousands of lines long in the frontend. It made you want to hurl.
Then I came across a couple of books about Spring and immediately recognized that it was going to help cleanup these superfund disasters that were passing as business applications. It was a depend-on-nothing kind of architecture, and I really wanted to create separation. But while Spring helped a lot with the backend, it virtually ignored the frontend. At the end of the day, we had to produce web pages. I had seen some pretty horrendous ways of accepting form data, and JSF offered a POJO-based binding mechanism that drastically simplified the problem and allowed us to dump our in-house web framework. We linked Spring and JSF and started paving a new course.
Several very serious problems remained that the JSF and Spring tag team couldn’t solve. The first was that we had thrown out the JSF managed bean container in place of Spring, but Spring was inept at managing state. We either had no state with singletons, transient state with the request or too much state with the session. We settled in the middle by using a state saving tag in our JSF views. But it was a pretty hacky workaround, and it caused the application to be brittle and rigid. We just didn’t allow certain page transitions because it would be too complex to support. The second major issue was that JSF didn’t have a way of executing an action on page load. We came up with some solutions, but they always left a bad taste. Finally, the Hibernate code was a damn mess. Fixing one exception seemed to cause two other exceptions to appear. The code had comments like “don’t change the sequence of these operations or an exception will result.” Again, the problem had to do with lack of proper state management (and general understanding of ORM, but who was telling us the real story?)
I had heard that Seam may have a solution for these problems, but I also heard that it required JBoss and EJB and I refused to use either. We felt very independent being able to run our application on Tomcat and Jetty. But the problems with our architecture just nagged at me too much and I decided to just read the Seam manual. I couldn’t believe my eyes. State management and conversations, page “on load” actions, persistence context management, oh, and by the way, you can get rid of all that Spring XML. It’s like the Seam developers were reading my mind. And there was even more stuff in there, like JSF enhancements and utility components, security, e-mail, bpm, and the list goes on. I felt like a kid in a candy store. I started banging out applications in no time and I was happy with how they looked.
I didn’t want others to overlook this framework given how much it helped me. While the manual made sense, I knew it wasn’t enough. I first worked to get Seam into Maven, to broaden its reach. Then, I decided to yell from the mountaintops by writing a series about it for IBM developerWorks. The overwhelming feedback from that series made it pretty clear, someone needed to write a book about it (a higher mountaintop) that was going to explain every last detail. I took on that challenge (and believe me, it was quite a challenge.) While writing I fixed a huge amount of bugs in Seam, contributed enhancements and spruced up seam-gen to lower the barrier to get started with Seam. I quite literally immersed myself in Hibernate, JPA, EJB 3, JTA, JSF and Java EE 5 in general. I came to appreciate the value of the platform, the remaining limitations and what Seam had to do to fill in the gaps.
Because of all the experience I gained, today I can help steer the platform, rather than just write about it. So Seam was just the start.
Jan Groth: What is your current work in the Seam context?
Dan Allen: Right now, I’m helping to get Seam 3 organized and seeking out potential contributors while dabbling a bit in the design and development. We got held up towards the end of last year waiting for Java EE 6 to be finalized. Now, the emphasis is on shifting the momentum over to Seam 3 so that we can cover the most popular features from Seam 2, that are still needed in Seam 3, by the end of the year, with plenty of incremental releases along the way.
My work on the project infrastructure began by putting together an official section on seamframework.org with Seam 3 information, first and foremost to give it an identity. I’m very happy about the comprehensive information we have collected. There is information about how to download Seam 3, how to get involved, the status of the modules and guidelines for development. One of the key areas of work was putting together a module handbook that explained how module leads setup the infrastructure for the module (SVN, JIRA, Hudson, docs, etc), how a module should be structured, how to publish a release and how to coordinate with QE to have the module validated before a release.
I’m providing design advice and a hand with the coding for several of the modules (Faces, JMS, persistence) and also the Weld Maven archetypes. I’m also spending a lot of time with a new in-container testing framework named Arquillian, which takes the place of SeamTest from Seam 2. Really, it puts SeamTest to shame because it works with both JUnit and TestNG, it can run tests inside any container, or as a client to the container and provides injection into tests. Basically, it’s super flexible and extensible. Arquillian is the second generation of the CDI TCK infrastructure, now integrated with a Java API for assembling archives named ShrinkWrap. Both of these tools are part of the JBoss Testing initiative (tentatively named Coral), which you can think of as a Seam for testing. This stack is important for three reasons. It’s sorely needed, it was a sore spot of Seam 2 and it will be used as the basis of Seam 3 tests.
All in all, there is more work than can possibly be done in a day. And that keeps it exciting.
Jan Groth: JBoss recently announced the creation of a new position: the Seam community manager. Pete Muir blogged that it was decided to make this a rotating position starting with you. Can you tell us about your goals and plans as a community manager? Are there any special topics you are going to approach?
Dan Allen: Oh yeah, I’ve got that job too Actually it’s my favorite job. But before I get into it, I want to clarify the title.
Shortly after announcing this position, we got some feedback that compelled us to change the name of the role to Seam Community Liaison. Seam is part of the JBoss Community, which is led and managed by Mark Newton. My role is really catered more to the unique requirements of the Seam project. For one, the Seam wiki and forums are not hosted with the other JBoss Community project, so they must be tended to individually. (That situation could be changing soon; stay tuned.) In Seam 3, which I’ll talk about later, each module is lead individually, so there is a need to coordinate with each of the module leads to make sure they have what they need and that ideas propagate from one module to the next. Finally, I wasn’t particularly happy with the way the community was being handled towards the end of of Seam 2 development. I wanted to reach out more.
The special topics I want to address mostly come from the Art of Community. For a long time I had it on my list to read the Art of Community by Jono Bacon. I’ve followed Jono for quite some time and I’ve been impressed by what he has done to bring together the Ubuntu Community and make it productive. I wanted to see what he had to say. Page after page of the book my head was exploding with ideas of better ways to engage the community and make faster progress.
What Jono made me appreciate was that if you inspire the community and make it easy for them to get involved, you are not only going to end up with great software and great ideas, but a much larger group to share it with. Making a contribution has to be as frictionless as possible. We also want to have bug squashing days, documentation days, better governance of the forums, and get more in touch with the needs of our users. We have a way to go before we get there, but already we’ve made progress with the information on the website. I’m also lobbying to get seamframework.org reunited with the JBoss Community site so that it’s easier to do cross project communication. After all, Seam integrations many of the tools and frameworks in the JBoss Community, yet sits in a totally separate place.
The Art of Community is a truly inspiring book and it reminded me why I love doing what I do…it’s really about the people and the ideas. We are not just writing software for the community and publishing it as Open Source. It’s the community’s software, solutions to problems that come from the real world. We want to support and foster that engine and the Seam Community Liaison is the spark plug of the engine and ensures it’s properly greased.