Sunday, October 28, 2007

Web Beans and Modules!

After some good work, the JSR-299 group released an early draft, first published on Gavin King's blog, and now on the JCP site.

The spirit of Web Beans is really good, and the way the annotations came out is very promising. I have nothing to say but compliment the Component Types, Component Bindings, Scopes, Injection, and Interceptors. The Event has the good approach (Event type filter), but looks young at the moment.

Web Beans is really the state of the art "Educational Framework". The technical base is already explored (Guice, Spring, Seam) and is not so complex, but the impact on the developer thinking is really significant. Like every good "Educational Framework" (Struts, Spring, Seam), it makes it harder to do the "bad thing" (hacking, ugly coupling) than the right one (framework driven injection and loose coupling).
I know that if developers start to use these Annotations their code will get cleaner, more readable and manageable.

But, reading through the specs and especially, "4.4.2 Interceptors bindings" and "8. Packaging and configuration", I felt like something was wrong: Where are my Web Beans modules?
I don't want to get into the argument of OSGi or JSR-277, but I was expecting a more modular approach of Web Beans Injection.
What I mean, is that I would like to see a Web Beans "core" defining all the above Annotations for a pure J2SE environment. This would be the specification of how to use Dependency Injection Annotations. On top of that, another specification on how to provide "Components Provider/Injectors" for JEE, JSF, EJB, MDB and so on.
For example, I want to be able to do:
@Log
private Logger log;


just by adding log4j-web-beans.jar in my classpath. In this jar Log4J will provide the Web Beans Component for my class and my environment.
So, with this approach all the EJB, JSF & JEE stuff that really don't have to be there, can be specified separately as: jee5-web-beans.jar, ejb-web-beans.jar, mdb-web-beans.jar, etc.
I think it will make the specifications easier to read and a lot more flexible for all the great future components ;-)

Since I don't like people that complain without proposing something of their own, I tried to see how to do this with the current specification. And, basically it's not missing much.
Today in EJB3 environment, the first thing I do is creating an Interceptor that can inject components from Spring or other sources in my Session Beans. The injection is based on my project level Annotations and it bridges Spring and EJB3 nicely.
So a first solution (not good but...) is to use javax.interceptor.InvocationContext. If the Web Beans container is adding some entry in getContextData(), I can find out the Component Type, the Scope, and other information and decide how to populate all the @Log fields.

A nicer solution will be to have Annotations specified by JSR-299, that will allow me to write something like:
@ComponentProvider
public class Jee5ComponentProvider {

@Provides(EJB.class)
public Object getEJB(WebBeansContext wbc) {
try {
return new InitialContext().lookup(
wbc.getDestinationField().getType().getName());
} catch (NamingException e) {
e.printStackTrace();
throw new RuntimeException(e);
}
}
}

Here I really did not investigate enough, but I know I'm missing @ComponentProvider and WebBeansContext in the current specification.
What do you think?

Wednesday, October 17, 2007

JSR-299 or Web Beans

After postponing for too long, I finally decided to look at Web Beans or JSR-299.

The story is that for our seminar JavaEdge 2007 we invited Gavin King. He accepted to come and to talk about his new JSR, and this was the first time I encountered "Web Beans".
And to tell the truth: The name gave me a cold shower ;-)
What? Gavin started as a backend guru for O/R Mapping, then decided to target the issue of Web development with Seam, and now is "may be" going even higher in the stack with some UI components spec!
It really sounded like Gavin was leading the new spec for some JSF UI widgets :-(

This name really put me off, and so I postponed reading about "Web Beans".
That was a mistake, and a really bad move.

When I saw in Gavin blog, that he was excited about exposing the work done in JSR-299 group, I decided to get into it.

And the conclusion is:
  1. From my personal technical glossary, "Web Beans" has nothing to do with Web, and Beans are not UI JavaBeans.
  2. Gavin did it again.
Before Hibernate the O/R Mapping tools concentrated more on showing off their feature list than helping developer having a persistent model. For Gavin what's important is how the user (poor developer) will communicate with the framework. Powerful features should not show off and complicate the API or the tool. Once the usage is clear, the framework follows.
So after Seam and easy @Conversation, he's leading this great JSR.

"Web Beans" is basically a good (meaning pushing forward) standardization of IoC and DI concepts using Annotations. The overview from Gavin slides of the Silicon Valley JUG, is a really good start to understand what JSR-299 is about.

"Web Beans" really uses the good Guice framework, removes the issue of static scopes in Seam, and helps you create your own meaningful project Annotations. And all this is done true to the Java spirit: in a readable way.
JSR-299 answers some of my needs I had in AADA and I hope it will help projects moving towards creation of more custom Annotations.

So, please, change the name...
  • First, for once the JSR number is very easy to remember ( 300 - 1 easy to find an association).
  • Second I always associated Beans with JavaBeans Swing UI or Struts, and I never felt it was connected with the concept of Components used in Spring, Guice, Seam or JSR-299. By the way, in "Web Beans" there is no @Bean but only @Component.
  • Third, I found the term API (Application Programming Interface) does not match today's specification code and technique. EJB3, JAXWS and so on don't export a DLL API. They help you code. For example, In JPA (Java Persistence API) more than 90% of the code are Annotations not Interfaces. It should be Java Persistence Annotations, no? You can argue that Annotations are indeed interfaces in Java, and that it will not change the acronym ;-)
Anyway here are 2 possible names:
- Dependency Injection API (or Annotations)
- Components Injection API (or Java Components Injection Annotations ;-)

Finally, JSR-299 DIA also generalizes the concept of Injector injected by injection from the Dependency Injection framework, and I'm really happy about it ;-)