The first candidate release of Weld (1.0.0.CR1) comes hot on the heels of the announcement that the reference implementation for JSR-299: Contexts and Dependency Injection for Java EE specification was renamed, both of which have been once called Web Beans. This is a major milestone; for the project and for Java EE 6, as it represents a feature complete implementation of the JSR-299 (Proposed Final Draft 2) specification. The specification, implementation and TCK are being submitted to the JCP for the Final Draft ballot. You can find some convenient download links in the official announcement or you can pull the artifacts from the Maven central repository. The reference implementation, Weld, is used in GlassFish V3 and the upcoming JBoss AS 5.2.0.Beta1 release. Weld also adds support for Servlet containers such as Tomcat and Jetty. Furthermore you may choose to use Wicket as your view layer, or perhaps Swing via the Java SE support. If you are using an OSGi container, there's a bundle for that too! There are a couple of examples in the distribution to get you started. Whether you are strictly using JSF or you're exercising the full breadth of the Java EE platform, JSR-299 promises to provide a sturdy foundation for next generation applications that ties all of your components together. Now's your chance to give it a spin!

Congratulations Dan and the JBoss team for doing a fantastic job with both JSR 299 and Weld! Our JSR 299 implementation, CanDI, is well on it's way too... Cheers, Reza -------------------------------------------------------------- Independent Consultant Author, EJB 3 in Action Expert Group Member, Java EE 6 and EJB 3.1 Resin EJB 3.1 Lite Container Lead

Yes!!! Now Wicket and Java EE 5 can be even closer, particularly EJB3. Thanks JCP.

I would have thought Wicket was already the perfect match for EJB3 since EJB references are like the Detachable model that Wicket uses. You can hold on to the EJB reference which is just a stub, and when the page re-loads, the EJB stub would magically re-attach to the EJB (persistence contexts and all). I even wrote my own basic EJB injector for Wicket the other week without any problems. Great news on Weld though, for use in Glassfish would I still need to download the CR1 version or is it already up to date/updateable through the Glassfish updater? Cheers, Andy Gibson

I would have thought Wicket was already the perfect match for EJB3 since EJB references are like the Detachable model that Wicket uses. You can hold on to the EJB reference which is just a stub, and when the page re-loads, the EJB stub would magically re-attach to the EJB (persistence contexts and all). I even wrote my own basic EJB injector for Wicket the other week without any problems.

Great news on Weld though, for use in Glassfish would I still need to download the CR1 version or is it already up to date/updateable through the Glassfish updater?

Cheers,

Andy Gibson

You're correct on the EJB stuff mentioned. Wicket does work with EJB3 pretty ok, and has and if you use the EJB injector anonation from the wicket-contrib-javaee-1.1.jar you will be flying. No need to mess with JNDI for EJB lookups. But as far as things like default/seamless JAAS support is concerned between the EJB container and Wicket running in the presentation layer, that's not supported since Wicket is a layer on top of low level servlets. You'll have to roll your own solution when it comes to Java EE 5 role based security for accessing protected EJB3 methods. So I'm guessing JSR 299 will help plug that gap.

Great news on Weld though, for use in Glassfish would I still need to download the CR1 version or is it already up to date/updateable through the Glassfish updater?

Cheers,

Andy Gibson

You can get the Weld CR1 in any recent build of GlassFish V3, such as b70 :-)

Erlang is king

Erlang is king

