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.
31. May 2013
13. Nov 2012
05. Jun 2012
01. May 2012
10. Jan 2012
15. Oct 2011
05. Oct 2011
04. Oct 2011
03. Oct 2011
29. Sep 2011
02. Sep 2011
12. Aug 2011
07. Jul 2011
01. Jul 2011
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)]
- Add global enablement of interceptors (see the Java Interceptors Specification 1.2), global enablement of decorators (see http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#enabled_decorators_priority) and alternatives (see http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#unsatisfied_and_ambig_dependencies) using the @Priority annotation
- Add support for @AroundConstruct lifecycle callback for constructors (see the Java Interceptors Specification 1.2)
- Allow binding interceptors to constructors
- Moved interceptor binding to interceptors spec, allowing for reuse by other specifications
- Support decorators on built in beans (see http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#decorators)
- Add EventMetadata (see http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#event_metadata) to allow inspection of event metadata
- Add @Vetoed annotation allowing easy programmatic disablement of classes (see http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#what_classes_are_beans
- Many improvements for passivation capable beans, including @TransientReference allowing instances to be retained only for use within the invoked method or constructor (see http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#passivation_capable_injection_points and http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#passivating_scope)
- Add scope activation and destruction callback events (see http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#builtin_contexts)
- Add AlterableContext allowing bean instances to be explicitly destroyed (see http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#context)
- Add automatic enablement of CDI for beans with a scope annotation, and EJBs, in Java EE (see http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#bean_discovery)
- Add class exclusion filters to beans.xml to prevent scanning of classes and packages (see http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#bean_discovery)
- Add Unmanaged allowing easy access to non-contexutal instances of beans (see http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#bm_obtain_unmanaged_instance)
- Add CDI allowing easy accesss to the current CDI container (see http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#provider)
- Add AfterTypeDiscovery event, allowing extensions to register additional types after type discovery (see http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#atd)
- Add @WithAnnotations as a way of improving extension loading performance (see http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#pat)
- Many minor improvements to portable extensions (see http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#spi)
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
- Ability to veto beans declaratively using @Vetoed
- Conversations in Servlet requests
- Application lifecycle events in Java EE
- Injection of Bean metadata into bean instances
- Programmatic access to a container provided Producer, InjectionTarget, AnnotatedType
- Ability to override attributes of a Bean via BeanAttributes
- Ability to process modules via ProcessModule
- Ability to wrap the InjectionPoint
- Honor WEB-INF/classes/META-INF/beans.xml to activate WEB-INF/classes in a bean archive
- Global ordering and enablement of interceptors and decorators
- Global selection of alternatives
- @New deprecated
- Clarify interceptors and decorators must be implemented using proxying
- Allow multiple annotated types per Java class
- Allow Extensions to specify the annotations that they are interested in
There are a number of open issues about which we would appreciate your feedback:
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 will scan all classes in a jar with beans.xml. We plan to add a syntax to beans.xml that will the application developer to exclude classes using a variety of filtering options (e.g. by package). Weld offers such a syntax, and will be used as a starting point for CDI http://docs.jboss.org/weld/reference/1.1.5.Final/en-US/html/configure.html#d0e5769.
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.
JBoss Developer Framework exists to show you, the developer, how to make the most of JBoss and Java EE 6 technologies on JBoss Enterprise Application Platform and JBoss AS.
There are three ways we do this:
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!
We realise that there are lots of people still using older technologies such as Seam 2, Spring or Java EE 5. We've put together a comprehensive set of migration tutorials to show you how.
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).
If you want to ask questions, or help out, then visit our forums (which are also mailing lists).
We'll be tweeting using the #jbossjdf tag.
We'll mostly be posting jdf related items on the jdf news feed, so if you want to keep up to date, I suggest you subscribe there.
The conference was excellent, I think we all noticed the really high calibre of the attendees - lots of excellent questions throughout the sessions!
I captured both the presentations I did, and they are up on vimeo - check them out if either topic interests you!
A standard, universal @Transactional annotation is coming in Java EE 7. You can read more about the proposal here.
However, there are some important things to keep in mind:
- @Transactional is being developed as a revision to the JTA spec (as an MR)
- @Transactional is 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 EG not 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!!).
|Showing 1 to 5 of 118 blog entries||