Women in Technology

Hear us Roar


Article:
  Using Dependency Injection in Java EE 5.0
Subject:   So what's new ?
Date:   2006-01-05 00:01:12
From:   GerritCap

Well this article is my first encounter with the new EJB specs and it is rather early in the morning so I might miss some important issues here but basically I don't see any difference between

Context ic = new InitialContext();
HelloWorld helloWorld = ( HelloWorld)ic.lookup("java:comp/env/ejb/HelloWorld");

and

@Resource(name="ejb/HelloWorld")
private HelloWorld helloWorld;


Okay, it looks different and you don't seen any InitialContext magic but to me it is still the same, this is not inversion of control as I appreciate it from Spring.


For me the prime reason to use IOC is that in a certain location I want to use an object implementing a certain interface but without having to determine at that location what object (of what exact concrete type) I am going to use. This functionality is basically already provided in the old J2EE specs as you lookup an object by name in the J2EE context. It is in the J2EE config where you define 'the" object suited to become the object implementing the desired interface. The same type of object lookup is also available in Spring by using its ApplicationContext and looking up a POJO bean by name.


Still the problem here is that this is not really IOC, its is an enhanced version of an implementation of the Interface Design Pattern. The problem as I see it is that sometimes you suddenly need 2 different objects of different types implementing a certain interface instead of just one. And if you developed your application by looking up objects by their configuration name. Example: an application uses a datasource to retrieve and store data. The data source is retrieved from the runtime environment using a single name AdventureDB. But then for some architectural reason 2 different databases are put into use and thus 2 differently configured datasources with 2 different names. Ok, it is simple to alter the code to use a different name in the lookup process. But if you used real IOC this wouldn't be necessary.


This is my second reason to use IOC in its full glory: in a spring based application where I need a datasource I provide a setter method to inject a datasource and in my spring config I define for a lot of different objects which datasource they need to use. Okay okay, if one object suddenly needs to use 2 different datasources this scheme also needs modification then.


Maybe the @Resource javax.ejb.TimerService ts; is a J2EE example of a more complete IOC as I just described it. But then the article is missing one element: where do you define the resource ? E.g. where in the new J2EE do you define the real class of which the resource is going to be a runtime instance of?


And finally one last remark which is not the issue of the article "Using dependency injection", where in J2EE 5.0 can I find Aspect Oriented Programming, which is the third reason I like Spring way over J2EE 1.4.


On the whole: a nice article on J2EE 5.0 but regarding J2EE 5.0 itself: too little too late.


Just my $.02
Main Topics Oldest First

Showing messages 1 through 3 of 3.

  • So what's new ?
    2006-05-05 00:22:13  pbpanther [View]

    The difference between these 2 is unit testing the bean/servlet.

    To test with an InitialContext you have to first set up a test context somehow then insert your mock/stub object into the the context.

    With dependency injection there is no dependency on an InitialContext in your code, so all you have to do is inject your mock/stub implementation of HelloWorld and you are testing.

    The reason for POJOs generally is so that you can unit test your code thoroughly and even program using TDD.
  • So what's new ?
    2006-03-28 23:23:44  NidhiTuli [View]

    The article didn't explain in details with example How to use dependency injection using XML in EJB3. Would it be possible to get more info or some links for the same. In our application we want to use dependency injection but at compile time we don't know which class it would be, so we can't use annotation. Doing dependency injection usin XML fits to our needs. Please suggest some example for the same.

    Thanks
    Nidhi
  • So what's new ?
    2006-01-05 13:12:24  DebaPanda [View]

    But then the article is missing one element: where do you define the resource ? E.g. where in the new J2EE do you define the real class of which the resource is going to be a runtime instance of? Here is what I've in the article:

    To use a field injection, simply define a field and annotate it to be a resource reference. If you don't define the resource's name and type, the container will derive this information from the field's name and type.

    You must have a resource e.g. DataSource configured in the data-source. Here is what I've in the article "In this example, a DataSource called AdventureDB should be available; if not, the container will throw an exception"

    I do not have any thing against Spring. I agree it has some demerits against containers like Spring but makes your code and configuration portable across any Java EE container. Spring configuration being proprietary is not portable and you have to stick with Spring.

    Setter injection is also supported with Java EE. If you are an XML fan you use XML instead of annotations as I described in the article. Also note that XML overrides annotation so you change your resource being injected.

    Anyway I don't think Spring is being touted as an alternative to Java EE, Spring is touted as a framework to be used with an Java EE container

    -Debu

Recommended for You
 
Sign up today to receive special discounts,
product alerts, and news from O'Reilly.
Privacy Policy >
View Sample Newsletter >