There’s still a lot of confusion over the difference types of managed beans provided in Java EE 6 with EJBs, CDI beans and JSF managed beans all being available. This article aims to clear up some of the differences between the them and define when to use them. (more…)
In the last few weeks I have been rather busy working on a new project with Rick Hightower, who is fairly well known for his training and writings on Spring and JSF, and Rob WIlliams who is a blogger known as much for meddling in new technologies (and getting mad at them) as he is for intertwining various historical and literary references in his posts. The result of this is the CDISource project which aims to advocate and facilitate the use of the JSR 299 – Java Contexts and Dependency Injection framework across the Java landscape.
If you’ve seen my posts or my site before, you’ll no doubt be aware that I have written at great length about Java EE 6, JSF, CDI , EJB and so on. What I haven’t written about is the many frustrations I’ve come up against in dealing with these frameworks on their own and especially when combined, or how their usefulness is often constrained to the application server container.
Java EE in some ways is an archipelago of frameworks that lacks the cohesiveness and all in one wide screen vision that software developers need. Java EE is about the enterprise, in reality its about the web, or even more specifically about Java EE containers. There’s a whole slew of uses for a good type safe and flexible dependency injection and AOP framework and such as CDI outside of Java EE containers but there is very little information and code to make it actually work.
Our goal is to make CDI useful and usable on its own without Java EE 6, and to give developers the tools and information to do so. To let them write vendor neutral and portable code, and apply agile and best practices. Developers know how to write good software and don’t want to sacrifice that for the sake of using a framework to make things easier. To that end we aim to provide code and information that will help facilitate those practices.
There will be some learning for ourselves along the way and we will have to change some of our previously held concepts. I know over the last few weeks having been getting CDI working and useful outside of the web container it has really altered my perspective on how I think about the dependencies and structure in CDI applications. My perspective has changed even more than when I wrote A Little Less Conversation.
As much as I hate to say it, we did come up with a mission statement, although we found it fairly easy and enjoyable to clearly defined the goals and attitudes of the project.
Our mission is to :
- Promote and facilitate the use of the Java Context and Dependency Injection (CDI) framework in relation to as many aspects of application development as possible.
- Enable developers to take advantage of CDI independently of Java EE.
- Provide lightweight, lean and agile access to the underlying CDI container as a core principle in our efforts.
- Make testing easy without requiring a complex set of tools or complex deployment scenarios.
- Enhance both Java EE development as well as the use of CDI in non Java EE application where possible.
- Promote and enable the use of CDI in a vendor neutral environment and maximize the portability of application code across CDI implementations.
- Not reject the ideas of Java EE but expand the usability of CDI outside the borders of Java EE application servers with frameworks that are not a part of the specification.
- Not reject other CDI efforts but to provide another venue to promote those efforts. This is an addition. This is another voice in support of CDI.
We are pretty excited that so far we have been able to live up to the intent of our mission statement with everything we’ve done so far. Over the next few days and weeks you will see articles and tutorials come out of Rick, Rob and I as we write about the CDISource project and we start to showcase some of the code we have written and start giving you an idea of where we are heading.
Right now we have vendor neutral support for starting up CDI outside of the web container and also for testing CDI beans with minimal configuration and intrusion on your test cases. We also have a few other pieces that are nearly ready, as well as dozens of ideas to get started on.
You can start by looking at Ricks brand new introduction of CDI over on JavaLobby.
Arquillian, JBoss’ foray into providing in-container testing for Java EE projects, could be used to give Java EE container developers the ability to test their containers using a set of tests based on expected Java EE behavior. Such tests will enable developers of the next generation of application servers to not only run unit and integration tests on their contains but can be used to ensure compliance with the Java EE spec. It would be especially useful for integration testing where different frameworks are developed in isolation leading to integration issues when it gets out to the public.
In an ideal world, the Java EE vendors could get together and share a common open set of tests to ensure that they are all following the same rules of the spec, almost like an informal TCK. Having such a set of tests would ensure higher quality application servers are turned out in a faster time. Going from Java EE 5 to Java EE 6 was quite a big leap, I don’t think anyone is expecting as much of a leap from Java EE 6 to 7 or 8, so now would be a good time to consider those options.
This is one of those things where everybody gains. All the vendors get the benefits of product improvement due to the unit tests and they all get the benefits of Java EE having a better reputation as a solid, portable framework with more timely releases.
This set of articles will document the contents of the Java EE archetypes for Maven. The archetypes come in four flavors, basic,minimal, sandbox and sandbox demo with each one being based on the previous one. In part 1, we’ll give an overview of the archetypes and the structure and configuration used in all of the archetypes. (more…)
Last time we looked more in depth at CDI and how we can define beans and inject them into other beans. This time we are going to look at how we can use events to decouple the handling of actions in the system.
In part 1, we looked at creating a JEE 6 application with Netbeans using JSF and CDI running on Glassfish. Now we’ll take a closer look at using CDI for managing dependencies in a Java EE 6 environment.
Here’s a quick tutorial on how easy it is to get started with JSF 2.0 and JSR 299, Java Contexts and Dependency Inject (CDI) using the latest release of Netbeans 6.8.
Like Christmas come early, Sun announced the release of JEE 6. This release sees continued improvement in the JEE stack with the inclusion of JSR 299, Java Contexts and Dependency Injection (CDI), and EJB 3.1 as well as JSF 2.0, and JPA 2.0. JSF especially has seen changes as a result of practical user feedback and community add-ons such as Seam and JSF Ajax frameworks which have contributed back to the JCP.
Glassfish v3 which implements the full JEE 6 stack has also been released, with JBoss’ Weld as the CDI implementation. Netbeans 6.8 has also been released with full JEE 6 project support including maven support for enterprise applications. Also of note is the hot deploy function of Glassfish which can deploy your app while maintaining session information.
Personally, I’m pleased. JEE 6 has really improved things for the java standards, and CDI has filled some gaps that previously required different additional pieces to completely fill. The ghosts of EJB 2.1 should now be permanently laid to rest, but should serve as a stark reminder. Having good frameworks to build standards based solutions is always good for the community.
I’ll try and get some tutorials on developing with CDI and JSF 2.0 with Netbeans and Glassfish out soon.
With Weld 1.0, the reference implementation of JSR 299 – Java Contexts and Dependency Injection now released, attention at JBoss has no doubt turned to Seam 3 which is going to be built on top of Weld. Red Hat and JBoss are committed to returning innovations back the JCP as is the case with Seam which not only resulted in JSR 299, but has also influenced a number of other JSRs especially JSF 2. With JSR 299 standardizing the Seam ’style’ of development it also brings about a some fundamental game changes for Seam 3 (hence the title) as much of the strength of Seam becomes part of the JEE standards.
I’ve spent some time in the last couple of weeks playing around with Glassfish, Netbeans 6.8 Beta (and milestone 2 before it) and JSF 2.0, and I have to say that this is turning out to be a really good set of development libraries and tools.