Enterprise grade Java.
You'll read about Conferences, Java User Groups, Java, Integration, Reactive, Microservices and other technologies.

Monday, April 30, 2012

JavaOne 2012 Analysis - Submitted Proposals and Speaker Distribution.

07:41 Monday, April 30, 2012 Posted by Test No comments:
, , ,
Beginning some time last year I started to have a closer look at conferences and their speakers. My main interest was to find out who was speaking how often. One conference was missing in this analysis because I really was not sure what can be published without breaking the confidentiality of the information. Being a member of the program committee for the second time this year and seeing all those wonderful sessions forced me to take another look at it and finally today I have at least some percentages to show to you. A big thank you goes out to Oracle's Sharat Chander for giving the permission to do that!
Based on the complete data for what has been submitted to JavaOne 2012 in San Francisco I will let you have a look at types, distribution and speakers. Every number given here is a percentage and the numbers behind them are still confidential. And again: This is an analysis of the complete submitted data. This doesn't tell you anything about what is going to be selected! The voting is still ongoing and the different program committees are hard at work reviewing every single proposal.

Submission Types
First of all let's look at the general distribution of submitted types independently of any track. Speakers could select any of five different types for their submission. The classic session, a BoF (Birds of a feather) a tutorial, a HoL (Hands on Lab) and for the first time this year a community keynote.
Not a big surprise that most of the submissions are sessions (70,14%). Second most proposed content are BoFs. Followed by tutorials, HoLs and some community keynote proposals. Even if this sounds very concrete, there is still some motion in here. Some BoFs might become sessions and the other way around.

Submission Types
Submissions per Track
Next most interesting figure is the general distribution of submissions per track. Seven tracks are there to chose from. Starting with the Core Java Platform and finishing with Java on Card and Devices. It is good to see a very evenly distributed number of proposals for every track. Lead by the Development Tools and Techniques track (24,15%) both Java ME, Java Card Embedded and Devices (8,21%) and Emerging Languages (5,86%) are the bottom end. Very few proposals are moved around from track to track during the voting process but it happens. I don't expect the final distribution to differ heavily from the one shown below.
Distribution per Track
Internal vs. External Submissions
The no 1 question discussed a lot in the past is the number of sessions given by Oracle employees. even if I would love to make an educated guess here, anything I can show you is the distribution with regards to the proposals. I have looked at the first speaker of every session and assigned it an internal or external flag (yes, that took some time ;)). More than 2/3rd (71%) of the submissions come from external (aka non-Oracle) speakers. Even if I have seen some combined proposals also this is a clear sign, that JavaOne is a community driven conference.
External vs. Internal Speakers
But where exactly is Oracle jumping in? Are there differences in submissions per track if we look at the internal speakers? Internal proposals have a stronger focus on Embedded Java, the Core Platform and JavaFX compared with the external submissions.

Submission Distribution by internal speakers

Submission Distribution by external speakers
What do we learn from all that? JavaOne is going to be a great, community driven conference with a lot of awesome sessions to come! If you haven't done so take a look and register for it! The final program is going to be announced in a few weeks and there still is plenty of time to find a flight and a hotel near by.

Friday, April 27, 2012

Thank you! I'm a JBoss Community Leader 2012!

06:56 Friday, April 27, 2012 Posted by Test 2 comments:
, , ,
Huge news yesterday: The voting for the JBoss Community Recognition Award has been closed and the final winner have been announced! And I won the documentation category! A big thank you goes out to everybody who voted for me. It's a real pleasure working with the JBoss Arquillian Team and I have to thank Aslak, Dan, Vineet and Lincoln for supporting me since my early tries with Arquillian (beginning in late 2010).

There are a couple of reasons I am proud to receive this award. First and foremost I enjoy being part of the broad Java EE ecosystem. Seeing the JBoss guys doing their work with joy and passion is a big proof that standards and the JCP in general are anything but boring. Java EE and the supporting technologies deliver a pool of knowledge and creativity to make life easier for every developer.

Second most important reason is, that it shows how you can contribute to open source successfully or more general to the technology you admire without contributing code. There are a couple of reasons which prevent me from contributing code to OSS. But as in one of my favorite slogans: "Power is nothing without control", code is nothing without documentation. But you don't have to be a rock star programmer or genius to push things. Providing guidance and tutorials, articles ... all that kind of stuff is at least equally important when great software comes to the masses. (Some product documentation still shows this day by day.) Given the fact that this blog and even some magazine articles are written in English forces me to also thank my former English teachers for transforming a D student into someone being able to express his thoughts reasonable.

