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

Advertisements

One thought on “Web Beans Sneak Preview

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s