What are you smoking? (and no, I don't want any)

Funny, I just finished an Erlang/OTP project. Couldn't wait to get back to a proper language like Java. Not to mention the Java performance beats Erlang...soundly. All the crap they put in their 5-year old benchmarks is just that...crap. P.S. Ever tried connecting from Erlang to an Oracle DB? Good luck.

I connect to Oracle every day: odbc:start(). {ok, Ref} = odbc:connect("DSN=sql-server;UID=aladin;PWD=sesame", []). odbc:sql_query(Ref, "CREATE TABLE EMPLOYEE (NR integer,FIRSTNAME char varying(20), LASTNAME char varying(20), GENDER char(1),PRIMARY KEY(NR))"). odbc:sql_query(Ref, "INSERT INTO EMPLOYEE VALUES(1, ’Jane’, ’Doe’, ’F’)"). Look how sexy that is! You don't need Java, JDBC or Hibernate bloated garbage.

I think it is the good day to paraphrase this citation of Roy Fielding; "It even manages to one-up the previous all-time-idiocy of IBM when they renamed their CORBA toolkit "Web Services" in a deliberate attempt to confuse customers into thinking they had something to do with the Web."; as "It even manages to one-up the previous all-time-idiocy of JBoss when they renamed their Enterprise Java Beans stuff as "Web Beans" in a deliberate attempt to confuse customers into thinking they had something to do with the Web.";

"It even manages to one-up the previous all-time-idiocy of JBoss when they renamed their Enterprise Java Beans stuff as "Web Beans" in a deliberate attempt to confuse customers into thinking they had something to do with the Web.";

I don't understand your point. JSR-299 is a Java dependency injection specification. Plenty of web applications use DI and can benefit from a DI standard.

"It even manages to one-up the previous all-time-idiocy of JBoss when they renamed their Enterprise Java Beans stuff as "Web Beans" in a deliberate attempt to confuse customers into thinking they had something to do with the Web.";

I don't understand your point. JSR-299 is a Java dependency injection specification. Plenty of web applications use DI and can benefit from a DI standard.

I'll hazard a guess. It's like calling a steak 'dog food' because a dog could eat it. Is every potential use of WebBeans necessarily part of a web app?

I'll hazard a guess. It's like calling a steak 'dog food' because a dog could eat it. Is every potential use of WebBeans necessarily part of a web app?

True, it's now more general, which is a reason the name changed to "contexts and dependency injection". The original idea (two years ago!) was pretty heavily tied into JSF, which is a web-only technology. The current spec is a major improvement over the original ideas.

"It even manages to one-up the previous all-time-idiocy of JBoss when they renamed their Enterprise Java Beans stuff as "Web Beans" in a deliberate attempt to confuse customers into thinking they had something to do with the Web.";

I don't understand your point. JSR-299 is a Java dependency injection specification. Plenty of web applications use DI and can benefit from a DI standard.

I'll hazard a guess. It's like calling a steak 'dog food' because a dog could eat it. Is every potential use of WebBeans necessarily part of a web app?

This has to be *THE* lamest bashing of JSR-299 I have ever heard.

I'll hazard a guess. It's like calling a steak 'dog food' because a dog could eat it. Is every potential use of WebBeans necessarily part of a web app?

The original purpose of the JSR was very web-application oriented. (Go read the original JSR proposal.) Therefore, the old name was extremely fitting. In the past 3 years, the spec evolved to something more general. Therefore, the new names for the spec and RI are arguably more fitting. However, there are still several features of the spec which are quite web oriented, and I expect to see 299 widely adopted in the area of web application development.

I'll hazard a guess. It's like calling a steak 'dog food' because a dog could eat it. Is every potential use of WebBeans necessarily part of a web app?

The original purpose of the JSR was very web-application oriented. (Go read the original JSR proposal.) Therefore, the old name was extremely fitting.

In the past 3 years, the spec evolved to something more general. Therefore, the new names for the spec and RI are arguably more fitting. However, there are still several features of the spec which are quite web oriented, and I expect to see 299 widely adopted in the area of web application development.

Just to be clear. I don't really care if you call it 'WebBeans' or 'PintoBeans' or 'BrazilNuts'. I was just throwing out a theory of what someone else had an issue with.

While looking through the Weld examples, and the older WebBeans documentation, it looks like a competitor to the new @ManagedBean JSF 2.0 annotations. Is there any information on when we'd want to use one over the other?

While looking through the Weld examples, and the older WebBeans documentation, it looks like a competitor to the new @ManagedBean JSF 2.0 annotations. Is there any information on when we'd want to use one over the other?

Steven, @ManagedBean and JSR 299 are complementary. That being said, I think @ManagedBean makes sense for applications that do not use JSR 299 or when you want to keep a level of de-coupling between JSF and JSR 299. Hope it helps, Reza ------------------------------------------------------------ Independent Consultant Author, EJB 3 in Action Expert Group Member, Java EE 6 and EJB 3.1 Resin EJB 3.1 Lite Container Lead

@ManagedBean and JSR 299 are complementary. That being said, I think @ManagedBean makes sense for applications that do not use JSR 299 or when you want to keep a level of de-coupling between JSF and JSR 299.

Thanks for responding Reza. The question I was trying to get at is that @ManagedBeans handle dependency injection. My assumption is that Weld/JSR-299 provides more sophisticated features for JSF2 users. I was inquiring as to what those features might be. In particular, I was hoping someone who is more familiar with the project can provide some "bottom-line" examples that would be readily understandable by a conventional JSF user.

It's difficult to answer this question without revealing some warts. The simple answer is that a class which is picked up as a bean by CDI implicitly has the @ManagedBean annotation. With or without the annotation, the class falls under the new managed bean specification, which is an offshoot from the Java EE 6 specification. If CDI is not present, JSF manages the life cycle of the bean. If CDI is present, then it takes over. At last, managed beans have been unified in Java EE! The trouble is that JSF still provides a dependency injection facility which is not aligned with CDI, or the rest of Java EE for that matter. The injection I speak of is declared by the @ManagedProperty annotation. What anyone from the Red Hat camp will tell you is that you should basically stop using the JSF injections and use CDI instead. Because of the way CDI is designed, it likely has a lower overhead (or, at the very least, the same). The other major issue is that the @ManagedProperty injections are not contextual, meaning they create hard references (assignments) rather than being managed by a proxy. So in the end, use @Named (to give the CDI bean an EL name) instead of @ManagedBean when using JSF in Java EE 6 (or use a Weld extension to use CDI in a servlet environment). Eventually, we will clean up the divergence in JSF, hopefully in JSF 2.1. Only so much can be solved in one iteration...and trust that there has been a lot of problem solving going on. I hope that helps!

The other major issue is that the @ManagedProperty injections are not contextual, meaning they create hard references (assignments) rather than being managed by a proxy.

I tried to explain them that properties managed without a proxy are pretty useless. They are good only for the HelloWorld application. JSF team thinks that an old style managed property is better then nothing, but I don't think so because it introduces further useless confusion.

I was inquiring as to what those features might be.

Steven, I hope the responses above answered your question somewhat. Just to make sure, JSR-299 provides a much richer set of dependency injection features more in line with Spring, Guice, Seam, etc. Some key features are type-safety, qualifiers, stereotypes, producers, disposers, declarative scope/life-cycle management, an SPI (bean resolution programmatic API if you will), events, etc. That being said, it might be the case that @ManagedBean coupled with @Resource, @EJB, etc are sufficient for your purposes or is a good starting point. I do strongly suspect that you would opt to use JSR-299 if it is available. It really is a good API, you should give the spec a read for now. Once things get settled down for Java EE 6, I was planning on writing something on TSS describing JSR 299...hopefully that will help. Cheers, Reza ------------------------------------------------------------ Independent Consultant Author, EJB 3 in Action Expert Group Member, Java EE 6 and EJB 3.1 Resin EJB 3.1 Lite Container Lead

I do strongly suspect that you would opt to use JSR-299 if it is available.

Absolutely. I am an easy sell and have no issue with it. However, I have to answer to those who pay my salary. When adding another technology to our applications, I need to justify its technical merits, especially since it would be a replacement for well established technologies, like Spring.

I need to justify its technical merits, especially since it would be a replacement for well established technologies, like Spring.

Steven, If that's the case, you might find my recent JBossWorld talk helpful as an aid to coming up with your own conclusions: http://www.redhat.com/f/pdf/jbw/rrahman_320_spring_framework.pdf. The presentation uses JSR 299 heavily. Hope it helps, Reza ------------------------------------------------------------ Independent Consultant Author, EJB 3 in Action Expert Group Member, Java EE 6 and EJB 3.1 Resin EJB 3.1 Lite Container Lead

While looking through the Weld examples, and the older WebBeans documentation, it looks like a competitor to the new @ManagedBean JSF 2.0 annotations. Is there any information on when we'd want to use one over the other?

It's a good question, and I'm not really in full agreement with the answers that have been posted so far. The new EE Managed Beans specification defines a base component model for Java EE, together with a very basic set of container services (@Resource, @PostConstruct, @PreDestroy). The idea is that other specifications (beginning with EJB, CDI, JSF and the new Java Interceptors spec) build upon this base component model and layer additional services, for example transaction management, typesafe dependency injection, interceptors. So at this level, the managed beans, CDI, interceptors and EJB specifications all work hand-in-hand and are highly complementary. Now, the Managed Beans specification is quite open-ended with respect to identifying exactly which classes are managed beans. It does provide the @ManagedBean annotation as one mechanism, but it also allows other specifications to define different mechanisms. So, for example: * The EJB specification says that a class obeying certain programming restrictions with a @Stateless or @Stateful annotation deployed in an EJB jar is a managed bean. * The CDI specification says that any class with an appropriate constructor deployed in a "bean deployment archive" is a managed bean. Given that EJB and CDI provide arguably more convenient ways to identify a managed bean, you might wonder precisely what @ManagedBean is needed for. The answer, as alluded to by Dan, is that if you have CDI available in your environment (for example, if you are using EE6), then @ManagedBean is just not really needed. @ManagedBean is really there for use by people who are using JSF2 without CDI. OTOH, if you do annotate a bean @ManagedBean, and you do have CDI in your environment, you can still use CDI to inject stuff into your bean. It's just that the @ManagedBean annotation is not *required* in this case. To summarize, if you do have CDI available to you, it provides a *far* superior programming model to the @ManagedBean/@ManagedProperty model that JSF2 inherits from JSF1. So superior, in fact, that the EE 6 web profile does not require support for @ManagedProperty etc. The idea being that you should just use CDI instead.

Some relevant discussion here: http://www.seamframework.org/Community/JSR299VsManagedBeanInJSF20#comment101504