You probably know me as an Oracle/GlassFish/WebLogic advocate, so the third and last reason for being proud is that it is possible for a guy like me to receive a JBoss award. If not that, what else could be a better proof for a big and working technology family. Even if the kids pick on each other from time to time work and play is fun for everybody.

My congratulations go out to the other winners:
Esteban Aliverti - New Features Drools (@ilesteban)
George Gastaldi - Bug Fixes Seam (@gegastald)
Bartosz Majsak - Issue / JIRA Arquillian (@majson)
Hantsy Bai - Wiki Arquillian

Hope to see you soon at JUDCon 2012 Boston June 25th and 26th when I am awarded! Thank you!

Tuesday, April 17, 2012

German Article about Arquillian.

08:29 Tuesday, April 17, 2012 Posted by Test No comments:
, , ,
A short reminder for my German readers. Heise.de Developer Channel published an updated version of my Arquillian article from last year. It now covers the new features from 1.0.0-Final and also introduces you to use the Drone Extension with Selenium to do some very basic UI tests.

The good news is that this is available for free. The bad news: It's only available in German. But don't forget to visit the new arquillian.org for latest guides and how-to's to get you started in many many other languages.

If you still need more information check out the complete Reference Guide for the Arquillian project. Or the FAQ.

Wednesday, April 11, 2012

Arquillian 1.0.0.Final released! Ready for GlassFish and WebLogic! Death to all bugs!

09:12 Wednesday, April 11, 2012 Posted by Test No comments:
, ,
Red Hat, Inc. and the JBoss Community today announced the 1.0.0.Final release of Arquillian, its award-winning testing platform built to run on the Java Virtual Machine (JVM). Arquillian substantially reduces the effort required to write and execute Java middleware integration and functional tests. It even enables test engineers to address scenarios previously considered untestable or too expensive to test.

The 1.0.0.Final release of Arquillian Drone, a key add-on to the platform, is included in this release. Final versions of select container adapters will be released later in the week. ShrinkWrap, a key component of Arquillian, announced its 1.0.0.Final release last week.

Arquillian originated from the test harness developed for the CDI 1.0 (JSR-299) specification in 2009. It spun off as an independent project and has evolved into an extensible testing platform. Coming full circle, the test suite in CDI 1.1 (JSR-346), the next iteration of the CDI specification, has migrated to Arquillian. Other specifications are expected to follow. Arquillian is also used by numerous open source projects, including Hibernate, JBoss AS 7, Drools, RHQ, JClouds and Apache DeltaSpike.

Newest features
Arquillian can manage more than a dozen container vendors, including JBoss AS, GlassFish, WebLogic and Tomcat, and supports running tests in cloud services. The container support allows developers to target a variety of technology platforms, including Java EE 5 and 6, Servlet environments, OSGi, Embedded EJB and standalone CDI. Additional new features include: Orchestration of multiple deployments across multiple containers and domain controllers in a single test Descriptor deployment Assertions for deployment exceptions A new configuration schema that supports multiple configurations per container EL-like evaluation in properties and configuration overrides via Java properties Configuration of protocol used for test execution Explicit ordering of test methods Fine-grained control over the container lifecycle Arquillian’s extensibility is reflected in its growing ecosystem of extensions. The most mature extension, Arquillian Drone, is included in today’s release. Drone is an abstraction over browser controllers such as Selenium and WebDriver that enables the developer to write browser-based tests without having to fuss with the typical setup and plumbing. Other extensions under active development include an Android test controller, DBUnit integration, a SeamTest replacement for testing Seam 2, BDD runners (Spock and JBehave), performance metrics, code coverage (Jacoco) and Arquillian Graphene (a type-safe Selenium API). Expect more extensions to emerge now that the platform has reached a stable release.

GlassFish embedded and managed containers
The complete support for both embedded and managed/remote GlassFish instances is ready and has been updated to 3.1.2. And also latest WebLogic 12c is supported!

How to get it?
The Arquillian platform and extensions are available in the Maven Central and JBoss Community artifact repositories. For a brief overview about what it takes to get your GlassFish project up and running with Arquillian have a look at some of my recent blog posts about it!

