Are you looking forward to annotation-based injection in Java EE 5.0?
You must be logged in to the O'Reilly Network to post a talkback.

Showing messages 1 through 13 of 13.

• One class != one object
  2007-05-01 10:06:33  docbillnet [Reply | View]
  
  
  Come on. The whole flaw with annotations is they assume each Object only has a single use. Presumably the reason why they are variables, and not constants in that they can take on different values.
  
  For example, consider if I had the following class:
  
  class DisplayMessage {
  Message message;
  Message setMessage(Message message) {
  this.message = message;
  }
  Message getMessage() { return message; }
  void displayMessage() {
  ... something complicated ...
  }
  }
  
  Now perhaps I have many other classes that need DisplayMessage objects injected. Some with different Message values?
  
  In Spring this is pretty easy. I just assign one resource name for each message object I will need, in inject the appropriate message.
  
  For example:
  <bean id="displayMessage1" class="Message">
  <property name="message" ref="message1"/>
  </bean>
  <bean id="displayMessage2" class="Message">
  <property name="message" ref="message2"/>
  </bean>
  <bean id="displayMessage3" class="Message">
  <property name="message" ref="message3"/>
  </bean>
  
  However, with annotations the message is contained within the class itself as an annotation. If you want to actually have different object which only vary by what value is ejected into them, you actually have to make separate classes. How stupid is that?
  
  A commonly used class might be replicated hundreds of times, just so different values can be injected.
  
  
• One class != one object
  2007-05-01 10:12:33  docbillnet [Reply | View]
  
  
  Opps. My example should have been:
  
  <bean id="displayMessage1" class="DisplayMessage">
  <property name="message" ref="message1"/>
  </bean>
  <bean id="displayMessage2" class="DisplayMessage">
  <property name="message" ref="message2"/>
  </bean>
  <bean id="displayMessage3" class="DisplayMessage">
  <property name="message" ref="message3"/>
  </bean>
  
  Just imagine how cluttered your project files will look with hundreds of duplicated classes.
  
  
  
  

• Error in using Dependency Injection
  2006-11-06 02:21:24  Varun.Khurana [Reply | View]
  
  
  When I type
  ' @Resource (name="jdbc/OracleDS")
  private DataSource fooDS; '
  in my IDE, I get a couple of errors which read:
  1) class 'name' not found
  2) formal parameter list: expecting ; ( This comes at the end of the first line
  
  Any pointers for solving this?

• Error in using Dependency Injection
  2006-11-06 02:17:24  Varun.Khurana [Reply | View]
  
  

• Annotations v/s XML
  2006-05-09 02:59:59  JasonSherman [Reply | View]
  
  
  I strongly believe it makes sense to use annotations where required. Nobody liked dependency code to be configured outside in a XML file which is at times difficult to read and looks ugly. But XML is still not dead, there's still a fair deal of code which is not related with any specific piece of code

• So what's new ?
  2006-01-05 00:01:12  GerritCap [Reply | View]
  
  

  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
  

• So what's new ?
  2006-05-05 00:22:13  pbpanther [Reply | 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 [Reply | 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 [Reply | 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
  
  
• So what's new ?
  2006-01-11 00:28:28  GerritCap [Reply | View]
  
  
  A few remarks:
  
  

  
  
  1. Often the mnemonics J2EE and EJB are used interchangably. But I think that J2EE stand for enterprise computing as a step in the evolution of stand alone apps -> client/server -> 3-tier apps. A more flexible way of organising your code. EJB is an implementation of that flexible organisation and delivered by tools like WebSphere, JBoss, WebLogic, Geronimo, ... So where you talk about a J2EE container you should really mention an EJB container.
  
  
  2. If I understand your article and rely correctly using field injection you either specify the name of the resource or the EJB container derives the name from its declaration. And binding the resource is done by the EJB container based upon that name.
     
     
     Well to me this is conceptually exactly the same as requesting the EJB container for a bean with a certain name although you don't program it that way.
     
     
     Again if I understand it correctly, setter injection isn't basically that different. The EJB container again sets the resource based upon the name of the setter.
     
     
     So where is the conceptual difference of looking up a bean by its name or the EJB container binding a resource to your objects based upon your name? This is a very limiting IoC strategy, like having inheritance in a OO language without polymorphism. The basics are there but you don't go all the way. Example what if you have 2 DAO's that programmatically use the same name for a data source resource but in a certain setup they would have to use 2 different datasources.
     
     In a conceptually complete IoC implementation (like Spring) you define a DAO object, you define a datasource and you link (or wire) them together. If tomorrow you need a different datasource for that bean then you wire another datasource to it indepedant of the fact of your original datasource still being used (or wired to) another dao.
  
  
  3. Talking about proprietary or portability:
     
     • Using Spring all of your java code never has to reference any Spring related class or whatsoever. Every object can be a POJO. You can use Spring to set a specific LayoutManager in a JPanel. Using EJB if you want to make an object persistent then it has to be a subclass of javax.ejb.EntityBean.
     
     
     • Spring configuration is done using an XML file, if for some reason you don't like spring anymore then you can do the wiring hard coded for example or you can interpret the same XML structure and do the wiring based upon your own interpretation. Or if there is a particular part you don't like about Spring then use it's source code and change it the way you like it. In a project I used to work on there was one particular thing we didn't like about EJB but a) we could not change the EJB container and b) all of our classes where already dependant to the javax.ejb hierarchy so we had 2 choices: delete all code and start all over without EJB or shut up and put up with the EJB situation.
     
     
     • Ever tried to migrate an EJB project from WebSphere to WebLogic or vice versa ? In every implementation of an EJB container there are some "additions" the are completely propriatary. Once I tried using a java webstart app and using the "original" java runtime environment to connect to a WebSphere EJB Session bean. You needed a IBM JRE including some IBM dll's on windows or a "patched" Sun JRE for the reaqson of having some portability between ibm's corba and ibm's rmi implementation usin in ejb's. Go figure. What are all these "Controls" you use in a WebLogic environment, you think they are portable to WebSphere ??? Why is there an org.jboss.ejb.EnterpriseContext ???
       
       Get real: every commercial EJB implementation makes money on you using their implementation so they will add some "features" only available on their platform (which usually makes your life easier in certain situations I agree) but once you use these features typically the cost of migrating to another EJB implementation is enourmous compared to the promise of "portability of EJB's". I know of a highly payed (and thus costly) consultant of company XYZ make a lot of money doing nothing but migrating customers to the XYZ EJB platform.
     
     
     
     
  4. I agree: Spring is not touted as an alternative to J2EE but as an alternative to EJB and definitly not supposed to be used within a EJB container. Read the book of Rod Johnson & Juergen Hoeller (the 2 most important persons behind Spring in my humble opinion) called "J2EE development without EJB". Can it be more clear?
     
  5. And basically Spring is not a framework, it are a number of different frameworks
     
     
     
     1. Spring core: used to wire plain POJO's implementing the full conceptuial meaning of IoC and allowing you to set properties of objects
     
     
     2. AOP implementation: add aspects of your logic to your code wihtout implementing them. Typical example is transaction management.
     
     
     3. JDBC support: using Spring's JdbcTemplates or use O/R tools like hibernate but not restricted to hibernate
     
     
     4. MVC web framework: going that one important step futher than struts. But allowing you to use struts, struts tiles and/or java server faces.
     
     
     5. Integration with EJB: yes you can integrate it with EJB for those who can't avoid it I guess
     
     
     6. JMS, Mail, JMX, job scheduling,...
     
     
     
     
  
  

  
  
  Gerrit