Help

/This is the third installment of a series of articles describing the current status of the Web Beans specification. You can find the first installment here and the second installment here./

So far, we've seen plenty of examples of components declared using annotations. However, there are a couple of occasions when we can't use annotations to define the component:

  • when the implementation class comes from some pre-existing library
  • when there should be multiple components with the same implementation class

In either of these cases, Web Beans gives us two options:

  • write a /resolver method/
  • declare the component using XML

In a future installment we'll talk more about all the crazy kinds of things we can do with resolver methods. First, let's just prove that Web Beans is not entirely annotation-centric.

We can declare a component in web-beans.xml:

<component>
    <class>java.util.Date</class>
</component>

Then an instance of Date could be injected by another component:

@In Date date;

By default, any component declared in XML has the component type @Component. We can use a custom component type:

<component>
    <class>java.util.Date</class>
    <type>org.jboss.test.Mock</type>
</component>

We can override the default component name:

<component>
    <class>java.util.Date</class>
    <name>now</name>
</component>

Or we can specify a scope for the component:

<component>
    <class>java.util.Date</class>
    <scope>javax.webbeans.SessionScoped</scope>
</component>

We can even specify binding annotations using XML, to distinguish between multiple components with the same implementation class:

<component>
    <class>java.util.Date</class>
    <name>now</name>
    <binding>org.jboss.eg.Now</binding>
</component>

<component>
    <class>java.util.Date</class>
    <name>logInTime</name>
    <scope>javax.webbeans.SessionScoped</scope>
    <binding>org.jboss.eg.LogInTime</binding>
</component>

<component>
    <class>java.util.Date</class>
    <name>startupTime</name>
    <scope>javax.webbeans.ApplicationScoped</scope>
    <binding>org.jboss.eg.StartupTime</binding>
</component>

Where @Now, @LogIn and @Startup are binding annotations used at the injection points:

@In @Now Date currentTime;
@In @LogInTime Date loginTime
@In @StartupTime Date startupTime

As usual, a component may support multiple binding annotations:

<component>
    <class>org.jboss.eg.AsynchronousChequePaymentProcessor</class>
    <binding>org.jboss.eg.PayByCheque</binding>
    <binding>org.jboss.eg.Asynchronous</binding>
</component>

Eventually, Web Beans will also support XML-based configuration of component properties, using literal or EL values, something like this:

<component>
    <class>org.jboss.framework.Captcha</class>
    <property name="strategy">math2digit</property>
    <property name="language">#{user.language}</property>
</component>

However, we've not yet worked out all the details of this. In particular, I would love to support a namespaced approach to component configuration, as seen in Seam or Spring 2.0.

6 comments:
23. Sep 2007, 18:38 CET | Link

After reading all three of these articles, WebBeans looks to be a very interesting dependency injection and context resolution mechanism. It appears currently to be potentially unique in its ability to intelligently resolve dependencies based simply on declaration of what a particular component requires or provides. Looks great.

One question that really interests me. This appears to be a completely generic dependency injection and resolution mechanism, which I should be able to use anywhere, not just in a web container. For instance, this would still be hugely applicable in a Swing GUI application, or some other situation which is not using JavaEE frameworks (not using JSF basically). I read in the first article that it should be able to run outside the container, so I guess this should be possible?

In which case the name WebBeans is slightly unfortunate, but I'm concerned more with how I can use it than getting hung up on the name :)

ReplyQuote
23. Sep 2007, 19:06 CET | Link

Should have read the other comments. I can see this is not a priority right now.

I think the community pressure is there at least..

24. Sep 2007, 04:28 CET | Link
Ryan de Laplante

I too would like to see this available to Java SE applications one day. If this is a future possibility, the name Web Beans doesn't fit.

Simon, I don't think that Web Beans is tied to JSF. You could use any web framework or even servlets to work with these components. Also, I don't think the components need to be Java EE components such as servlets and EJBs. They can be any POJO.

 
24. Sep 2007, 20:13 CET | Link
Sakuraba

I would go as far as saying that a mechanism like that would be a huge help in many aspects of Java development just like JPA.

Seam core could then become some kind of RI for Java BeanComponent API aka formerly known as Web Beans.

Alright... the name sucks badly, but you get the idea...

 
25. Sep 2007, 10:42 CET | Link
Ryan de Laplante

I think I now understand why it is called WebBeans. The standard scopes that come with it might only be usable in the context of a web container. Request, Session, Conversation and Application. To make those scopes work outside of a web container (for example, a Swing application) they might need completely different code under the hood. I still think that the name should be changed to something more generic.

 
25. Sep 2007, 13:38 CET | Link
I think I now understand why it is called WebBeans. The standard scopes that come with it might only be usable in the context of a web container. Request, Session, Conversation and Application. To make those scopes work outside of a web container (for example, a Swing application) they might need completely different code under the hood. I still think that the name should be changed to something more generic.

Yes, but note that since Web Beans has an extensible context model, the built-in contexts are really just a layer over the core engine. Just because we have built-in contexts that are well-defined in the Web environment does not mean that the engine is tied to the web.

Post Comment