The Arquillian project hosts a couple of guides in different languages to get you started. See the complete Reference Guide for all the details. Arquillian is released under the Apache License, v2.0.

Thursday, April 5, 2012

5 Ways to Contribute to GlassFish without being a Programming Genius

10:09 Thursday, April 5, 2012 Posted by Test 5 comments:
, ,
Andy Lester posted the original guide about 14 Ways to Contribute to Open Source without Being a Programming Genius or a Rock Star back in March and I really liked the idea. And this is why I decided to adopt this post a bit and tell you how and what you could do to support your favorite Appserver and technology.

Ask not what GlassFish can do for you, but ask what you can do for GlassFish! (freely adapted from John F. Kennedy)

First of all: Don't be afraid!
If you are reading this, you probably have the feeling that you could find some useful information about how you could start contributing. But you might also feel the fear about: Not being good enough at programming; don't have enough time; generally don't feel that my view on things is the right one ... and many many other things. At least to me those voices are always there. And I assume you know about them yourself. As Andy already pointed out in the original post:
We’re just people who get stuff done. Sometimes we do a little, and sometimes we do a lot. Sometimes it’s programming, and sometimes it’s not. (Andy Lester)
And that is true. Most Open Source Software projects in general and GlassFish and Java EE 7 especially are well set up and have build a huge ecosystem around which makes it possible to contribute on many many different levels of experience. So, you don't have any excuse for not contributing. Let's look at what could work for you:

Prepare yourself - Get up to speed!
GlassFish and most of the Java EE RI projects have a comparably long history. For example Sun Microsystems launched the GlassFish project on 6 June 2005. With the beginning of the Java EE 5 specification it is the anchor and reference implementation for Java EE specifications on the JCP. Unless you are deeply involved with what happened in the past you should make yourself familiar with the project teams, the sub-projects, the main developers and the tools they have in place. This is a lot of reading and listening at first. But it is very helpful for your further involvement. A good place to start reading are the Principles of the Project GlassFish Community. They are part of the overall GlassFish Wiki which keeps information about upcoming and past releases and also a lot of detailed information around the teams, building, developing, testing and using GlassFish. It honestly isn't completely updated. You will have trouble following all links but most of the stuff there is relevant.
Another good idea is to follow the main blogs from the GlassFish community. First and foremost this is The Aquarium. The editor-in-chief is taking care of the community and spreads the word about other useful resources and blogs out there. And you are obviously already following at least one other GlassFish related blog ;)

Review, Suggest and Add Documentation!
Documentation is a good place to start contributing. Find broken links, suggest new documentation. All you need to contribute in this area is to closely follow the Documentation Community. Contact the documentation team via eamil to get started or simply review some of the stuff that is out there. It's also a good idea to subscribe to their mailing-list (docs@glassfish.java.net). There are plenty of different sections here. You can work on FAQs, Translate them, write and translate How-Tos and tutorials, do videos and screencasts. And to stress this a little more: The whole community is waiting for your feedback. Simply tell them what worked for you? What didn't and why?

Help Others - be a community hero!
If you don't have the time to contribute to a single topic you can still choose to help others by tracking down their problems. There is a very active users@glassfish.java.net mailing-list for general questions and a dedicated webtier@glassfish.java.net mailing-list for Servlet, JSF, and other "web" technology questions. See the complete list of available mailing-lists for the GlassFish project to find the right one to contribute to. All you need to do is to subscribe with your free java.net account. And please remember the RFC1855 when writing to the lists :) Don't forget to ask questions. By doing this you might even help somebody not brave enough to ask something.
Stuff I personally like the most is blogging. About example applications which you have build, or about common questions which could be answered with example implementations (Security, Very short How-Tos) and other blog-posts. If you tweet about your posts and add the #GlassFish hashtag or tweet it directly to the @GlassFish twitter account I am sure the team is picking it up and spreading the word for you.

Find and File Bugs on Releases!
I am sure you suffered from a GlassFish bug in the past. And instead of sitting at your desk and start complaining about that crappy piece of software while talking to co-workers you simply could do what would solve it. File it! And it is simple as using the GlassFish Project on java.net's JIRA. Make sure to include a simplest possible example of when and where the bug happens and be curious to see what is happening and who is taking care about it.

