Rick

Rick
Rick

Tuesday, March 29, 2011

Dependency Injection - An Introductory Tutorial Part 1 | Javalobby

CDI is the Java standard for dependency injection (DI) and interception (AOP). It is evident from the popularity of DI and AOP that Java needs to address DI and AOP so that it can build other standards and JSRs on top of it. DI and AOP are the foundation of many Java frameworks, and CDI will be the foundation of many future specifications and JSRs.

This article discusses dependency injection in a tutorial format. It covers some of the features of CDI such as type safe annotations configuration, alternatives and more. This tutorial is split into two parts, the first part covers the basis of dependency injection, @Inject, @Produces and @Qualifiers. The next part in this series covers advanced topics like creating pluggable components with Instance and processing annotations for configuration.

CDI is a foundational aspect of Java EE 6. It is or will be shortly supported by Caucho's Resin, IBM's WebSphere, Oracle's Glassfish, Red Hat's JBoss and many more application servers. CDI is similar to core Spring and Guice frameworks. Like JPA did for ORM, CDI simplifies and sanitizes the API for DI and AOP. If you have worked with Spring or Guice, you will find CDI easy to use and easy to learn. If you are new to Dependency Injection (DI), then CDI is an easy on ramp for picking up DI quickly. CDI is simpler to use and learn.

CDI can be used standalone and can be embedded into any application.

Source code for this tutorial, and instructions for use.

It is no accident that this tutorial follows this Spring 2.5 DI tutorial (using Spring "new" DI annotations) written three years ago. It will be interesting to compare and contrast the examples in this tutorial with the one written three years ago for Spring DI annotations.



Design goals of this tutorial


This tutorial series is meant to be a description and explanation of DI in CDI without the clutter of EJB 3.1 or JSF. There are already plenty of tutorials that cover EJB 3.1 and JSF with CDI as a supporting actor.

CDI has merit on its own outside of the EJB and JSF space. This tutorial only covers CDI. Repeat there is no JSF 2 or EJB 3.1 in this tutorial. There are plenty of articles and tutorials that cover using CDI as part of a larger JEE 6 application. This tutorial is not that. This tutorial series is CDI and only CDI.

This tutorial only has full, complete code examples with source code you can download and try out on your own. There are no code snippets where you can't figure out where in the code you are suppose to be.

We start out slow, step by step and basic. Then once you understand the fundamentals, we pick up the pace quite a bit.

All code examples have actually been run. We don't type in ad hoc code. If it did not run, it is not in our tutorial. We are not winging it.

There are clear headings for code listings so you can use this tutorial as a cookbook when you want to use some feature of CDI DI in the future. This is a code centric tutorial. Again, the code listings are in the TOC on the wiki page so you can find just the code listing you are looking for quickly like an index for a cookbook.

Decorators, Extentions, Interceptors, Scopes are out of scope for this first tutorial. Expect them in future tutorials.

If this tutorial is well recieved and we get enough feedback through, the JavaLobby articles, our google group and comments section of the wiki then we will add a comprehensive tutorial on CDI AOP (Decorators and Interceptors) and one on Extentions. The more positive and/or constructive feedback we get the more encouraged we will be to add more.



Dependency Injection


Dependency Injection (DI) refers to the process of supplying an external dependency to a software component. DI can help make your code architecturally pure.

It aids in design by interface as well as test-driven development by providing a consistent way to inject dependencies. For example, a data access object (DAO) may depend on a database connection.

Instead of looking up the database connection with JNDI, you could inject it.

One way to think about a DI framework like CDI is to think of JNDI turned inside out. Instead of an object looking up other objects that it needs to get its job done (dependencies), a DI container injects those dependent objects. This is the so-called Hollywood Principle, "Don't call us‚" (lookup objects), "we'll call you" (inject objects).

If you have worked with CRC cards you can think of a dependency as a collaborator. A collaborator is an object that another object needs to perform its role, like a DAO (data access object) needs a JDBC connection object for example.



Dependency Injection-`AutomatedTellerMachine` without CDI or Spring or Guice


Let's say that you have an automated teller machine (ATM, also known as an automated banking machine in other countries) and it needs the ability to talk to a bank. It uses what it calls a transport object to do this. In this example, a transport object handles the low-level communication to the bank.

This example could be represented by these two interfaces as follows:

See the rest at:
Dependency Injection - An Introductory Tutorial Part 1 | Javalobby

Monday, March 28, 2011

Announcing CDI Source

We decided to create an organization, named CDISource, to promote the use of CDI. This organization is not tied to any vendor nor to Java EE 6.

It did not take too long digging into CDI before I realized that Java Enterprise Edition 6 really nailed it this time. I have been a long time anti-EJB3 proponent. The interception model was flawed. The DI was flawed (or rather missing). CDI looks much better.

CDI is the Java standard for dependency injection (DI) and interception (AOP). It is evident from the popularity of DI and AOP that Java needs to address DI and AOP so that it can build other standards and JSRs on top of it. DI and AOP are the foundation of many Java frameworks, and CDI will be the foundation of many future specifications and JSRs.

CDI has merit on its own outside of the EJB and JSF space. Of course you can use CDI with JSF 2 and/or EJB 3.1. However CDI has a much wider scope than just Java EE 6 applications.

CDI is a foundational aspect of Java EE 6. It is or will be shortly supported by Caucho's Resin, IBM's WebSphere, Oracle's Glassfish, Red Hat's JBoss and many more application servers. CDI is similar to core Spring and Guice frameworks.

Like JPA did for ORM, CDI simplifies and sanitizes the API for DI and AOP. If you have worked with Spring or Guice, you will find CDI easy to use and easy to learn. 

If you are new to Dependency Injection (DI), then CDI is an easy on-ramp for picking up DI quickly. CDI is simpler to use and learn.

Although the ideas behind CDI are fundamentally sound, there are some missing pieces that can make it hard for adoption. CDISource aims to try to fill some of those missing pieces through tutorials, maven archetypes, and our open source library. We want to make the on-ramp for CDI easier by reducing the learning curve. CDI is nascent yet very promising.

Already CDISource has added support for doing unit testing (out of a Java EE container) with CDI. We did this by providing a standard interface for client side CDI so you can use Resin Candi, Seam Weld or Apache OpenWebBeans (all open source implementations of CDI).


In the last few weeks Andy Gibson, Rob Williams and I (Rick Hightower) (et al)  have been banging away on code, examples and ideas. We have come up with a mission statement (and a lot of working code).

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.
To support these efforts we have setup the following: tutorials wiki, CDI Advocacy webiste for news on CDISource, blog, vimeo for tutorial videos, tutorial that work with Eclipse WTP, google code project for examples, google group for support, and a github repo for our beancontainer and test frameworks.

CDISource is looking for experts and enthusiasts to sign up and volunteer their time. 


You can start by looking at my brand new introduction to CDI DI over on JavaLobby.

Also look at Andy Gibson's CDISource announcement. He is much more eloquent than I.

There is so much more to come.





    Kafka and Cassandra support, training for AWS EC2 Cassandra 3.0 Training