I would like to thank Matt Corey for his commentary on Web Beans, and respond to several points.
Web Beans is not just about the web, as many people have already commented (including Gavin)... while I don't necessarily need it to be brought to JSE, I believe a name change is in order...
I'm inclined to think that the concrete issue of the target platform is more important. Both platforms already feature strong branding and Web Beans is just a piece of the platform, not a platform by itself. On the other hand, if SE developers feel that this technology is useful to them, then we (the Web Beans group) are going to have to go back to Sun and the JCP and discuss how their needs can be accommodated.
If Web Beans becomes a generic Dependency Injection mechanism, then we would be left with at least three distinct DI systems in JEE -- the Web Beans DI, the @EJB/@Resource DI from JEE 5, and the Managed Bean mechanism from JSF... something will need to be done to address this (please don't say 'Unified DI', a la 'Unified EL' :) )...
This is certainly a problem we're thinking about. But we need guidance from the EE expert group on how to proceed with this. In theory we could provide facilities that would allow @EJB and @Resource to be implemented on top of Web Beans, if that was the decision of the EE expert group.
The @In annotation clearly comes from Seam, but there might be something more appropriate here -- in Seam, there is also an @Out annotation, representing 'outjection'... So far, Gavin hasn't given us a hint of whether this will be around in Web Beans, but if not, then I think @In should become something like @Inject, @Bean, @Component, etc
We kicked @Out out of the spec, after much discussion. @Out is really convenient in the Seam/JSF world of named variables. It doesn't make so much sense in the world of Guice/Web Beans where much more static checking is possible. And it's possible to achieve a very similar effect using resolver methods.
I'm open to suggestions for renaming @In, I've considered @DependsUpon, @Uses, @Contextual and @Injected.
The Guice influence appears to have replaced the String-based naming in Seam (i.e. -- @Name("myBean") ) with annotations (@MyBean)... while this requires a little more code, it seems to be a good call -- it should help prevent things like typo's in the Strings causing NullPointerExceptions at Runtime...
Right, this is something that Guice did beautifully. The Guice approach is elegant, typesafe and completely natural - so much better than the approaches of Spring or of JSF (Seam built upon the JSF approach).
However, injection by name is still possible in Web Beans, since @Named is defined as a binding annotation. You can do:
@In @Named("currentOrder") Order order;
(If you really want to.)
The various Component Types could be hugely useful for having multiple configurations for a single application, but I would like to see more ways of defining your components -- for example, I like to be able to keep my system configurations in the app server itself, so when I deploy an EAR from test to staging to production, I can simply copy an EAR that has passed QA -- if I have to change the web-beans.xml file, I can't do this (unless there is perhaps a default that you could configure in your server)
One way you could do this is to just not include the archive containing your @Staging components when you deploy to production. If high-precedence components are not in the classpath at deployment time, they won't be deployed.
I love the scopes, but Gavin mentions that the @ConversionScoped will be available from JSF managed beans, while request, session and application will be available from Servlets -- what about JSF makes it the only thing that is appropriate for the conversation scope? Any reason it couldn't be available to Servlets-based frameworks like Struts, etc.?
No reason at all. But here we're drifting into questions like:
- what functionality should be defined by the Web Beans specification?
- what functionality can be provided by the application or third-party frameworks?
The Web Beans spec has an extensible context model. In particular, this means that if you want to define your own Context object for the @ConversationScoped scope, that works for any servlet request, you can do it.
So far all I can say is "Great work guys!"... oh, and keep the previews coming!
Thanks for the feedback Matt, appreciated :-)