Test-drive Promoted Builds and Release Candidates!
Working with the JIRA and filing your first bugs is a good base for taking the next step. Now you know what it takes to report bugs and you simply could run your stuff on latest promoted builds or release candidates. This makes sense for the main development versions at a given time and date. As of writing this post you could get your hands dirty by trying the GlassFish 4.0 promoted builds. And this is especially easy with GlassFish because you don't have to build it. It's all there. For your platform of choice. Give it an early test-drive and have the chance to find stuff before it get's released. Every bug you find is a complaint less from anybody of the growing community and a valuable contribution!

Work with Code! Get things done!
Tired of writing documentation and testing a lot and giving feedback? And you are known a bit among the core developers? And you are ready to take a challenge? Let's go with requesting the observer role on the glassfish java.net project and get ready to build latest trunk and get familiar with the continuous build. You have to join and observe the dev@glassfish.java.net mailing-list and read about contributing code in general.
And there might be a lot of small stuff to do. Fix a bug, Write a test, silence a compiler warning, add a comment. Or even bigger things: Contribute enhancements, new features or even whole modules. It's completely up to you.  The very first step is to sign the OCA Policy (Contributor Agreement) and submit your patches via email, and then ask the maintainer of the code for commit access. The maintainer will seek consensus before granting the Developer role, but their decisions are final. You have to follow the coding conventions and know about the Roles & Governance Policy. And always keep in mind: You are working on an application-server. Which isn't the smallest project you could get your hands on in general.

I am nominated for the 2012 JBoss Community Recognition Award

07:00 Thursday, April 5, 2012 Posted by Test No comments:
, , ,
Each year, the JBoss project leads are asked to nominate contributors that they feel have make significant and leading contributions to the JBoss.org Community over the past year. Now it’s that time again, and those nominations are now complete.
Big news: I am nominated for the 2012 JBoss Community Recognition Award in the category documentation. A big "Thank you!" goes out to Aslak Knutsen (@aslakknutsen) for nominating me! - so let the voting begin!

Review the Nominees then place your Votes NOW!

Markus Eisele - Arquillian
Markus, a very active blogger in the JavaEE space, has taken an interest in Arquillian and has written multiple blogs about the project and how to use it with alternative containers. He helped translate the Getting started guide to German, which gives Arquillian native language support in on of it’s biggest supported areas.

Monday, April 2, 2012

The Java EE 6 Example - Gracefully dealing with Errors in Galleria - Part 6

07:17 Monday, April 2, 2012 Posted by Test 5 comments:
, , ,
The Galleria Java EE 6 example app is growing . Today I am going to write about how to gracefully deal with errors. A lot has been done about user input validation already but there are still a lot of failure situations which are not handled but should be. If you are curious about what happened in the past look at the first parts of the series: The basics , running it on GlassFish, running it on WebLogic, testing it and enhanced security.

General Exception Mechanism
The application uses checked exceptions to communicate errors between the layers. The ApplicationException is the root of all possible business exceptions.

Those business exceptions communicate validation violations and all known errors between the domain and the presentation layer. The <domain>Manager (e.g. AlbumManger) classes in the galleria-jsf view project catch them and use the ExceptionPrecessor to populate the error messages to the view. The other kind of Exceptions that could occur between those two layers are RuntimeExceptions. Those get wrapped into an EJBException by the container and are also caught by the The <domain>Manager classes. Those generate a more general error message which is shown to the user.

I am not going to jump in on checked vs. unchecked exceptions here (Google a bit about it if you are curious). I tend to use checked exceptions when the application has a chance to recover from the error. Unchecked are thrown when something happens which isn't recoverable. That is the reason, I am not happy with the exception handling mechanism build in at the moment. I am going to get into this a little later.

What is missing? ViewExpired and more.
Seems as if everything is handled right now. But only on the first impression. Open the login screen and wait a bit and let your http session timeout. You are now greeted with a not so nice ViewExpired exception screen.

If you are trying this as a loged-in user you are simply redirected to the login page. Anyway, the same error page could come up for some other unexpected conditions in the presentation layer. So, let's fix this. Most obvious thing to do is to simply introduce a dedicated error-page.
Now you redirect your users to a dedicated page which could tell him/her something nice about workplace security and not leaving the app unattended for such a long time. This works for most of the applications out there. If you are willing to have some additional information on the page or simply want to catch more than one exception and handle them individually without having to configure them statically, you need something called an ExceptionHandler. This is new in JSF 2 and all you need to do is to implement an ExceptionHandler and it's factory. The factory itself is configured in the facex-config.xml because there isn't any annotation for it.

