Bio

I am leading the CDI 1.1 specification, and work on JBoss Developer Framework, a
set of tutorials and examples for all JBoss users. Previously, I've worked on
Infinispan and I led the Seam and Weld projects, and am a founder of the
Arquillian project. I've worked on a number of specifications including JSF 2.0,
AtInject and Java EE 7. I am a regular speaker at JUGs and conferences such as
JavaOne, Devoxx, JAX, JavaBlend, JSFDays, JBoss World, Red Hat Developer Day and
JUDCon.
I am currently employed by Red Hat Inc. working on JBoss open source projects.
Before working for Red Hat, I used and contributed to Seam whilst working at a
UK based staffing agency as IT Development Manager.

In Relation To Pete Muir

In Relation To Pete Muir

I'm pleased to say that CDI 1.1 is available and included in Java EE 7. If you want to learn more, read on, and join a webcast 12th June about all the technologies in Java EE 7. Both webcasts are followed by a Q&A session, when CDI experts will be on hand to answer your questions. The webcast is at [9 am PT / 12 pm ET / 5 pm London] or [9 pm PT / 12 am ET (Thursday) / 2 pm Sydney (Thursday)]

Last week the JCP posted the CDI 1.1 public review draft. This draft continues to incrementally improve the 1.0 spec. We haven't added any major new features, instead we're concentrating on honing 1.0 :-)

The CDI class, which provides programmatic access to CDI facilities from outside a managed bean

The CDI 1.0 specification clearly states that only beans whose bean class is accessible (using standard classloader visibility rules) can be injected into another bean. For example, if you have a bean A in WAR, assuming standard Java EE classloader structure, it wouldn't be available for injection in bean B, in an EJB module. This generally makes sense, as the type is not visible either.

CDI also offers two options to replace bean implementations transparently, without explicitly selecting that implementation (either by type or using a qualifier) - alternatives and specialization. In this case, it is less clear that the bean class of the specializing bean, or the bean class selected alternative, must be visible.

The CDI EG is still debating this issue, including whether to offer a backwards incompatible mode here.

CDI implementations have not consistently shared @ApplicationScoped beans across all modules of an EAR. This issue heavily relates to Bean visibility. The CDI 1.1 specification will clearly state how @ApplicationScoped are shared.

A commonly requested feature is for the application to be able to do some work once the application has started but before it starts servicing requests originating remotely. Currently CDI 1.1 defines a @Initialized(ApplicationScoped.class) which is called when the application context starts, but we are investigating whether this can be extended to provide a more general startup event.

If we define such an event, we need to allow custom contexts to activate themselves whilst it is executing, however this is likely beyond the scope of CDI 1.1 and will likely be addressed in CDI 2.0.

CDI 1.1 adds @WithAnnotations which allows an extension observing ProcessAnnotatedType to filter which types it sees. We would like to provide such functionality for all container lifecycle event observers, but there are some interesting things to consider, including whether it would be better to filter on qualifiers for later events. CDI 1.1 may or may not add such support, and we are looking for feedback on this.

CDI 1.0 requires array valued members of qualifiers to be annotated with @Nonbinding, excluding them from the resolution process. The JDK defines that annotation equality for array valued members should use Arrays.equals(), which requires two identical arrays (equal values, in the same order) in order to return true.

We feel that to make array valued members of qualifiers useful, we need to offer a pluggable strategy for checking equality of arrays, as often it would be desirable to consider two arrays with the same values, in any order, as equal. We intend to add this for CDI 1.1.

CDI 1.0 requires the type used for observer resolution to be based on the runtime type of the event object. Unfortunately, the JDK erases generic type information about objects that we need to allow firing of many events with parameterized types. CDI 1.0 also completely ignores the generic type of the injected event object, which does typically contain the needed type information. We therefore intend to change the event observer resolution rules to allow the generic type of the event object to be taken into account if the runtime event object does not contain sufficient information.

Note that this may seem like a backwards incompatible change, however CDI 1.0 is essentially unimplementable today - examples in the spec do not work as described.

We start small, with the quickstarts. Each quickstart is very focused, and shows you one API, or one use case. There are about 53 quickstarts today, ranging from JAX-RS CRUD to GWT to HTML5 to transactions.

Quickstarts are great, but there comes a time in everyone's life when they want to write something other than a simple application! TicketMonster steps up to the plate at this point. Today, it's a full web-app written, with front-ends showing off the three approaches to view layers we like at JBoss - HTML5 + REST, Errai/GWT and RichFaces/JSF.

Over time, we plan to add much more to TicketMonster, as well as spin up other examples. Check out the Roadmap for more info on our plans!

