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 :-)
Having excluded the idea of @Out, you get rid of Seam's behaviour of calling the getter (or reflectively picking out the private field) after every method call. In a sense, @Out is the only way of automatically replacing something that's already in the context (I think -- going from the top of my head, here, so quite possibly wrong). So I guess this means that unless the application developer does some dodgy hacking (or uses some Web Beans API that you haven't told us about yet), the components in the context don't change other than that components not yet referenced in this context might be added later on. I wonder how this affects @In... I suppose there's three choices: (1) do it like Seam does (inject prior to every single method call); (2) do it once, on component initialisation; or (3) do it once for every time a new context is created. Any comment on which we're likely to get, and what trade-offs you think there are relating to enabling/disabling mutability of the component contexts?
It's definitely interesting that you're taking the approach of sticking strictly within the Java EE mandate contemplated by the JSR proposal. There are obviously political (in the sense of 'non-technical', rather than any negative sense) reasons for that, which I appreciate. Obviously, though, you'd be aware that regardless of whether you intend to stick within the bounds of Java EE or not, you are effectively defining a component framework for Java, and basically that means a (relatively generic) DI framework for Java. Obviously there's Spring and Guice already out there in that domain, especially in the SE space. And they're (with very good reason) quite well established there. Realistically, though, once Web Beans is part of Java EE, not only is there not going to be some different SE DI framework emerge as a JSR, but more to the point, there's a much much greater likelihood that regardless of technical merit (which, btw, I'm not suggesting is not present with abundance in Web Beans), some simple extension of Web Beans will become the de facto SE standard. To be honest, I don't have a point here, but I guess I'm saying that potential SE extensions are something you should consider, even if your position is that you don't have a mandate for anything other than a being a unified component model for Java EE.
One final thing, as far as naming goes... @In: possibly @Requires? It indicates a dependency that must be fulfilled and, at least to me, indicates one that might or might not exist yet (and so might have to be created). It also has the benefit of feeling a bit like a generalisation of the existing (probably badly named) @Resource.
Btw -- in the 'Post Comment' section, 'response' is spelt incorrectly in the 'Enter response' captcha replacement field label. I feel like it's only reasonable that I be anally retentive when commenting on a post that describes an upcoming JSR. :-p
Obviously feel free to delete this post -- its only purpose is to bring it to your attention, not to stand here for all time making fun of spelling errors!
Removing @Out gets you partway there. However, you still need to account for injection of narrower-scoped objects into objects with wider scopes. The path we've decided to go down is to proxy the injected object, and lookup the current object each time the proxy is called.
How about @Inject instead of @In?
BTW the tab index on your post comment form skips the comment section. It goes Name, Email Homepage, Subject, Enter response,Post Comment button, then up to the first link on the page.
Damn @Out is not in Web Beans?! Sort of kills this idea I have of distributed stateless web beans aggregated in one application.