In Relation To

Matt Corey has blogged about CDI interceptor bindings, showing a simple example of how you can implement your own @RequiredTx annotation. He also lightly criticizes the use of beans.xml for interceptor enablement. (This was also discussed in the Weld forum.) I really think we have the design just right here, and I'll explain why. But first let me remember why CDI interceptor bindings are much better than the @Interceptors annotation from EJB 3.0.

In reply to this post, Matt writes:

I just updated the Examples Guide for Weld 1.0 on the newly released JBoss AS 6.0.0.M1, including how to load the projects into Eclipse.

One of the points for using Hibernate Search is that your valued business data is stored in the database: a reliable transactional and relational store. So while Hibernate Search keeps the index in sync with the database during regular use, in several occasions you'll need to be able to rebuild the indexes from scratch:

The second beta for the Tattletale, the Java dependency analyzer, 1.1 release is out.

I've seen a couple of folks wondering why CDI requires a beans.xml file in every bean archive. If there's no alternatives, interceptors, or decorators to declare, why do you need to have the empty file?

Matt Corey writes:

How do you follow the fantastic news of the week with the Java EE6 platform and CDI getting final approval ? How about a JBoss AS release that includes support for three key EE6 features: CDI, Bean Validation, and JSF 2?