Open the faces-config.xml and add the following lines at the bottom:
Now we are going to implement the GalleriaExceptionHandlerFactory in the dedicated package. The interesting method here is the:
    public ExceptionHandler getExceptionHandler() {
        ExceptionHandler result = parent.getExceptionHandler();
        result = new GalleriaExceptionHandler(result);
        return result;
This is called once per request must return a new ExceptionHandler instance each time it's called. Here the the real ExceptionHandlerFactory is called and asked to create the instance, which is then wrapped in the custom GalleriaExceptionHandler class. This is where the real interesting stuff happens.
    public void handle() throws FacesException {
        for (Iterator<ExceptionQueuedEvent> i = getUnhandledExceptionQueuedEvents().iterator(); i.hasNext();) {
            ExceptionQueuedEvent event = i.next();
            ExceptionQueuedEventContext context = (ExceptionQueuedEventContext) event.getSource();
            Throwable t = context.getException();
            if (t instanceof ViewExpiredException) {
                ViewExpiredException vee = (ViewExpiredException) t;
                FacesContext fc = FacesContext.getCurrentInstance();
                Map<String, Object> requestMap = fc.getExternalContext().getRequestMap();
                NavigationHandler nav =
                try {
                    // Push some stuff to the request scope for later use in the page
                    requestMap.put("currentViewId", vee.getViewId());
                    nav.handleNavigation(fc, null, "viewExpired");

                } finally {
        // Let the parent handle all the remaining queued exception events.
Iterate over the unhandler exceptions using the iterator returned from getUnhandledExceptionQueuedEvents().iterator(). The ExeceptionQueuedEvent is a SystemEvent from which you can get the actual ViewExpiredException. Finally you extract some extra information from the exception and place it in request scope to access it via EL in the page later on. Last thing to do here for a ViewExpiredException is to use the JSF implicit navigation system ("viewExpired" is resolved to "viewExpired.xhtml") and navigate to the "viewExpired" page via the NavigationHandler. Don't forget to remove the handled exception in the finally block. You don't want this to be handled again by the parent exception handler. Now we have to create the viewExpired.xhtml page. Do this inside the galleria-jsf\src\main\webapp folder.
<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE composition PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<ui:composition xmlns:ui="http://java.sun.com/jsf/facelets"
    <ui:define name="title">
        <h:outputText value="#{msg['Exception.page.title']}" />

    <ui:define name="content">
            <h:outputText value="#{msg['Exception.page.message']}" />
            <p>You were on page #{currentViewId}.  Maybe that's useful.</p>
            <p>Please re-login via the <h:outputLink styleClass="homepagelink" value="#{request.contextPath}/Index.xhtml" ><h:outputText value="Homepage" /></h:outputLink>.</p>
Please note that I added new message properties here, so you need to make sure to place them in galleria-jsf\src\main\resources\resources\messages.properties and translations.
Until now this obviously only handles one special instance of exception. You could extend it to handle others as well. Now that we have the basic mechanism in place you are free to do this.

Refactoring the RuntimeException handling
As I said, I am not happy with the way the application is handling RuntimeExceptions. Now that we have a nice central exception handling in place we can move those stuff around a bit and refactor the *Manager classes. Delete all those    catch (EJBException ejbEx) { blocks from all of them. We are going to take care of them in the GalleriaExceptionHandler in a minute. Simply add an another check to the GalleriaExceptionHandler and redirect the user to another page if any other exception than a ViewExpiredException is thrown.

 // check for known Exceptions
            if (t instanceof ViewExpiredException) {
                ViewExpiredException vee = (ViewExpiredException) t;
                // Push some stuff to the request scope for later use in the page
                requestMap.put("currentViewId", vee.getViewId());

            } else {
                forwardView = "generalError";

                Locale locale = fc.getViewRoot().getLocale();
                String key = "Excepetion.GeneralError";
                logger.error(Messages.getLoggerString(key), t);
                String message = Messages.getString(key, locale);
                FacesMessage facesMessage = new FacesMessage(FacesMessage.SEVERITY_ERROR, message, null);
                fc.addMessage(null, facesMessage);
This approach has some advantages. It reduces the needed code in the *Manager classes and we finally have a central place to take care of those unrecoverable exceptions. This still is not very enterprise like. Imagine your first level support team needs to look after customers and they start complaining that the only message they get is a "GeneralError". That is not very helpful. You support team would need to escalate it and second or third level would need to check the logs and and and .. All this because of an error, that we could have know. First thing to do is to find out about the causing error. Parsing stack traces isn't big fun. Especially not of RuntimeExceptions that are wrapped in EJBExceptions and further on in FacesExceptions. Thank god for the Apache Commons ExceptionUtils. Open your galleria-jsf pom.xml and add them as dependency:
Now you can start to examine the root cause:
 } else {
                forwardView = "generalError";
                // no known instance try to specify

                Throwable causingEx = ExceptionUtils.getRootCause(t);
                if (causingEx == null) {
                    causingEx = t;
                logger.error(Messages.getLoggerString(key), t);
               requestMap.put("errorCode", errorCode);

Don't forget to also log the complete stack-trace (t and not only causingEx) here. In general it's a bad thing to let users know about exceptions. Nobody really wants to see errors happen (because we do hate making mistakes) and after all exception stack-traces could disclose sensitive information which you wouldn't like to see on a screen somewhere. So you need to find a way to display something meaningful to the user without disclosing too much. That is where the famous error-codes come into play. Use the root-cause exception as message key or make your own decisions on what effort you are going to put in here. It might be a system of categories of errors (db, interface systems, etc.) which give the first-level support a good hint about what was causing the error. I would stick to a simpler solution from the beginning. Simply generate a UUID for every caught exception and trace it to both the log and the UI. A very simple one could be the following.

String errorCode = String.valueOf(Math.abs(new Date().hashCode()));

This should also be added to the message properties and don't forget that you need another one for the generalError template. If slf4j would use the same message format than jdk logging does you would only need one property .. anyway:

Exception.generalError.log=General Error logged: {}.
Exception.generalError.message=A general error with id {0} occured. Please call our hotline.

Add this to the generalError.xhtml and see how the error code is passed to the message template.

 <h:outputFormat  value="#{msg['Exception.generalError.message']}" >
                <f:param value="#{errorCode}"/>

There is still a lot to improve on here. You could use the javax.faces.application.ProjectStage to lookup the current mode the application is running in. If you are running in ProjectStage.Development you could also put the complete stack-trace to the UI and make debugging live a bit easier. The following snippet is trying to get the ProjectStage from JNDI.

public static boolean isProduction() {
        ProjectStage stage = ProjectStage.Development;
        String stageValue = null;
        try {
            InitialContext ctx = new InitialContext();
            stageValue = (String) ctx.lookup(ProjectStage.PROJECT_STAGE_JNDI_NAME);
            stage = ProjectStage.valueOf(stageValue);
        } catch (NamingException | IllegalArgumentException | NullPointerException e) {
            logger.error("Could not lookup JNDI object with name 'javax.faces.PROJECT_STAGE'. Using default 'production'");
        return ProjectStage.Production == stage;

What about the 3-digit Http Error Pages?
That is another thing to take care of. All those remaining 3-digit http error codes which return one of those not nice looking error pages. The only thing to do this is to map them in the web.xml like shown in the following:
You should make sure to have those mappings in place and present a meaningful error to your users. It should become best practice to always offer a way to navigate further from there.

The Heroes of Java: David Blevins

06:15 Monday, April 2, 2012 Posted by Test No comments:
, , ,
Time to catch up with my "Heroes of Java" interview series. This is interview number 15 already and I am glad it is David this time. You might have read the name before. He is the Java EE hero in person.

David Blevins
is a founder of the Apache TomEE, OpenEJB and Geronimo projects. David was a member of the EJB 3.0, EJB 3.1, and Java EE 6 Expert Groups, current member of the EJB 3.2 (JSR 345) and Java EE 7 (JSR 342) Expert Groups, and contributing author to Component-Based Software Engineering: Putting the Pieces Together from Addison Wesley.

General Part
Who are you?
You can blame me, in whole or part, for the creation of OpenEJB (1999), Geronimo (2003), TomEE (2011, yay!), a handful of small projects like Swizzle, XBean and the short-lived distributed GBuild system, as well as meddling in other projects like OpenWebBeans, Axis, and (if I can find the time) the newly created DeltaSpike.
I've been involved with the EJB spec since 3.0, Java EE since 6, and consider the Embeddable EJBContainer API and "EJBs in WARs" to be two of my favorite contributions to the standards space, with hopefully more on the way. Overall, Java EE and especially the goal of embeddable and testable JavaEE has been a passion of mine for many years, though I'll say I've really just hit my stride in the last couple years.

Your offical job title at your company?
I think my title is "Software Architect", though I often fill out conference badges with "Open Source Guy" for fun. I was part of Gluecode which was a Geronimo-focused company purchased by IBM in 2005. My official role there pertains to WebSphere CE which is Geronimo-based. So I guess, technically speaking, I worked on three servers that reached Java EE 6 certification last year; TomEE, Geronimo, WebSphere CE. It was a very busy year!

Do you care about it?
I'm incredibly passionate about everything I do and will do it if the title matches or not. No one, including me, has a "Developer of TomEE" job title, yet it exists and has a community of people who love it and pursue it with intensity.

Participating in the JCP on Java EE specs is also not my title, but something I do out of a strong desire to both prove it and see it improve. Java EE, especially EJB, took it on the chin in the Spring heyday and that seems to have infused a great deal of stubbornness in me to prove that while implementations can be heavy, specifications are ideas that can be improved and be implemented as light as anyone might want. No technology is as bad as anyone might say as long as there are people who are willing to listen and improve it.

But above all, I like to make things. Difficult things that you can’t do by yourself. I like the making of it more than the thing itself. What keeps me working on something are the people who find enjoyment in what you have created and the people with whom you find enjoyment in doing the creating.

Do you speak foreign languages? Which ones?
Fluent Spanish, thanks to my beautiful wife Ameila, all my wonderful in-laws in Ecuador and Spain. I've never had to use it in a technical setting, though, and I really admire people who have to work in their second language. I’ve been learning Italian and some day I’d like to add Portuguese to the list.

How long is your daily "bootstrap" process? (Coffee, news, email)
Every morning I go straight from bed to the espresso maker, make a cappuccino for the wife and myself and go straight in on the queue. It’s too long to get through in one day. Between openejb, tomee, java ee7, ejb 3.2 and other mailing lists and just plain work, it can be quite late before I get to any coding myself.

I find I have to just focus on a couple topics a day and just keep rotating. That’s great for maintenance, but doesn't really get you those large leaps forward. I find when I'm most productive it tends to be in blackout periods where I ignore all inputs, all meetings, sleep very little and do nothing but code on one thing. I call it going into a black hole. Seems to be the only way to get certain things done. At the end of the year I can go back and pinpoint major developments to "black hole" periods.

You have a twitter handle? Why?
Mostly because I consider it irresponsible to encourage people to devote time, energy and large portions of their life to something and not to talk about it.
At least that’s what I told myself when I convinced myself to open it up. I don’t really spent a lot of time celebrating my successes and am always right onto the next thing. Spending time promoting something or calling it “the best” is really hard for me. It feels narcissistic and egotistical and that’s just not me.

That O’Reilly interview with me at JavaOne on YouTube sat there for three months before I mentioned to anyone it existed. That’s how bad I am.

There’s zero doubt in my mind it’s my largest personal flaw something I’m really trying to work on. The “if you build it, they will come” say is simply not true. You’ve got to build it and promote it with just as much passion as you built it. Something I seem to only be good at in bursts. But as I say, I’m working on it. :)

Whom are you following in general?
Almost exclusively tech people. Most are friends from other app servers and other projects. I adore the JBoss and Glassfish guys in particular, lots of friends in who tweet often in companies like FuseSource, Sonatype, MuleSoft and similar. Few people understand how hard it is to do the things you do other than people who also do it. Friends and family will always love you, but there are just some things only your fellow colleagues understand. It’s nice to be able to see how everyone is doing and what they’re working on.

The [tech- David @dblevins] non-tech David to follow @TheOnion, @chelseahandler, @alyankovic and @thensoncompany (who doesn't love the muppets!)

Do you have a personal "policy" for twitter?
No real policy, though I tend to be more tech on twitter and more personal on facebook.

Does your company restricts or encourages you with your twitter ussage?

What's your daily development setup? (OS/IDE/VC/other Tools)
OSX, Intellij, Maven, SVN (only just started playing with Git).

Which is the tool providing most productivity to your work?
The above, definitely. When there is no tool, filling in the gaps with regular expressions, bash, perl and other command-line hackery are my go-to for ad-hoc tools. I’m a big fan of reducing the size or repetitiveness of tasks through writing cheap tools.

Your prefered way of interacting with co-workers?
80% IRC, 19% other IM, 1% phone/skype. Face to face when I can, though that is a rare treat.

What's your favorite way of managing your todo's?
I've tried all sorts of software, but for some reason I default to pen and paper at my busiest times. I keep an open notebook next to my computer. When things are crazy, all the mess in my head goes there.

If you could make a wish for a job at your favorite company: What would that be?
I’d love to see a company focused on TomEE and be in a position to offer some of the really hard-working people on the project jobs doing what they love.

TomEE is a unique beast in that it's the first Java EE app server to reach certification without corporate backing. It is filled with people who work all day at full-time jobs and then come home and hack on TomEE. People who will take vacation to get together and hack once a year. It's an incredibly special community.

You're programming in Java. Why?
I did my first major work in Java on version 1.1.2 and have used it steadily since. The the evolution of the language has played a major part in keeping it fun and enjoyable for me. But I have to say I wouldn’t still be using Java if tools like Intellij or Eclipse hadn’t been invented, which I view as “structure” editors rather than text editors. They read in and understand the bytecode and can fundamentally edit logic. You can digest and transform a massive codebase with ease if you know what you’re doing.

The thought of going to another language where this is not possible and you have to deal with a large program as plain text seems like going back to the stone age.

What's least fun with Java?
I guess it would be that even a small program is still large. Not a serious issue as the inverse is also true; large programs in Java can be quite small. But there are definitely problems too small for Java.

If you could change one thing with Java, what would that be?
I've blogged about it, so I guess I should keep my stance that I think 'final' should be the default and there should be a 'mutable' or some other keyword. In practice it's far rarer to actually need to re-initialize an already initialized variable. It's too late to make that change, though.

One thing that isn't too late is I'd love an "import org.acme.Foo as Bar;" syntax. I hate needlessly long and ugly class names, which I would describe as "preemptively ugly" for the sake of not conflicting with other classes. If two class names conflict, let me import them with different names of my choosing that makes my source more readable. Imports are not represented in bytecode and are little more than syntactic sugar. Making that sugar a bit sweeter would be great.

What's your personal favorite in dynamic languages?
I rarely get a chance to play with that kind of tech, though I find it interesting.

Which programming technique has moved you forwards most and why?
Hard to pick just one with so many tools in the toolbox. Less of a technique and more of a philosophy, but a big one, is I tend to avoid design overhead as much as possible. Java programmers in general tend to over-abstract and over-design. Time tends to prove the things you think you’ll need are not what you will eventually need. Adapting to change then becomes an act of removing things you don’t need only to add what you do need. The more complexity, the harder it is to unravel it and adapt. Today’s abstractions are tomorrow’s restrictions.

Employing minimalism in design and architecture, keeping code honest, and not attempting to solve problems before you actually have them are keys to a 10 year codebase.

What was the biggest project you've ever worked on?
I laugh everytime I think of it, but during the late 90’s boom I worked on a project that spent the equivalent of two Lunar Rover’s in just 3 years, only to scrap it when they bought and merged with another company in the industry.

Which was the worst programming mistake you did?
To be quite honest, not sticking to my guns when I knew what I was working on was the better vision and goal.

The equivalent of what became OpenEJB 3 and TomEE 1 where there in rough form in 2003. The concepts of Embedded EJB container and JavaEE add-on for Tomcat worked fine, but unfortunately it was one major EJB spec revision behind. The codebase was dropped in 2003 when Geronimo launched, which is something I protested but ultimately allowed. It became clear that it would never be possible to re-add these features with the new codebase, so in 2006 I quietly resurrected the old codebase and this is what became OpenEJB 3 and eventually, TomEE.

If I had stuck to my guns, we might have had Embeddable EJB and “JavaEE for Tomcat” a few years earlier. But you never know with these things, it might never happened at all. Regardless, of when it happened, I’m glad I didn’t give up and both eventually came to life.

I’m not sure how it looks from the outside, but I can say on a personal level releasing OpenEJB 3 final in 2008 and TomEE in 2011 were two of the hardest things I’ve ever done. I don’t mean that in any technical sense. Their existence isn’t the act of having an idea, but the sheer force of will and dedication it takes to make it happen and keep doing it. You face a lot of challenges and uncertainty and it’s a constant test to every part of your character.

Of course therein lies the fun :)