Skip navigation

Dan's Blog

13 posts


Last week I announced that the JBoss Community submitted an application to participate in the Google Summer of Code (GSoC) 2012 program. We had over 30 project ideas identified by the time Monday rolled around and the applications were being reviewed.


You're fingers must have been crossed because the application was accepted! For the first time ever, the JBoss Community (independently, not on the coat-tails of Fedora) will participate in the Google Summer of Code. "Hack" yeah!


Interested students can browse the list of project ideas, get a list of potential mentors and find other necessary information on the GSoC 2012 ideas page on the JBoss Community site. Feel free to start contacting potential mentors today! You can reach mentors by private message or via the #jboss or #jbosstesting IRC channels on Freenode IRC.


Note: Applications are not yet open for students to start applying. However, it is time for mentors to sign up! Interested students should contact mentors on IRC or mailinglists to inquire about projects. Consult the timeline on the official GSoC 2012 page for dates.


We've setup a list for students and mentors to chat about GSoC in the JBoss Community. You can register for the list here:


We also encourage you to checkout the Fedora Project GSoC 2012 initiative. The Fedora Project was also accepted! Congratulations fellow champions of openness! There are lots of opportunities with Fedora as well, including a handful of cross-over projects, which you can find on the Fedora Project GSoC 2012 ideas page.


Thanks to all who have supported this process. It's going to be a great summer. Hack on!


I'm excited to announce that last Friday (March 9, 2012) Anil and I submitted the application for the JBoss Community to participate in the Google Summer of Code (GSoC) 2012 program. We had 25 project ideas identified at the time of submission, with more added over the weekend. Thanks to all project members who came forward with ideas!


The selected list of organizations will be announced at the end of this week (March 16, 2012). Keep your fingers crossed!


Interested students can browse the list of project ideas, get a list of potential mentors and find other necessary information on the GSoC 2012 ideas page on the JBoss Community site. Feel free to start contacting potential mentors today! You can reach mentors by private message or via the #jboss or #jbosstesting IRC channels on Freenode IRC.


Note: that applications are not yet open for students to start applying. Consult the timeline on the official GSoC 2012 page for dates.


We also encourage you to checkout the Fedora Project GSoC 2012 initiative. There are lots of ideas there as well, including a handful of cross-over projects, which you can find on the Fedora Project GSoC 2012 ideas page.


Thanks to all who have supported this process. Regardless of whether the proposal gets accepted, it's been enlightening to share project ideas and visions with you.

As I mentioned in my previous post, I was in Portland last week juggling four events:

  • Community Leadership Summit
  • OSCON JVM Language Symposium
  • OSCON Java & Data

It was non-stop action from the time I rolled into the airport after midnight on Friday until I had to drag myself away the following Thursday. This post will focus on the OSCON side of the action. The tiger is on the prowl!


change-world.jpgIf there was ever a time I wanted to be at multiple places at once (or be able to fork myself), this was it. OSCON 2011 blended my three main technology passions together under one roof: Open Source, Linux and Java. It was geek overload! This was also the inaugural year for Java, a coming out party of sorts. (Find out why Java finally got invited to the OSCON family in this video interview).

O'Reilly did an amazing job of preserving the conference in photos (see the OSCON 2011 Flickr photostream) and videos (see the OSCON 2011 YouTube playlist). I can honestly say that I didn't miss a single keynote, even though I could never manage to scrape myself out of bed early enough to catch one of them live.

A major focus of this conference, and for me personally, was the state of the union on JCP transparency (or, in other words, the progress on the "Is Java Open?" question). There were keynotes, sessions and one (rather provocative) panel scheduled to conjour up the straight answers. The panel, titled "Java Standards Annoyances", delivered a very clear message that fear and paranoia is running rampant and needs to be addressed.

"Oracle is evil!! Java and open source are doomed! The standards body is a zombie! .NET is going to eat our lunch. Larry’s planning on turning you into pet food for his Velociraptors!"

