Discussions

News: Web Beans and the EE platform

Bookmark and Share Get thread feed

  1. Web Beans and the EE platform (1 messages)

    If there's one thing that we really want to get right as Web Beans goes from Public Draft to Proposed Final draft, it's integration with the Java EE platform. Up to this point, most of the work we've been doing as an EG was focused on nailing down the programming model, the semantics of the Web Beans services, and the behavior of the Web Bean manager. We've been writing the spec to assume that Web Beans implementations should be pluggable between different Java EE containers, because this is a direction that a lot of folks in the Java EE community believe that the EE platform should move in, and because we would like Web Beans to help show the way for other specifications such as EJB, JTA and perhaps even Servlets (note that JPA and JSF already support this). Since the release of the Public Draft, our main focus has shifted to the integration problem. Web Beans generated a bunch of controversy when the draft was circulated to the EE platform expert group and proposed by Sun for inclusion in the Web Profile. That's not surprising - Web Beans solves some very important problems that lots of people have strong opinions on. I've also had a number of more technical discussions with the EE and EJB spec leads and with the EJB expert group. A number of concerns have emerged, which we're now attempting to address. Let me share my take on these issues, and some directions we might pursue. More...
    Reply to this

    Threaded Messages (1)

  2. Lack of full DI is problematic to whole platform[ Go to top ]

    Lack of full DI support has really hurt the EE platform. I really felt this pain while on the JAX-RS expert group and leading the JBoss Resteasy project. From the JAX-RS EG/JSR perspective, lack of DI hurt us (IMO) because we needed fine-grain configuration and injection of plain Java objects. Particularly for adding support for JAXB. What ended up happening is that an ad-hoc, use-case specific model was introduce that was specific to JAX-RS. (ContextResolver). It would have been so much better if we had Web Beans available to provide this fine-grain injection rather than writing our own ad-hoc solution. From a RESTEasy perspective, I needed a way to configure the framework. What I didn't want was to have a Seam, Guice, or Spring dependency enforced on Seam, Guice, or Spring users. I also didn't want to implement/maintain/document 3 different ways of bootstrapping and configuring RESTEasy all just to do some simple configuration. Finally, the last amazing thing about the specification is that because it permeates into specifications like EJB and Servlet, future domain-specific injection frameworks like JAX-RS could easily be integrated in a portable manner into all of EE fairly easily because Web Beans provides the facilities and integration points to do this. I'm really excited about re-implementing Resteasy in terms of Web Beans and see how this could affect my extensibility. Java EE needs to become a living breathing specification that encourages innovation by providing the integration points and facilities for new third-party frameworks. I believe Web Beans can be a large part of the story here. Combined with the pluggability aspects that other JSRs like EJB, JCA, and other specifications are doing, EE 6 could add years to the viability to the Java EE platform. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com
    Reply to this Reply to original