To make all this possible, we've developed a set of BOMs. The BOMs start with Java EE 6, and build on that base API with JBoss extensions such as Hibernate (Search, Validator...), Errai and Arquillian. They're a great way to make sure you're using the same set of dependences that we test with!

JBoss Developer Framework 1.0 is firmly focused on education, showing you how to use JBoss Enterprise Application Platform and JBoss AS with Java EE 6.

JBoss Developer Framework 2.0 will start to add other technologies to the stack, such as Deltaspike and Aerogear. We won't be forking these projects, but simply testing and recommending a version to use (via a Maven BOM).

@Transactionalis being developed as a revision to the JTA spec (as an MR)

@Transactionalis not being developed by the CDI EG, nor will it be in the CDI spec

Feedback on @Transactional should be sent to the Java EE platform EGnot to the CDI EG. The platform EG is conducting the revision to the JTA spec.

Java EE does not recognize a Servlet container as a compliant environment and therefore this feature will not be available there by default (mainly due to the absence of JTA in this environemnt).

However, to bridge the divide, Deltaspike will likely offer support for @Transactional in a Servlet environment since we acknowledge that it is important, and is an environment preferred by many developers (but we still strongly urge you to migrate to the web profile!!).

Whilst I was relaxing over the Christmas break, a few items came in which I want to share with you.

First up, JUDCon India. In two weeks, what feels like half of the core developers at JBoss will descend on Bangalore for two days packed full of talks on all things JBoss. I'll be covering Infinispan and application development using JBoss AS and Java EE.

Next, I'll be in Brno (my favourite city in the Czech Republic, as I always get to drink lots of beer with friends. I'll be speaking at the JBUG and at the Developer Conference about Infinispan. See you there.

At JavaOne, I had the great pleasure of talking to Rick Hightower for half an hour. We covered CDI, Java EE, EJB and Spring - great fun! Info just published the talk.

The JBoss / Red Hat booth really was the hub of the conference for me, and my colleagues. I spent more time at the booth than anywhere. Whether it was catching up community members, presenting in the mini-theater, chatting with people interested in JBoss technologies, or just gossiping with colleagues, it was always fun.

The mini-theater was a great crowd draw, and both my mini-theater talks caused the corridor to become impassable. All the mini-theater talks were recorded, and are just starting to appear online. I had a cloudy theme to mine, showing people how to use Red Hat's PaaS, OpenShift.

The parties were non-stop, and of course I have to mention the JBoss Party at Slide. But the definite highlight of the week for me was seeing Tom Petty and the Heartbreakers, and Sting. Mark, my boss, told me I was allowed to appreciate Oracle for a couple of hours during the concert, but afterwards I had to take a cold shower ;-) I better not say too much more, as I know there are some good photos of me on his camera!

Our final party of the week was perhaps the most impressive. Roof top terrace of one of the two JBoss Pad's watching the Blue Angels doing a fly-by.

I managed to attend a few sessions, and enjoyed attending a couple around migrating from both Spring to Java EE. It's great to see the community really championing the cause of Java EE so enthusiastically. Makes those long hours Gavin, and many others, spent getting CDI off the ground seem very worth it.

My session was a once-in-a-lifetime opportunity - I talked about what's coming in CDI 1.1. I'm not a huge fan of this sort of session (I much prefer showing how you can build applications using the JBoss stack), but I knew the JavaOne audience would be interested in seeing the updates. The session, and many corridor discussions lead to an excellent panel session at the end of the week (with Arun in the chair, and David, Reza and Siva sitting alongside me on the panel). I learnt a lot about what you are looking for from CDI 1.1, and what your priorities are, invaluable information.

I had the opportunity to talk to InfoQ, O'Reilly and TSS during the week about CDI and Java EE - all three were great fun to do. We covered the inevitable question How does this relate to Spring? a couple of times of course ;-) I'll post when the interviews are up! Thanks to Rick, Tim and Cameron, and their respective teams, for taking the time!

Eh? What? Manik and I took a few days off after the conference to go hiking in the Sierra Nevada. There was somewhat more snow than we expected, and was pretty cold (night one, our boots froze), but a great way to unwind. Of course, I was sporting some pretty sexy well travelled head gear (it's been to 5500m above sea level and to 61 degrees north, that cap has).

I've just submitted an early draft of the Contexts and Dependency Injection 1.1 (CDI, JSR-346) to the JCP. We (the CDI community) have completed around a third of the features we want to see in CDI 1.1, so wanted to post an early draft to get some wider feedback. Whilst the JCP sort out the paperwork, you can read the draft on jboss.org :-)

So, what's been added since CDI 1.0?

@Disposes methods for producer fields

The CDI class, which provides programmatic access to CDI facilities from outside a managed bean