The panel turned out to be remarkably amicable, making its abstract and the "No punching" rule seem almost absurd. It turns out, that was the outcome the organizers from the London JUG, the newly elected community representatives to the JCP Executive Committee, anticipated. They wanted to make clear their commitment to reforming the JCP and making it accessible to Java developers. They did it with action, by bringing both sides to the table. In the end, Patrick Curran, chair of the JCP, acknowledged that many disputes were over an "old way of thinking" and invited everyone to participate in JSR-348 (i.e., to advance towards a new version of the process. You can find a more thorough recap of the panel in this JavaWorld article.

Curious what it means for a JUG to hold a seat on the JCP EC? About what reform they are planning? Check out the acceptance statement written by the London JUG, JCP reform and what it means for the Java developer.

Oracle certainly made significant strides at OSCON 2011 towards "cracking the code" in regards to their Java strategy and commitment to openness. I encourage you to watch the videos to get the story first hand. You'll likely agree that we are headed in the right direction, but there is still a gap to be closed.

"Open Source, Java and Oracle -- Cracking the code" presented by Steven Harris

For more detailed statements, see this write-up of Oracle's Vision of Java that was presented by Steven Harris.

"Who Needs Standards?" by Patrick Curran

For an interesting comparison to the JCP, see the article "Linux Standard Base and Its Role in the Community" from the August 2011 issue of Linux Journal. The LSB provides a standardized and tested common set of interfaces for ISVs to target. In essence, LSB is to Linux what the JCP is to Java, except that LSB is an independent workgroup and the test suites are entirely open and automated.

"JDK 7 in a Nutshell" by Joe Darcy

There were corresponding sessions for each of these keynotes, but those videos are not yet available.

To present a counter argument, Bob Lee asks the tough question in his keynote "Is Java open?" (skip to 9:30). He states his opinion, one shared by many community members, that it's open when the JCP is not controlled by a single entity.

355854043.jpgPerhaps you are wondering, why does it matter that Java and the platform standards are open? Members of the audience in David Blevins' presentation on TomEE learned pretty quickly. TomEE is an aspiring Java EE 6 Web Profile implementation built on Tomcat.

David is working very hard on getting all the tests to pass. How far along is he? He's not allowed to say. Those are the rules. How many tests are there? He's not allowed to say. Those are the rules. How is he running the tests? He can't show you. Those are the rules. Can you help him pass the tests? Not unless you sign your name in blood with his. Those are the rules. You see the problem?

Transparency is so important, especially for tests. After all, what good are tests if you can't show people that they pass? Would you believe me if I told you they do?

Fortunately, David can report how many CDI tests TomEE passes. Why? Because the CDI TCK (test suite) is released under the Apache License, Version 2 (an open license). That means he can share his progress and get community input. That's how we believe all test suites in the JCP should be.

Speaking of CDI, I gave a short presentation about CDI extension writing, titled "Hacking Java EE: CDI Extension n00b to l33t in 40 minutes" (told you it was short). The slides are below, though they likely aren't too much use until the audio and video are available. For now, they can be like an appetizer


I'm planning on doing an article on the topic which should serve as a more useful tutorial for those of you following along from home.

I thoroughly enjoyed my week at OSCON. I agree with Steven's point in that I felt we were able to make a positive impact on the Java community.

Looking back on the photos and videos, I wish I could have caught a few more sessions, booths and parties. But there's always next year, right? I can at least say that I did make it to the Red Hat booth, eventually!


I can hardly have any regrets since I met so many new people, established new friendships and strengthened existing ones. One of the best pieces of feedback I received was that JBoss has become a much better citizen of the Java community. That's a company I can be proud to represent!

I'll leave you with a picture of my new friends at the London JUG in the thick of the strategy of a giant chess match.


I was in Portland last week for OSCON, which really turned out to be four events stacked into one:

  • Community Leadership Summit
  • OSCON JVM Language Symposium
  • OSCON Java & Data

It was an intense week, to say the least

1554153515-2.jpgThis post will focus on the Community Leadership Summit, a free event held the weekend before OSCON. The Community Leadership Summit brought together community leaders, organizers and managers interested in growing and empowering a strong community around their projects, products or business.

My initial motivation for scheduling to attend OSCON was to participate in the Community Leadership Summit. This event was introduced in 2009 by Jono Bacon, community manager for the global Ubuntu community. The purpose of event is to cater to the growing community manager profession, serving as a first step in helping community managers and leaders define and refine their work, share knowledge and make connections in a vendor neutral way.

I've followed Jono's work for many years, read his book The Art of Community and have been taking on an expanding community role myself at JBoss. I figured it was a good time to learn from my peers about how to be a more effective community leader and share some of my own success stories. According to Jono, we are entering a renaissance of community management, so what better time to get involved?

Since the summit is a free event, I wasn't sure how many people to expect. Turns out, this is a pretty hot topic. There were nearly 200 participants. Since the event originated out of Jono's work with the Ubuntu community, I assumed most of the people would be open source community managers. That was certainly not the case. The group was surprisingly diverse and included employees from Adobe, Microsoft, Uservoice, Rackspace, Google and more. That supports the claim that the Community Leadership Summit is a strongly independent event. Indeed, Jono often reminds us that no company should have a monopoly on community.

The Community Leadership Summit is a barcamp-style unconference, which means the sessions are roundtable discussions proposed by attendees and scheduled at the start of the day. Session notes, and other information captured during the event, were posted on the Community Leadership Summit wiki. There was regular chatter on twitter, which you can follow by searching for the hashtag #cls11. To get eyes on the event, check out the stack of pictures Mark Terranova snapped.

What was most surprising to me (or perhaps just unexpected) is that most of the participants were eager to propose a session. Then again, this was my first unconference, so perhaps that's typical. Either way, I like it. There was no shortage of topics (the board from day one shown below), too many to choose from in fact. That's a good thing, as it kept the conference interesting.

Session board

Originally, I thought the conference was just one day. I had no problem committing when I found out it was two days because I knew there was a lot more to explore. Some people even suggested extending the second day, if that gives you any indication of how engaging the conversations were.

I moderated one session each day. You can follow the links to see the notes I wrote up about the session.

I thoroughly enjoyed all the sessions I attended and was very glad to get to know many of the other community leaders. I'll highlight a few of my favorite sessions I attended and why they resonated particularly well with me:

  • The DEATH STAR User Group (photo)

    One of the challenges in open source is that some companies don't have a focus on good. Rather, they have a focus on benefiting shareholders and harming competitors without regard to how their actions affect the community. This session focused on how to reconcile at a personal level being labeled as evil and how to act towards the community when conflict arises. I attended to learn how I can help Red Hat steer clear of making decisions that damage community trust in the name of short-term (or short-sighted) gains. The community is essential to sustainability. I pronounced that if the two became estranged (and I discovered myself working for an evil company), I would side with the community since that is where my reputation is most valuable.

    UPDATE: Simon Phipps, who hosted the session, shares its premise in his blog entry The Long Road To (Software) Freedom. In the entry, he suggests one model for the journey a company may take towards embracing software freedom. This model may be a valuable tool for community managers who work for large corporations at various stages of this journey and are often faced with the responsibility of fielding negative perceptions of their employer. For those of you working for software companies, how far along is your employer?

  • One Company Many Communities: What next?

    This session brought together individuals currently facing the challenge of managing multiple, often disparate communities within their company. Red Hat has several layers of this problem. The most obvious is the independent Fedora and JBoss Communities. Going deeper, there is a customer community and independent open source community in each camp (RHEL/Fedora and EAP/JBoss). When you look in the JBoss Community, you find a whole range of additional independent communities, struggling to remain linked through the infrastructure. Aside from reflection, the value I got out of this presentation is the acknowledgement that one size does not fit all and that the linkages must emerge and be fostered rather than forced on the communities like shackles.

  • Community as gasp Marketing

    This session explored the role between community managers and marketing. After sharing some stories, we all agreed that at some point, community managers wear a marketing hat. The question we tried to answer next was, to what degree? In small companies, the community manager and marketing may be the same role. In larger companies, there will no doubt be a dedicated marketing person or team. Regardless, the work the community manager does will touch on marketing and thus should have a relationship with the marketing team. As to whether the community manager is in the marketing or engineering department, that will vary from company to company. I certainly recognize that I engaging in marketing when I talk about the technology at conferences, plan software launches, select project logos and so on.

  • We Do Awesome: How we can communicate great work to managers and stakeholders

    This talk wrapped up the weekend with a discussion of how to communicate the value of the work we do as community managers to our company. We arrived at two tools, stories and metrics. Stories relay value through emotional and personalization. Metrics relay measurable impact. When using metrics, it's important to focus on relative change, not absolute numbers. I frequently use stories, but now I recognize that I need to balance them with metrics. I'll be studying the recent work done by David Eaves for the Mozilla community and David Neary for the Meebo community in this area.

After day 1, we got a real treat: a comedy stand-up routine that only a geek would truly appreciate by FLOSS geek and feminist Sumana Harihareswara (@brainwane). Geek out! The best things in life truly are free. HBO, eat your heart out.

FedoraJBoss.pngI was also thrilled to meet a colleague at the event, Adam Williamson, Fedora QA community manager/monkey. Although we didn't plan it (honest, we never met prior to that weekend), the event served as an excellent catalyst for building a bridge between our respective communities, Fedora and JBoss. We shared many stories, workflows and values. I'm amazed how many awesome people work for Red Hat. Hopefully we'll look back on this event as a key turning point for bringing together these surprisingly isolated communities.

UPDATE: Check out Adam's blog post about his experiences at the Community Leadership Summit.

Without a doubt, the event was very worthwhile, even more interactive than I anticipated. I definitely picked up some good advice and strategy for managing communities. Above all, I recognized how much I enjoy working in a community role and how much more I still need to learn and explore. This event is no doubt just the beginning.

There was some talk of organizing a CLS East in either New York or Philadelphia. I'm definitely interested in continuing the conversation about community leadership. I'd also like to encourage Red Hat to become a sponsor and send more employees to participate.

JBoss AS 7 banner

When asked in a recent interview what makes the release of JBoss Application Server 7 (AS7) significant, we replied,

"We are so excited about this software."

The reaction?

"You [JBoss] say that about everything."


But this release really is different. There's genuine excitement and optimism about AS 7 at Red Hat, which permeates deep into the community as well.

Now, I have a confession to make. I've never been a huge fan of JBoss AS. Despite using it quite regularly in development, production and trading, I always felt as though their was something better out there. My main gripes? Speed and compliance.

This is not really a big secret. While contributing to Seam 2 as a community member, I often focused on issues that dealt with running Seam on GlassFish, and frequently advocated for the combination. I echoed that recommendation in my book.

Act 1

When EE 6 went final, I again gravitated towards GlassFish because it was the only option available for running EE 6 applications, which I very much wanted to start educating developers about. GlassFish also started in under 10 seconds, which certainly helped. Can you blame me for wanting to cut out the putzing around?

Working on the Arquillian project has given me the opportunity to compare application servers more objectively, so as to backup my gut with some real data. I tracked the progress of AS 6 development using the Arquillian showcase. Each milestone unlocked additional tests, like levels in a game of Angry Birds.

But the birds were still angry because not all the standard EE 6 tests were working; that is, until the final release. I was excited about JBoss AS 6.0.0.Final because it was finally compliant...meaning it's a Java EE 6 Web Profile certified implementation and, for the most part, behaved with the element of least (unwanted) surprise. The startup speed had improved over AS 5, but still long enough to be annoying.

However, that honeymoon soon ended when the Seam team began preparing for the first release of the reincarnated Seam framework, Seam 3. We quickly discovered that classpath leakage, a fundamental problem that has long plagued AS 6, was interfering with the compatibility of CDI extensions. To make matters worse, GlassFish had the exact opposite problem. Despite having a more sound, modular architecture, it exhibited remedial classpath resolution problems CDI archives, in addition to other emerging compliance issues. At times, I was beginning to lose my faith in the viability of the Java EE application servers.

Enter AS 7...

And then JBoss AS 7 came along. It wasn't love at first sight, but let's call it love at second sight on the 'Ides of March'. I can now say with confidence that AS 7 is the first JBoss AS line I've ever loved. What's more, I believe it's the best Java application server ever made. It's downright incredible. Its superior quality compelled me to join the release team, advocate for it and to take that message to my audience by speaking about it. My wife even got involved in polishing the communication and and crafting an engaging slide deck (7 reasons to love AS 7).

7 reasons to love AS 7 title slide

Why all of a sudden do I like, or rather love, JBoss AS? We'll, the answer is simple, really. I want to use the best option available. I look at several factors when evaluating and application server:

  • Speed
  • Compliance
  • Performance
  • Handling

AS 7 is not merely a progression, but a complete departure from the JBoss AS legacy of problems. It has been redesigned from the ground up as a highly tuned, modular server in order to deliver on these requirements, and many more. That's the only way it could move forward, and shoot so far out in front of the pack.

Speed iconSpeed


AS 7 is #@*%ing fast. It shatters the competition and my expectations. See the results (record time: 700ms). Easy win there.

Compliance iconCompliance

AS 7 is Java EE 6 web profile certified (Full profile certification is slated for 7.1). That's a start, but robustness is a constantly evolving goal. The integration test suite for AS 7 is based on Arquillian, which means it consists of real tests, and those tests are easy for anyone to run in their IDE. If a problem comes up, we have a common language for demonstrating the scenario and easily collaborating with the community of developers and users on a fix. And, of course, all those Arquillian showcase tests pass too

I'd like to give a shout out to Andrew Rubinger for structuring the testsuite, to Thomas Diesler and Aslak Knutsen for evolving the AS 7 container adapter and to Stuart Douglas for being a test writing machine. In the end, credit goes to all for a group effort. Tests are engineering rigor of this application server. Run them proudly!

Compliance also means a clean environment. The modular classloader keeps applications isolated, so you can use your own XML parser or Hibernate libraries without experiencing classloader hell. You also don't slip into depending on internals of the application server, such as non-public APIs and libraries. The modular structure steers you clear of compliance issues not covered explicitly by the TCK.

Performance iconPerformance

AS 7 takes and aggressive approach to memory management, leaving plenty of headroom for the application. It should not get slower over time, no matter how many deployment cycles you throw at it. It avoids the use of reflection internally, uses indexes to lookup classes and annotations quickly and keeps applications isolated, all which contribute to the performance boost.

Handling iconHandling

Finally, AS 7 is incredibly easy to configure. You can control a single server in isolation or many servers using a domain controller. In both cases, the configuration is centralized in a primary configuration file (with one secondary configuration when using the domain control). Just as an example, you can change all the port numbers using a single attribute. There are four ways to change settings, including a cli for geeks and scripts, and a super fast web console for the more casual and visual users. I'm also relieved that deployments are the only files that belong in the deployments directory. Finally!

Bring it.

I'm not ashamed to say I'm a fanboy of JBoss AS 7. Label me. It certainly deserves the acclamation. It's the application server we've all been waiting for and certain deserves the acclimation. Hats off to Jason Greene, the AS 7 team and our awesome community. It's only going to get better from here.

For those of you who are Red Hat customers, EAP 6, which is being built on AS 7, is going to be awesome too. That's a product we can be so proud of having in production environments.

Discover all 7 reasons to love AS 7 and download AS 7 for free! Then, watch the webinars and tell us what you love about AS 7 (Use hashtag #JBossAS7).


Experience the speed!

jax-jsf-summit.pngJAX, a popular European conference brand, is traveling to the US under the moniker JAXConf. It will be hosted in connection with JSF Summit next week (Jun 20 - 23) in San Jose, CA. And a JBoss storm is colliding with it full force!

If you're attending, you'll have plenty of opportunity to learn about Java EE 6, CDI, JSF and a plethora of JBoss technologies (Seam 3, Weld, RichFaces, JBoss AS 7, Forge, Drools, OpenShift and Ceylon) from our clan of speakers.

Here's a quick peak at our line-up:

Dan Allen & Lincoln Baxter III

  • Java EE 6 secrets: Wield CDI like a Ninja Master
  • Forge new Ground in Rapid Enterprise Java Development

Dan Allen

  • Seam 3 brings Java EE improvements of tomorrow, today (@ JSF Summit)
  • The future of Java enterprise testing
  • 7 reasons to love JBoss AS 7 (@ JBoss Day)

Lincoln Baxter III

  • Beautiful Java EE: URL-rewriting for the next generation web-user (@ JSF Summit)

Jay Balunus

  • RichFaces 4.0 Component Deep Dive (@ JSF Summit)
  • The Mobile Web Revealed For The Java Developer (@ JBoss Day)

Brian Leathem

  • CDI and Seam Faces realize the full potential of JSF (JSF Summit)

Tihomir Surdilovic

  • LAB: BYOL (Bring your own laptop): Apply JBoss Drools and CEP to your application (@ JBoss Day)
  • JBoss Drools and Drools Fusion (CEP): Making Business Rules react to RTE (@ JBoss Day)

Tobias Kunze Briseño

  • Cloudy Innovation: Platform-as-a-Service and Open Choice

Gavin King

  • The Ceylon Language Module

Ales Justin

  • Java EE on Google App Engine: CDI to the Rescue!

Many of our community friends will also be speaking, including Matthew McCullough, Andy Schwartz, Daniel Hinojosa, Max Katz, Kito Mann and, well, too many more to mention. It's a solid line up! Check out the speaker list for a full list of sessions.

jboss-jax.pngIf you're not attending, but in the area, check your schedule! We're sponsering the JBoss Day event that anyone can attend for free! Just sign up!

I'll kick off the afternoon and we'll launch into talks on mobile web development, Drools, AS 7 and more. Don't miss it! Come geek out with us!

The biggest news is that the first candidate release of JBoss AS 7 is slated to strike ground midweek, so be sure to attend JBoss Day or visit the JBoss booth (#313) to learn what makes it so electifying! At the booth you can also learn about the upcoming EAP 6 from Jason Andersen and Ashesh Badani.

Also drop by the JBoss booth to meet the OpenShift team to get your app into the cloud. OpenShift is a PaaS for developers who love to build on open source, but don't need the hassle of building and maintaining infrastructure. Bring your language of choice!

See ya in the Golden State! If you can't make it in person, we invite you to follow @JBossNews on twitter. Look for the hashtags #jaxconf and #jbossas7.

Right on the tail of the first alpha, Seam Servlet 3.0.0.Alpha2 has been released. Why the quick turnaround? Because we wanted to put two features in your hands so you can take control of that request.

  1. The ServletRequestContext lifecycle object
  2. Initial Seam Catch integration

The first feature let's you control the beginning of the request more easily. The second allows you to handle the tail of the request if bad $#*! happens.

If filters were events

While examining the Servlet API to determine what enhancements to make, I realized that it offers only a hodgepodge of lifecycle events. You get an event when the request is initialized, but no matching event for the response. You have to resort to using a servlet filter to access the response at the beginning of the request. But then you have to worry about whether you are handling an HTTP request and about managing the filter chain.

In the first alpha, I added a synthetic event for when the response is initialized and destroyed using a built-in filter. You can listen for this event using a CDI observer:

void onResponseInitialized(@Observes @Initialized ServletResponse response) {
   response.addHeader("Cache-Control", "no-cache");

You can even inject the request object into the observer method so that you can access both the request and the response:

void setEncoding(@Observes @Initialized ServletResponse res, ServletRequest req)
      throws Exception {

While this is a start, I thought of a few enhancements that would really make this ring:

  1. Group the request and response in a type together
  2. Short-circuit the request if the response is committed by a listener
  3. Allow the listener to observe a specific servlet path

Wrapping the request and response together was a no-brainer. One parameter is better than two. So I created the ServletRequestContext to provide access to the following implicit objects:

  • ServletRequest
  • ServletResponse
  • ServletContext

I also created its HTTP-counterpart, HttpServletRequestContext, which provides access to these objects:

  • HttpServletRequest
  • HttpServletResponse
  • HttpSession
  • ServletContext

These two objects can also be injected into any managed bean during the request.

We can now simplify the character encoding listener from the listing above:

void setEncoding(@Observes @Initialized ServletRequestContext ctx)
      throws Exception {

So far, we've only been considering listeners that contribute to the response. But what if you want to commit the response, such as send an HTTP error response or redirect to another page? With Seam Servlet, you can!

Here's a basic example showing a welcome page filter that redirects to a start page if the root URL is requested.

void redirectToStartPage(@Observes @Initialized HttpServletRequestContext ctx)
      throws Exception {
   String servletPath = ctx.getRequest().getServletPath();
   if (servletPath == null || servletPath.length() == 0 || servletPath.equals("/"))
      String startPage = ctx.getResponse().encodeRedirectURL(
      ctx.getContextPath() + "/start.jsf");

You also now have the option of associating the listener with a specific servlet path, in this case the context root, using the @Path qualifier:

void redirectToStartPage(@Observes @Path("") @Initialized HttpServletRequestContext ctx)
      throws Exception {
   String startPage = ctx.getResponse().encodeRedirectURL(ctx.getContextPath() + "/start.jsf");

You never have to write a Servlet listener, Servlet or Filter again!

When bad $#*! happens

Exceptions are a fact of life. As developers, we need to be prepared to deal with them in the most graceful manner possible. The Servlet API only gives you limited options for doing so:

  • send an HTTP status code
  • forward to an error page (servlet path)

To squeeze you into a tighter corner, you have to configure these exception mappings in web.xml. It just doesn't make this task easy. We have something that does.

Seam Catch provides a simple, yet robust foundation for modules and/or applications to establish a customized exception handling process. By employing a delegation model, Catch allow exceptions to be addressed in a centralized, extensible and uniform manner.

That sounds good, so how do you make use of it? That's where the Catch integration in Seam Servlet comes in.

When the request goes south (i.e., an unhandled exception occurs), and both Seam Servlet and Seam Catch are on the classpath, the exception will be caught and forwarded to your exception handler methods. How you deal with the exception from there is up to you.

Here's how you send an HTTP error response with a friendly message for any unhandled exception that occurs:

public class ExceptionHandlers {
   void handleAll(@Handles @WebRequest
         CaughtException<Throwable> caught, HttpServletResponse response) {
      response.sendError(500, "Sorry things didn't work out the way you expected."); 

The @WebRequest qualifier distinguishes this exception handler from one that might apply to a JAX-RS request. (It will be optional in a future release)

Let's add another handler that sends a 404 response when the application-specific AccountNotFoundException is thrown.

void handleAccountNotFound(@Handles @WebRequest
      CaughtException<AccountNotFoundException> caught, HttpServletResponse response) {
   response.sendError(404, "Account not found: " + caught.getException().getAccountId()); 

Since you have access to the response object, you can send any sort of response you want to the browser. The next release of Seam Servlet will provide handler annotations so you can configure these two responses above declaratively. Stay tuned!

Get started!

As with all Seam 3 modules, the Seam Servlet module is published to the JBoss Community repository. Here's the dependency declaration you need to add to your POM to include this module in your project:


If you're not deploying to JBoss AS, you also need JBoss Logging (a portable logging abstraction):


There's plenty more features to explore in Seam Servlet, and more to come, so check it out!

[ Module Overview ] | [ Download Distribution ] | [ JIRA ] | [ Reference Guide ]

Never write a Servlet listener again! After all, who wants to implement container interfaces? With the Seam Servlet module, you no longer have to!

Servlet event bridge

The first alpha release (3.0.0.Alpha1) of the Seam Servlet module brings deeper integration of CDI and the Servlet API. The integration kicks off by channeling Servlet lifecycle events to the CDI event bus. That means you can use simple CDI observer methods to respond to Servlet lifecycle events, such as the request initialized event. You listen for the exact event you are interested in with no additional configuration necessary.

Here's a basic example that prints the User-Agent that issued the request:

public class UserAgentPrinter
   public void printUserAgent(@Observes @Initialized HttpServletRequest request)
      System.out.println("Request issued by " + request.getHeader("User-Agent"));

Perhaps that doesn't impress you much (if so, great). There is a golden egg hidden in this bridge.

Application initializers

Put away those startup singletons you're so excited about. You don't need them. The Servlet context initialized event is much better suited for application initialization routines. Since the observer is a CDI bean, you can inject anything you might need to get setup. Even better, the bean can be configured to be released as soon as the setup routine is complete by making it dependent-scoped (the default). In contrast, when you use a startup singleton, it hangs around for the lifetime of the application.

Here's the classic case of inserting seed data into the database when the application is starting up:

public class SeedDataImporter
   private EntityManager em;
   private UserTransaction utx;
   public void importData(@Observes @Initialized ServletContext ctx)
         throws Exception
      em.persist(new Product(1, "Black Hole", 50d));

Or better yet, just make it an EJB:

public class SeedDataImporter
   private EntityManager em;
   private UserTransaction utx;
   public void importData(@Observes @Initialized ServletContext ctx)
         throws Exception
      em.persist(new Product(1, "Black Hole", 50d));

If you don't want to tie your code to the Servlet API, you have the option of observing WebApplication, a value object provided by Seam Servlet:

public void importData(@Observes @Initialized WebApplication webapp)
      throws Exception { ... }

Injection galore

Seam Servlet also exposes the implicit Servlet objects, such as ServletContext, ServletRequest (and its HTTP counterpart) and HttpSession, as appropriately-scoped, injectable resources.

Here's an example of how you inject the HttpServletRequest:

private HttpServletRequest request;

There's one important implicit object that's been left out, the response. Since the Servlet API does not raise lifecycle events for the ServletResponse (and its HTTP counterpart), Seam Servlet steps up and emulates the lifecycle events for this implicit object using a Servlet filter. That gives you access to the response object in a lifecycle observer! Here's an example that sets the character encoding on the request and response:

public class CharacterEncodingSetup
   public void setup(@Observes @Initialized ServletResponse req, ServletRequest res)
         throws Exception

You can also access the response through injection, as shown here:

private HttpServletResponse response;

In addition to implicit objects, Seam Servlet also allows you to inject contextual HTTP state; in simpler terms, request parameters, headers and cookies. As you would expect, you can inject these values as strings.

// retrieves the value "chocolate" from query string ?flavor=chocolate
@Inject @RequestParam @DefaultValue("vanilla")
private String flavor;

Leveraging a feature from Weld Extensions (Seam Solder) known as a "narrowing bean", Seam Servlet can also inspect the type of the injection point and convert the value to that type before performing the injection.

// retrieves the long value 9 from query string ?id=9
@Inject @RequestParam("id")
private Long bookId;

Finally, Seam Servlet addresses a bit of a pain point in CDI: accessing the BeanManager.

Easy BeanManager access

When the code you are writing is inside of a bean (or other resource) managed by CDI, you can access other beans or the BeanManager using some form of injection. There are scenarios where you are starting outside of this managed environment and you need a way in. According to the JSR-299 specification, that way in is through a JNDI lookup. Did that make you cringe?

The fact is, JNDI isn't universal or consistent across all popular deployment environments (think Tomcat and Jetty). To level the playing field, Seam Servlet binds the BeanManager to the Servlet context attribute javax.enterprise.inject.spi.BeanManager (the fully-qualified class name of BeanManager). Now you have two ways to find the BeanManager, the later being ideal for Servlet applications.

If you want to hide the lookup completely, you can use the BeanManagerAware super class or a static method on the BeanManagerAccessor class to obtain a reference to the BeanManager. Under the covers it will consult this Servlet context attribute, amongst other lookup strategies.

public class NonManagedClass extends BeanManagerAware
   public void fireEvent()

Get started!

As with all Seam 3 modules, the Seam Servlet module is published to the JBoss Community repository. Here's the dependency declaration you need to add to your POM to include this module in your project:


If you are not deploying to JBoss AS, you will also need JBoss Logging (a portable logging abstraction):


At the moment you cannot use Seam Servlet on GlassFish because several of the extension points used by Weld Extensions (Seam Solder) are not functioning correctly on GlassFish. This is an issue that affects most Seam modules at the moment, though you can expect a resolution soon. See GLASSFISH-14808 and related issues.

There's plenty more features to explore in Seam Servlet. The next major addition, coming in Alpha 2, is CDI-based exception handling through integration with the Seam Catch module. Check out the Seam Servlet module page or issue tracker for more details (links below).

[ Module Overview ] | [ Download Distribution ] | [ JIRA ] | [ Reference Guide ]


Speaking at Utah JUG

Posted by dan.j.allen Oct 20, 2010

I'll be speaking at Utah JUG on Thursday, Oct 21 about CDI, Seam 3 and Arquillian. I'll also get a chance to meet for the first time in person one the Seam 3 community developers, Jason Porter. Jason works on Seam Catch, the exception handling process based on the CDI event bus.


Here's the abstract for my talk. Hopefully the whimsical title will convince you all to come out


CDI and Seam 3: What's the story and how do I test it?


In the first of this two-part session, Dan will provide an overview of Seam 3, a powerful Open Source development platform for building rich Internet applications in Java EE.


The talk begins with an overview of JSR-299: Contexts and Dependency Injection for Java EE (CDI). CDI is the new core programming model in both Java EE 6 and Seam 3 and therefore the most prominent aspect of this stack. It provides services for managed and enterprise beans that include dependency injection, contextual life cycle management, interceptors and event notification. It also includes an extensible SPI for developing additional portable functionality and customization, a key enabler for Seam 3.


Seam 3 extends the CDI programming model by providing portable enhancements, extensions and integrations that tie together technologies within and beyond the Java EE platform into a full-stack solution, complete with tooling. You'll discover how this stack is used to address common business concerns and then look ahead at what else is on the menu for Seam 3.


After the whirlwind tour of CDI and Seam 3, we'll ask the question "How do I test this stuff?" That's where Arquillian comes in.


Arquillian is a container-oriented testing framework, layered atop TestNG and JUnit, that brings your test to the runtime rather than requiring you to manage the runtime from your test. In doing so, it provides the missing link in enterprise Java development: simple, portable integration tests. We'll walk through example after example until the sun goes down so you can see that Arquillian is the future of enterprise testing, and there's no limit to what you can test with Arquillian in your toolbox.


See you there!

Even if given days of preparation to draft a written response, I don't think I could have answered this question more clearly than Pete Muir, lead of the Seam and Weld projects, does in the following interview. This interview was given by Java Magazin author Michael Schütz at JUDCon Berlin 2010.


Seam 3 interview with Pete Muir


I pulled out a couple of quotes to highlight here, but there's plenty more where they came from.


On the perspective Pete brings to Seam:


I'm a great believer that what makes a good framework developer is really understanding the problems the framework solves.


On how Seam 3 related to CDI:


Think of CDI as the core of Seam 3 - it's the basic programming model for your application components.


On how Seam 3 is structured:


Seam 3 is implemented as a set of portable extensions (modules) for JSR-299 that run in any environment which supports JSR-299.


On community participation:


We encourage contributions from anyone in the community who wants to develop a new module for #Seam 3 (just get in contact!)


I'll add that I thoroughly enjoy working with the community and seeing the exhilarating impact a great idea can have on the group.


On the prospect of a CDI extension directory:


We also moderate a social bookmarking group where anyone can link to a #CDI extension.


On life after JSF:


Coming up, we'll start to see GWT really take its place as a first-class option for writing your view layer. The GWT integration for Seam 3 will focus heavily on integration with Errai.


A lot of pieces had to come together for Seam 3 to take shape. Those pieces are finally aligning and, now that the source has been switched over to Git at, things are going to get heavy.

During my long flight to Frankfurt last month, I responded to an interview by asiandub about Seam for the German Java Magazin. In the interview, I reflect on the value of Open Source, how I got involved in Seam and where we are headed with Weld and Seam 3. I ended up writing so much (surprise, surprise) it had to be split into two parts. I justify my thoroughness in my first response:


I'm going to be a little long-winded [...], but I think it's important to communicate what led me to Seam because it says a lot about the software itself.


The full, 2-part interview is available online at the JAXenter Magazine website:



In part 1, I share the thoughts I had after reading the Seam reference documentation the first time:


It's like the Seam developers were reading my mind. [...] 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 go on to explain that it wasn't just enough for me to know about it. I wanted other to benefit too.


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 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.) [...]


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.


I squeeze in a short review of the Art of Community at the end of the first part because it really sums up my vision of this project:


The Art of Community is a truly inspiring book and it reminded me why I love doing what I'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.


Part 2 dives more into the technical details and where we are headed.


CDI and Seam 3 are the Future of Both the Seam Community and Red Hat.


I explain our standards strategy as a defender of choice:


Red Hat is strong when the Java EE platform is strong. Our strategy does not depend on the platform remaining weak to justify the existence of our projects. It's quite the opposite. If we make one of our own projects obsolete, or some part of it, that's progress.


To quote jbalunas, it's cyclic:


Find a void. Fill the void. Standardize the fill.


I liken Seam modules to JSF UI component libraries and explain how we will ensure portability:


  1. Seam 3 is primarily built on the CDI portable extension SPI, insulated from handling low-level concerns that run a high risk of breaking portability.
  2. One of the principal requirements of Seam 3 modules is portability.
  3. The Arquillian in-container test framework allows modules to be continuously tested against an array of application servers.


But with the improvements to Java EE, the question comes up whether Seam is still needed:


Is Java EE 6 a solid platform? Yes. Will you still need extensions? Yes. And CDI was designed specifically to be able to root and foster such an ecosystem. You can even write your own extensions, which really wasn't possible with Seam 2. Now we just need a plug-in site


I'm very excited about all the innovation that is taking place in the JBoss Community right now and I encourage you to become a part of it. You never know where it will lead, but I can guarantee you it will open doors for you.

I received an e-mail from a buddy informing me of a likely, but involuntary, job transition. His situation made me recall a primary reason I prefer to work on Open Source projects: Free will.


The funding from our grant will run out at the end of the month and therefore my employment is a bit uncertain at the moment. Many forces are working hard to secure more funding, so I don't know when my last day will actually be.


It can be frustrating when you invest a lot of time, energy and creativity into software project, only to find out one day that you can't work on it anymore, either because your contract has expired or the funding for the project runs out. While you earn plenty of paychecks and experience from the project, what do you really have to show for it? You're forced to walk away without your creation, left only with memories (and whatever code you managed to transfer to that flash drive).


Of course, we all have to make a living, so working on proprietary or internal software projects is inevitable--some may even say a necessary evil. I've been in jobs where I felt like one brain in large matrix that feeds the company's information technology. But a job is a job. The company is paying you for your work, so you should certainly work hard if you value your career.


But you don't have to leave it all behind when it's time to move on.


Reserve your most passionate work for something you can control. In my talks, I often encourage developers to go home and create an application for themselves. It's yours for life and you can design it however you want. But there's something even more satisfying than working on software alone - working on it with others.


Why not get involved in an Open Source project so you can collaborate, share ideas, build reputation within a community and learn from each other? What you end up with is something you collectively own that's likely better than anything you could create by yourself. More importantly, you can show your contributions to anyone at anytime.


While you may be forced to let go of your investment in a company's software project, no one can take away your open source contributions. Your contract with Open Source never runs out.

A fellow remote employee (remotee) at Red Hat recently sent a message to the remote employees mailinglist with the subject Team Building. In the e-mail, he laments about the day a fellow team member left the company whom he had never met.

A member of my team is leaving after 20 months, a fellow remotee based in Colorado. I've never met him. As far as I know he only met two of his immediate co-workers: his manager and another engineer on our team who was hired at the same time. They met during orientation in Raleigh. He never went anywhere else during his tenure.


I haven't been to any Red Hat office in 16 months and counting.


I hate contrived team building. I don't really care what personality type I am, don't want to see if I'd end up on my butt in trust fall and most of all don't want to be in anything resembling a skit. But it sure would be nice to sit with my team once a year or so.


Are other remotees feeling disconnected as well? Have you been to the new Westford office in the last year? Did you even know it moved in 2008? Do you know what your team members look only only because they've received a Service Award?


This story prompted me to answer two questions I'm often asked:

What is it like to work remotely? How do you manage to stay connected?


I'll share how my team has dealt with the distance and how I've managed to maintain personal connections.


I work out of my house in Maryland on a team (Seam, Weld, Arquillian) that, like many of the teams at Red Hat, is extremely diverse geographically. We may even be one of the most diverse teams, and I count community members as part of my team as well. No two team members live in the same city except for our QE guys (Brno). We represent more than a half dozen countries and we're spread across most of the world timezones (no matter when we schedule a meeting, someone is up in the middle of the night; on the other hand, it's always 5 o'clock somewhere cheers_hat.gif). To put it simply, there are oceans between us.


That is so cool.


I consider myself fortunate because I do get to meet the members of my team regularly. That's because most of us are speakers. So where we meet up is at conferences. It's quite a thrill when you get to meet someone for the first time in person that you've communicated with online.


At Devoxx 2009, Seam had it's annual team meeting right alongside the conference, bringing everyone together in Antwerp, Belgium. At that point, I already knew the team very well (though I did meet some new faces). The main reason was because the previous Seam meeting was at a Tuscan farmhouse in rural Chiusi, Italy, in almost complete isolation. It was sort of like a retreat. I believe that conversations I have with the team today, nearly two years later, are still influenced by the interaction we had that week. When compared to the conference meetings, well, the retreat doesn't even compare.


My take on these meetups is that a single face-to-face meeting can keep you "connected" for several years. That's because it gives you an image in your head. All IRC chats, phone calls and e-mails that occur after that point are with people, not just with handles, addresses and voices. There's just no way to replace that experience.


It's important is to keep that image fresh in your mind, though (no, this is not a vanity contest, it's about knowing the real person...the expressions, movements and yes, the hair and face). To get that refresher, I recommend video chat. I meet with my managers and teammates from time to time on video chat and frankly, I think it's almost as close as being there. (If you want to get a real sense of how far this might go someday, rent the movie Up in the Air).


Another tool that helps establish the human interaction is for all the team members to maintain personal profiles on internal or community sites. For me it's JBoss Community (dan.j.allen). A picture and a short bio go a looooong way to connecting with a person.


Finally, a great way to connect with other employees, even if you can't connect with your teammates, is through local user groups. I'm researching getting a DC JBoss user group off the ground. Sometimes, it just feels good to feel good about your company and maybe hear the names of colleagues mentioned, even if you can't meet them. It's also a good way to discover people that are local, without the lameness of trying to figure out what to do together, or keep a colleague's butt from hitting the ground in a trust fall.


In summary, here are the ways I recommend to stay connected while working remotely:


  • Get together at annual or biannual team meetings: good, especially when away from distractions
  • Attend conferences where you can meet teammates and managers; speaking makes it cheaper
  • Video chat with teammates or managers
  • Follow community profiles (I think all employees should try to interlink in a "social network" and there should be lots of picture sharing)
  • Join local user groups


When you work remotely, there's always that chance of a team member joining and leaving without ever getting to meet that person. But that's far outweighed by the flexibility to work from wherever you want and to learn about people who live in different parts of the world than you. And what I like the most is that it gives you an opportunity to travel. The way we work is changing. But that doesn't mean we have to lose touch.

Filter Blog

By date:
By tag: