Web Beans Sneak Preview

In case you didn't notice, Gavin King is offering a sneak preview of the Web Beans spec (JSR 299) so far in part 1, part 2, part 3 and part 4... It's been a whole day since his last post, so it appears like now is a good time to put out some thoughts... These are in no particular, but will hopefully serve to continue the conversation to make the eventual spec as useful as possible...

• 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...
  
• 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' :) )...
• 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
• 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...
• Very flexible -- follows the JEE5 pattern of defining a default configuration with annotations, but allowing it to be overridden or changed with an XML configuration... alternately, the XML configuration could be used as a central configuration file, as in Spring...
• 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)
• 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.?
• Could we reduce some of the annotation chatter with something like @In (scope=ConversationScoped, new=true)? Hmm... actually that ends up with more chatter -- perhaps not :)
  

That's enough for now... So far all I can say is "Great work guys!"... oh, and keep the previews coming!

M