Before I get started, my position on the subject of ejbs should be known. I actually thought that ejbs were on the way out... with the lack of testability and the extra unnecessary complexity for most projects prior to ejb3. EJB3 greatly improved this, but IMHO was too little too late. Spring + Tomcat already provided what folks were looking for. Additionally the number of clients using JSF is a dying breed. Once again, JSF 1.0 missed the boat with non-bookmarkable pages, etc. While there are shops sticking with these Sun driven standards which are produced out of the JCP, the majority of support appears to come out of vendor interest and not developer interest. My earlier work on projects with JSF led me to appreciate a couple of frameworks; 1. facelets, 2. a4jsf, and 3. SEAM (when working on jboss). jsr-299 (web beans) seems to be the formal standardization of SEAM.
My thoughts on jsr-299
It appears that @ annotations are the new shiny toy, and there is no end to specifications going crazy with them. jsr-299 defines 34 new annotations. The goal of the specification as defined on the spec home page, is to unify JSF managed bean component model with the EJB component model... well I've stated my position on this. So either this specification is too little too late and a benefit mainly to jboss, or perhaps there is something to be gained beyond this spec stated goal.
There were several interesting ideas out of the specification. The first was the creation of an extensible annotation model. So if there are not enough annotations in the world for you, you can create your own that work with the framework. This is accomplished through the new javax.inject.@BindingType. This appears to provide fine grain autowiring qualifier. One of the examples given defines
@LDAP
class LdapAuthenticator
implements Authenticator { ... }
followed by the declared injection of an LDAP Authenticator:
@LDAP Authenticator authenticator
Another interesting idea is producers... I really like the concept here. Page 3 and 4 illustrate an example where a @SessionScoped @Model Login class has a @Produces @LoggedIn User getCurrentUser() method. Abbreviated below:
@SessionScoped @Model public class Login {
@Current Credentials credentials;
@PersistenceContext EntityManager userDatabase;
private User user;
@Produces @LoggedIn User getCurrentUser() {
if (user==null) {
throw new NotLoggedInException();
} else {
return user;
}
}
Then the getCurrentUser() method is invoked for the inject as listed below:
@Model
public class DocumentEditor {
@Current Document document;
@LoggedIn User user;
@PersistenceContext EntityManager docDatabase;
public void save() {
document.setCreatedBy(currentUser);
em.persist(document);
}
}
The last interesting part of the specification is the event framework. I don't understand why this is in the specification. There appears to be no dependency for the event framework on the other parts of the specification. It doesn't comply with the stated goal of unification of JSF and EJB. It would make sense for this to be separate. Mainly to use it separate from all other aspects of web beans.
Thoughts on jsr-318
I did not review the entire specification yet. I was checking out some of the mentioned ejb-light details mentioned in jsr299. As mentioned, outside of being required by clients to help them with ejbs or ejb light projects, I'm really not interested. There is however one very interesting addition to the ejb specification, that is the @Asynchronous annotation. This is long over due. In addition to its obvious benefits, a method annotated as asynchronous can also return a value defined as java.util.concurrent.Future
The concept of EJB-lite is lost on me... I already have that it is Spring.
Summary
If you are looking to stay in the world of EJBs and JSF, then these newly defined specifications are of great value to you and your shop. jsr-299 fills a number of gaps in the jee space and provides the power of Spring in a standardized way. Clearly jsr-299 will be part of the new jee 1.6 specification, at least in several of the profiles. If you are not using either JSF or EJB or nether, then it is unclear what value this brings to the community. It will be interesting to see if a vendor implements this specification (or a portion of it), in a world without JSF. It appears that the jsr-299 specification helps vendors more than it helps developers.
