|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 26
Messages: 26
Messages: 26
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Weld 1.0.0.CR1 (formerly Web Beans) is released
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!
|
|
|
Message #326851
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Weld 1.0.0.CR1 (formerly Web Beans) is released
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
|
|
|
Message #326854
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
+1 for Wicket
Yes!!! Now Wicket and Java EE 5 can be even closer, particularly EJB3. Thanks JCP.
|
|
|
Message #326858
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Wicket and EJB
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
|
|
|
Message #326864
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Wicket and EJB
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.
|
|
|
Message #327149
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Weld 1.0.0.CR1 (formerly Web Beans) is released
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.";
|
|
|
Message #327159
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Weld 1.0.0.CR1 (formerly Web Beans) is released
"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.
|
|
|
Message #327165
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Weld 1.0.0.CR1 (formerly Web Beans) is released
"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?
|
|
|
Message #327170
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Weld 1.0.0.CR1 (formerly Web Beans) is released
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.
|
|
|
Message #327171
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java Blows!
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.
|
|
|
Message #327175
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Comparisons to @ManagedBean annotations in JSF2?
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?
|
|
|
Message #327177
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java Blows!
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.
|
|
|
Message #327179
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Weld 1.0.0.CR1 (formerly Web Beans) is released
"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.
|
|
|
Message #327180
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Comparisons to @ManagedBean annotations in JSF2?
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
|
|
|
Message #327183
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
When is JSR 299 preferred for JSF users?
@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.
|
|
|
Message #327185
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
CDI and the relationship to @ManagedBean
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!
|
|
|
Message #327329
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Weld 1.0.0.CR1 (formerly Web Beans) is released
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.
|
|
|
Message #327387
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Comparisons to @ManagedBean annotations in JSF2?
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.
|
|
|
Message #327467
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Weld 1.0.0.CR1 (formerly Web Beans) is released
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.
|
|
|
Message #327469
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: When is JSR 299 preferred for JSF users?
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
|
|
|
Message #327499
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
agreed
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.
|
|
|
Message #327512
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: agreed
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
|
|
|
Message #327625
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: CDI and the relationship to @ManagedBean
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.
|
|
|
Message #328504
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Weld in GlassFish V3
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 :-)
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman continues to explore the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(January 21, Article)
Ted Neward is an independent consultant specializing in high-scale enterprise systems, and an authority in Java and .NET technologies. He is the author and co-author of several books, including Effective Enterprise Java. At TheServerSide Java Symposium in March, he will be presenting sessions on pragmatic architecture, ECMAScript and Scala.
(January 15, Article)
Now that Oracle is absorbing Sun Microsystems, there mixed views on what should come of the Java Community Process (JCP). While some say Oracle should become the new steward of Java and keep the JCP much as it was, others argue that it may be time to open-source this widespread language.
(November 24, Article)
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
Download the entire book of Jakarta-Struts Live and learn about Struts MVC, Tiles, the Validator, DynaActionForms, plug-ins, internationalization, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
