Gavin King on the impact of JSR-299 and Weld 1.0 on Java EE and JBoss __java

Gavin King on the impact of JSR-299 and Weld 1.0 on Java EE and JBoss

Author Charles Humble translator Zhang Long posted on November 23, 2009 11:24 P.M.

Shortly before, the JBoss Department of Red Hat released the context and dependency injection of Weld1.0.0--java EE 6 to JSR-299 (Java ee), contexts and Dependency injection for Java EE, later referred to as C DI) 's reference implementation. The weld implementation is used by Sun GlassFish Application Server v3 and the forthcoming JBoss as 5.2.0, but Weld does not require a complete application server. It can run in a servlet container, such as Jetty 6.1 or Tomcat 6, and can also be used in the Java SE 5.0+. To illustrate the latter point, the weld release package also includes an example console application and a swing application example.

After the first release of the draft JSR-299, Google and SpringSource jointly submitted JSR-330 to standardize "a time-tested and irrefutable set of annotations so that the injected class can span multiple frameworks", so I met the leader of the CDI specification Gavin King couldn't wait to ask him what effect JSR-330 had on CDI. CDI now uses the annotations defined by JSR-330 to declare the injection point. This effect is negligible because the 330 models used are basically the same as 299. It boils down to the difference between the name of the note.

Know that 330 does not define a complete dependency injection scheme. It only defines an injection point with modifiers, and nothing else is defined.

InfoQ: How CDI and EJB handle the managed bean model introduced by EE 6. The new managed Bean specification is the work of JSR-299 (what we call the "simple Web Bean" in the early drafts of the specification). Simple Web beans Support Dependency Injection, El Name and interceptor, but do not have EJB programming constraints.

The Managed Bean spec is a lot of controversy, and Red hat says we do need to support injection of ordinary Java classes, while other EE stakeholders express a great deal of discomfort with the 299 definition of such a new EE "component."

After many discussions, we believe that the idea of such a "simple" component should be a specification that makes up the basis of all other EE component programming models, including EJBS, and so on. This is a great vision, and we all agree with that, but EE 6 doesn't fully implement it.

The final result: CDI can be used in ordinary Java classes (now called "Managed Bean") and EJB. Today's EJB can be thought of as a special managed Bean, but with some additional programming constraints and functionality. This programming model can greatly reduce the new user learning EE curve.

InfoQ: Does the EJB need its own component model? I think the future direction of the EE platform is to gradually use the EJB-specific functionality and apply it to all managed beans. For example, why not all managed beans support @transactionattribute and @rolesallowed? It doesn't make any sense.

However, EJB has a place to define endpoints for message transmission, remote and asynchronous method calls, timers, and so on. In these cases, the EJB lifecycle model is very meaningful.

InfoQ: Seam creates inspiration for JSF 2 and CDI. Fixing these problems in JSF is better than solving them in seam. We have never really been satisfied in the process of trying to make the user experience transparent. Users always notice when to use JSF's features and when to use seam features that should be placed in JSF.

CDI originates from Red Hat's open source seam framework, which, broadly speaking, standardizes seam's programming model as the Java EE 6 programming model. CDI implements the 3 main purposes of Java EE 6. First, it provides a declarative way to manage the scope, state, and lifecycle of binding to context components. Second, it provides the platform with a standardized, annotation-driven, type-safe Dependency injection framework, similar to Google Guice. Finally, it provides service Provider Interface (SPI) for the extended development of the Java EE platform.

CDI's service Provider interface has become a key component of Java EE scalability, and scalability is a central issue in Java EE 6. JSR-316 specification says: ... We believe that everyone is eager to use these technologies on the Java EE Application Server, or in the form of plug-ins. By adding more extension points and service provider interfaces, other technologies can be used in the form of plug-ins for platform implementation, which is neat and efficient, and is very simple for developers to use, just like devices on the platform.

As you can see from the next edition of Seam (seam 3), seam 3 will be CDI as its core engine and use CDI service Provider interface to provide many of the features not covered in CDI, such as BPM integration, drools integration, PDF and Email template support as well as Excel generation and so on. These extensions (also including other extensions provided by Third-party vendors) can be run in any environment that supports JSR-299, including any Java EE 6 environment. The CDI specification says: Portable extensions can be integrated with containers in the following ways:

• Provide your own beans, interceptors, and adorners.

• Injecting dependency into its own object through dependency injection services.

• Provides a context implementation for the customized scope (custom scope).

• Enhance or provide annotation based metadata through external annotations.

Gavin King said: The advent of CDI and JSF 2 foreshadowed seam's new direction.

In Seam 2, we spent a great deal of effort to fill the JSF vulnerabilities, resulting in the lack of time to integrate the presentation layer technology that attracted us very much. JSF 2 allows us to focus on other areas.

Most importantly, CDI now offers a core "engine" that can be ported between all EE 6 application servers and even on Tomcat, jetty, and resin. The core does not depend on any particular presentation layer technology. What it has is just a well-defined set of SPI for portable extension developers. The SPI serves as the foundation of the entire ecosystem. If you're a framework developer, it's now clear what you need to do to integrate the framework with the CDI and EE environments (through scaling). This may be the most exciting feature of CDI.

Seam 3 will become a CDI-portable extension that can be used on any application server and provide extensions to the CDI programming model while integrating with other technologies that we are interested in.

JBoss CTO Mark Little says CDI and seam will be the future direction of all of its projects and platforms: The team is working closely with these projects and platforms, such as ESB and soa-p, to ensure that new seam takes into account its specific requirements. Importantly, some projects already think seam is the right choice, even without making any changes, so it's easier to integrate tightly and quickly than you think.

King confirmed this and said: Red hat has successfully applied seam to some of the projects it has developed. CDI puts seam's core functionality on a solid foundation, and our implementation of CDI Weld is a more focused and well tested infrastructure. This means that we can apply weld to a variety of areas that are not suitable for seam 2, which is irrelevant to building a Web site.

In addition to Red Hat there are many other CDI implementation is about to break the cocoon into butterflies. The creator of the resin Caucho technology has an implementation (Candi), and the resin container itself uses a lot of CDI internally. Apache is also working on an implementation called Openwebbeans, and the Granite DS has an implementation that can apply CDI to flex applications as follows: We think JCDI is ideal for flex RIA for event-driven architecture. The JCDI application is very neat, and although JBoss seam provides a lot of features, there is no need to develop an RIA front-end.

View English Original: Q&a with Gavin King on the Impact of JSR-299 and Weld 1.0 on Java EE and JBoss

Transfer from: InfoQ Chinese station