Annotation-Driven Dependency Injection in Spring 2.1

Discussions

News: Annotation-Driven Dependency Injection in Spring 2.1

  1. Marc Logemann pointed out Mark Fisher's "Annotation-Driven Dependency Injection in Spring 2.1." Mr. Fisher's note shows the new context namespace in use, which can automatically scan packages for possible injectable types, as well as the aop namespace, which can autowire aspects based on annotations in source code. The Spring configuration file at the conclusion of the explanation looks like this:<!--?xml version="1.0" encoding="UTF-8"?--> The class that leverages this configuration looks like this:public class GreetingServiceImplTests extends AbstractDependencyInjectionSpringContextTests { private GreetingService greetingService; public void setGreetingService(GreetingService greetingService) { this.greetingService = greetingService; } @Override protected String[] getConfigLocations() { return new String[] { "/blog/applicationContext.xml" }; } public void testEnglishWelcome() { Locale.setDefault(Locale.ENGLISH); String name = "Spring Community"; String greeting = greetingService.greet(name); assertEquals("Welcome " + name, greeting); } public void testGermanWelcome() { Locale.setDefault(Locale.GERMAN); String name = "Spring Community"; String greeting = greetingService.greet(name); assertEquals("Willkommen " + name, greeting); } }Note that there's no specific declaration of the GreetingService; the context scan looks for candidates for injection based on annotations, and injects them automatically. Spring 2.1 should be out sometime soon; what features are you looking for?

    Threaded Messages (36)

  2. The actual annotation[ Go to top ]

    You might want to point out that the class that leverages the annotation-driven dependency injection actually has an annotated setter method for the to-be-injected property: @Autowired public void setMessageRepository(MessageRepository messageRepository) { this.messageRepository = messageRepository; }
  3. Re: The actual annotation[ Go to top ]

    You might want to point out that the class that leverages the annotation-driven dependency injection actually has an annotated setter method for the to-be-injected property:

    @Autowired
    public void setMessageRepository(MessageRepository messageRepository) {
    this.messageRepository = messageRepository;
    }
    For what it's worth...you don't have to use setter methods to use @Autowired. The method can be any method and @Autowired will auto-wire the method's arguments. Moreover (and this is kinda cool) you don't have to use methods at all! You can place @Autowired on a private instance variable and it will inject it.
  4. Without going deep into the details what I don't like is the use of annotations for configuration aspects. I still think that is wrong, point. And, IMO, lot of people saying a wrong thing does'nt make it right. Maybe in few years someone will come and teach us that all those tons of (configuration) annotations are a terrible mistake. And I will not too much surprised if he is the same promoting this stuff. Guido.
  5. Annotations or Configuration[ Go to top ]

    Without going deep into the details what I don't like is the use of annotations for configuration aspects.
    ...
    Guido.
    Actually I believe that this is an excellent example of the use of annotations. Annotating a method to say that it expects it expects to be called as part of the creation of that object is not configuration. It is metadata about the class itself. The actual annotation in the example up the top: @Autowire could imply configuration, specifically auto-configuration. I would suggest something more value neutral like @Inject. If your application/configuration can survive with autowiring then no further configuration is required. Use of such annotations, however, should not mean that a configuration file cannot be used to wire up your bean a specific way. Larry
  6. Annotations being wrong[ Go to top ]

    Not sure whether the annotations are wrong or right in the first place. But just wanted some clarification regarding the same. We did move out of the usual source to the XML configurations so that they can be externalized. I guess the annotations are again reversed the same thing, ie the configurations are coming back to the source files. Just wanted to know whether they're actually right?
  7. Re: Annotations being wrong[ Go to top ]

    Not sure whether the annotations are wrong or right in the first place. But just wanted some clarification regarding the same.
    We did move out of the usual source to the XML configurations so that they can be externalized. I guess the annotations are again reversed the same thing, ie the configurations are coming back to the source files. Just wanted to know whether they're actually right?
    Nagraj, I think talking about annotations (for dependency injection) being wrong or right is a little bit too black or white. At the end of the day, most of the Spring project members feel that using annotations to drive actual dependency injection is at least somewhat invasive, and that invasiveness is unnecessary in light of alternatives such as XML or Spring's externalized "Java Config" option. But that said, we do think it's important to offer this option (with a model that's the best possible fit for Spring), so people can make their own choice. The nice thing with the Spring approach too, is that it's really not either/or. While I will probably chose to not use any annotation driven dependency injection, somebody else may work primarily with annotations, and then fall back to XML when hitting some of the fundamental limitations of the approach (i.e. what happens when there are multiple implementations of a target interface, etc.). This option is simply not available in some alternative frameworks. Regards, Colin -- Colin Sampaleanu Principal, Interface21 Spring Training, Consulting and Support - "From the Source" http://www.interface21.com
  8. good feature[ Go to top ]

    Hi, This is a good feature, I like it. But how about if there are two GreetingService classes in the classpath, but in different folder (that possible), then how Spring 2.1 resolve this ambiguity? Thanks, Yi Zhu
  9. another thought[ Go to top ]

    Hi all, When Spring configuration is becoming more and more complicate, is there another way to easily handle this complicate? For example, a new scripting languange to handle this complication. I mean that we can write a script instead of XML file to configurat the software process. In my undersatnding, a OOP scripting language is more powerful and flexible that XML file.
  10. Sure[ Go to top ]

    In most cases (from my experience at least), if you find your configuration gets more complex, it's typically because your application just gets that much more complex. So switching to a different way of defining the same configuration hardly helps. That being said, you can certainly define application contexts programmatically - in plain Java or in Groovy, bsh, etc. I blogged about some very basic idea around doing it with Spring's BeanDefinitionBuilder.
  11. Reply: Sure[ Go to top ]

    " That being said, you can certainly define application contexts programmatically - in plain Java or in Groovy, bsh, etc. I blogged about some very basic idea around doing it with Spring's BeanDefinitionBuilder. " I have checked your Blog, but I can't see that your example code can make a complex project configuration easier in the languages you chose. What I want to say is that we need a more powerful scripting language which can handle software components in a more higher level, just like spring XML config file to Javabeans.
  12. Re: another thought[ Go to top ]

    Groovy+grails already does this. http://grails.codehaus.org/Spring+Bean+Builder
  13. Groovy's been an option for a while[ Go to top ]

    I mean that we can write a script instead of XML file to configurat the software process.

    In my undersatnding, a OOP scripting language is more powerful and flexible that XML file.
    If it's scripting languages you seek, the Grails community has you covered: http://grails.codehaus.org/Spring+Bean+Builder The thing to remember is that the annotations are a *choice*. The XML configuration, properties configuration, java configuration, grails configuration, etc. will all continue to exist as choices for configuration. You use what feels comfortable, and I wouldn't be surprised to see these choices coexist with one another... app beans in annotations, infrastructure in XML anyone?
  14. It's about choice[ Go to top ]

    The thing to remember is that the annotations are a *choice*.
    Well said. Spring has long been criticized for its use of XML for configuration. These annotations simply represent an optional configuration choice to satisfy those that prefer annotations. If you still like XML, then go ahead and use that. Or if you prefer Groovy or JRuby, then there are options for Spring configuration there, as well. Your choice. FWIW, I still favor XML...but I'm glad that there's an abundance of choices. While I'm here, I feel compelled to agree with one other post that said that autowiring can be scary for larger applications. Again, however, this is only a choice. If @Autowired doesn't strike you as a good idea, then consider using @Resource instead. @Resource lets you explicitly choose which bean gets wired (and like @Autowired, doesn't require a setter method...use it on a private instance variable if you want).
  15. Re: It's about choice[ Go to top ]

    The thing to remember is that the annotations are a *choice*.


    Well said. Spring has long been criticized for its use of XML for configuration. These annotations simply represent an optional configuration choice to satisfy those that prefer annotations. If you still like XML, then go ahead and use that. Or if you prefer Groovy or JRuby, then there are options for Spring configuration there, as well. Your choice.

    FWIW, I still favor XML...but I'm glad that there's an abundance of choices.

    While I'm here, I feel compelled to agree with one other post that said that autowiring can be scary for larger applications. Again, however, this is only a choice. If @Autowired doesn't strike you as a good idea, then consider using @Resource instead. @Resource lets you explicitly choose which bean gets wired (and like @Autowired, doesn't require a setter method...use it on a private instance variable if you want).
    Annotations for injection are unnecessarily invasive for my taste, so I will probably personally stick to a combination of XML plus the alternate Spring JavaConfig (http://www.springframework.org/node/455) which is completely non-invasive. However, it really bears pointing out that, invasiveness aside, this new annotation driven injection does not share most of the caveats of traditional Spring autowiring. Traditional Spring autowiring was a pretty broad brush: for a bean definition, you told Spring to autowire it, while being able to specifically inject certain properties. Surprise would come from the fact that you did not have much control over what would be autowired (0-x setters when working with setter methods, or a constructor otherwise), and on top of that, the default behavior was to treat no match as a silent non-error, with only the ability to alternately turn on a flag saying _all_ properties needed to be injected. The new annotation-driven injection is much more predictable and there does not have to be any "surprise" factor. You can specifically indicate which fields or methods should be injected, and will get an error if there is no match (or too many). It's also quite relevant that as opposed to some other annotation based dependency injection frameworks, when the annotation driven approach hits a wall (multiple matching targets, etc.) it is quite easy to fall back to explicit bean definitions to cover those cases. Regards, -- Colin Sampaleanu Principal, Interface21 Spring Services - "From the Source" http://www.interface21.com
  16. Re: It's about choice[ Go to top ]

    The thing to remember is that the annotations are a *choice*.


    Well said. Spring has long been criticized for its use of XML for configuration. These annotations simply represent an optional configuration choice to satisfy those that prefer annotations. If you still like XML, then go ahead and use that. Or if you prefer Groovy or JRuby, then there are options for Spring configuration there, as well. Your choice.

    FWIW, I still favor XML...but I'm glad that there's an abundance of choices
    Craig, will sping2.1 annotation be covered in Spring In Action 2?
  17. Re: It's about choice[ Go to top ]

    Craig, will sping2.1 annotation be covered in Spring In Action 2?
    Unfortunately, no. The timing of Spring 2.1 did not allow me the opportunity to work it into the book. The writing phase of the book is over (has been for almost a month) and we're up to our neck in the production phase (tech editing, copy editing, typesetting, etc, etc, etc). At this point, I can only make small changes to the manuscript.
  18. There are a number of things mentioned that really annoy me, and in my own experience lead to difficult to maintain projects in the long run. It seems like all these things that are supposed to make the spring config more concise are exactly the things that add complexity to large projects. Firstly, once your project is too big to hold in your head in one go, autowiring is bad. It gets you up and running quickly, but you just have to *know* how things fit together. You cannot look at your XML file and see it, which is hell when something goes wrong. The more steps you have to take to see how your components fit together, the harder it is to support a large application. So, in large projects, precisely where you would benefit from terse configuration, we have ended up expressing all dependencies explicitly. Secondly, applying AOP with pattern matching simply does not scale well. I know the Spring IDE now supports visualisation of this kind of thing, but in the past you just had to parse the expression in your head and figure out which beans might be advised somewhere down the line. This is nicer in Spring IDE, granted, but even so getting that working on a sufficiently large project is pretty taxing. Thirdly, the introduction of managed beans that are not even declared anywhere in the config files is just doubling all of the maintenance headache of autowiring. Not only do you just need to *know* that your method might be injected with something, but also that the injected bean might not actually have been declared anywhere. So, when investigating a problem with your application, the following process: * Look at the bean definition for your component to see what collaborators have been assigned to it Becomes: * Look at the bean definition for your component to see what collaborators have been assigned to it * Scan all files in your application context to find named/typed beans that could have been wired up for you * Scan all files in your application context that may have declared a package for auto-discovery of components * Scan all java files for @Component annotations None of these things are too taxing if the project is small, or if your support staff consists entirely of top-flight Interface21 consultants. Unfortunately, support is one of those things that companies just love to save money on and cynically outsource to whatever developing nation is flavour of the month. So yes, some of these things are interesting and convenient, and Spring IDE helps somewhat (it's come on a lot recently, but the bean navigator sucks for large projects). However, you may find that if you use all of these toys on a project you're stuck supporting it until the end of your career as no-one else can ever get their head around how it all slots together.
  19. There are a number of things mentioned that really annoy me, and in my own experience lead to difficult to maintain projects in the long run. It seems like all these things that are supposed to make the spring config more concise are exactly the things that add complexity to large projects.

    Firstly, once your project is too big to hold in your head in one go, autowiring is bad. It gets you up and running quickly, but you just have to *know* how things fit together. You cannot look at your XML file and see it, which is hell when something goes wrong. The more steps you have to take to see how your components fit together, the harder it is to support a large application. So, in large projects, precisely where you would benefit from terse configuration, we have ended up expressing all dependencies explicitly.

    Secondly, applying AOP with pattern matching simply does not scale well. I know the Spring IDE now supports visualisation of this kind of thing, but in the past you just had to parse the expression in your head and figure out which beans might be advised somewhere down the line. This is nicer in Spring IDE, granted, but even so getting that working on a sufficiently large project is pretty taxing.

    Thirdly, the introduction of managed beans that are not even declared anywhere in the config files is just doubling all of the maintenance headache of autowiring. Not only do you just need to *know* that your method might be injected with something, but also that the injected bean might not actually have been declared anywhere.

    So, when investigating a problem with your application, the following process:
    * Look at the bean definition for your component to see what collaborators have been assigned to it

    Becomes:
    * Look at the bean definition for your component to see what collaborators have been assigned to it
    * Scan all files in your application context to find named/typed beans that could have been wired up for you
    * Scan all files in your application context that may have declared a package for auto-discovery of components
    * Scan all java files for @Component annotations


    None of these things are too taxing if the project is small, or if your support staff consists entirely of top-flight Interface21 consultants. Unfortunately, support is one of those things that companies just love to save money on and cynically outsource to whatever developing nation is flavour of the month.

    So yes, some of these things are interesting and convenient, and Spring IDE helps somewhat (it's come on a lot recently, but the bean navigator sucks for large projects). However, you may find that if you use all of these toys on a project you're stuck supporting it until the end of your career as no-one else can ever get their head around how it all slots together.
    And what if the same application is deployed in different contexts each requiring different configurations ? I don't know if annotation-driven approach is able to solve this problem, but, if not, is it possible to live in a world where silver bullets can be applied just in "Hello World" application and prototypes ? Is it possible that it is only me having such a requirement ? Guido
  20. Firstly, once your project is too big to hold in your head in one go, autowiring is bad. It gets you up and running quickly, but you just have to *know* how things fit together. You cannot look at your XML file and see it, which is hell when something goes wrong. The more steps you have to take to see how your components fit together, the harder it is to support a large application. So, in large projects, precisely where you would benefit from terse configuration, we have ended up expressing all dependencies explicitly.[...]

    So, when investigating a problem with your application, the following process:
    * Look at the bean definition for your component to see what collaborators have been assigned to it

    Becomes:
    * Look at the bean definition for your component to see what collaborators have been assigned to it
    * Scan all files in your application context to find named/typed beans that could have been wired up for you
    * Scan all files in your application context that may have declared a package for auto-discovery of components
    * Scan all java files for @Component annotations
    I don't think you should look at the XML file to figure out what components are injected into a class. That should be (and usually is) evident from the class itself, given members and setters. Granted, I've never really worked on HUGE projects, but hand on heart, what percentage of your beans actually diverge from the "blogDao" BlogDaoImpl.class pattern, not counting pointless naming conventions such as "hibernateSessionFactory" when there's only one SessionFactory?
  21. Firstly, once your project is too big to hold in your head in one go, autowiring is bad. It gets you up and running quickly, but you just have to *know* how things fit together. You cannot look at your XML file and see it, which is hell when something goes wrong. The more steps you have to take to see how your components fit together, the harder it is to support a large application. So, in large projects, precisely where you would benefit from terse configuration, we have ended up expressing all dependencies explicitly.[...]

    So, when investigating a problem with your application, the following process:
    * Look at the bean definition for your component to see what collaborators have been assigned to it

    Becomes:
    * Look at the bean definition for your component to see what collaborators have been assigned to it
    * Scan all files in your application context to find named/typed beans that could have been wired up for you
    * Scan all files in your application context that may have declared a package for auto-discovery of components
    * Scan all java files for @Component annotations


    I don't think you should look at the XML file to figure out what components are injected into a class. That should be (and usually is) evident from the class itself, given members and setters. Granted, I've never really worked on HUGE projects, but hand on heart, what percentage of your beans actually diverge from the "blogDao" BlogDaoImpl.class pattern, not counting pointless naming conventions such as "hibernateSessionFactory" when there's only one SessionFactory?
    I think you should be able to look for the XML. I have a persistence.xml. All my persistence wiring is defined in one place. But with annotations, I now have to check each and every DAO. Ditto for security, business, presentation, roles, caching, profiling, etc... I think that this would scale poorly in terms of understanding. Information that was contained in well named XML is now spread across dozens and dozens of class files. In addition, I've had need to change configuaration and having to recompile seems like a pain, but as mentioned, we have choices.
  22. Autowire magic[ Go to top ]

    I have implemented a large part of this for our large (huge?) project. I can say, with hand on heart, that there are very few cases where we need to do anything other than autowire. That is we generally have only one Impl class. The joy of doing this is you say "I need to use this DAO", so you add a setter with an annotation and it just appears. Larry
  23. Re: Autowire magic[ Go to top ]

    I have implemented a large part of this for our large (huge?) project. I can say, with hand on heart, that there are very few cases where we need to do anything other than autowire. That is we generally have only one Impl class.

    The joy of doing this is you say "I need to use this DAO", so you add a setter with an annotation and it just appears.

    Larry
    What I am missing here is annotation driven bean declaration. I know there are several side projects, but all of them fall severely short once it comes down to custom scopes. All of them chose the approach of using predefined enumerations which limit themselves down to the predefined scopes given by spring, instead of strings as scope assignment types and hence making it unnecessary complicated to use them once you have a custom scope.
  24. Re: Autowire magic[ Go to top ]

    I have implemented a large part of this for our large (huge?) project. I can say, with hand on heart, that there are very few cases where we need to do anything other than autowire. That is we generally have only one Impl class.

    The joy of doing this is you say "I need to use this DAO", so you add a setter with an annotation and it just appears.

    Larry
    You've inspired me. While I've had need to change a few implementations, DAOs have not been one of them. Hmmmm..it'll be worth doing some experimentation to find a balance.
  25. I don't think you should look at the XML file to figure out what components are injected into a class. That should be (and usually is) evident from the class itself, given members and setters. Granted, I've never really worked on HUGE projects, but hand on heart, what percentage of your beans actually diverge from the "blogDao" BlogDaoImpl.class pattern, not counting pointless naming conventions such as "hibernateSessionFactory" when there's only one SessionFactory?
    Hand on heart? In typical use, 100% of our infrastructure classes conform to that pattern (sessionFactory, dataSource, transaction advice, that kind of thing - fortunately I've managed to avoid talking to two DBs from one app context in all but the most unusual cases) Maybe 95% of our core business objects are an interface with a single implementation. There are always exceptions, and those bite you in the ass with autowiring. Approximately 0% of our collaborating beans can be autowired (generic classes that behave differently depending on their config). These are also completely inappropriate for annotations, as there are maybe a dozen concrete implementations, each of which is declared several different ways. Approximately 30% of our frontend controllers/flows are single-purpose and could be autowired or annotated. The majority are generic and reusable depending on their configuration. Again, several dozen concrete classes are represented by several times as many bean definitions. All in, maybe a quarter of the beans in a full application context follow that simpl dat/daoimpl pattern. Vastly outnumbered by general purpose collaborators and controllers that are highly config-dependent. Add to that nested bean contexts and autowiring gets very imprecise. It's safer just to express everything explicitly, rather than have a mix of autowiring/non-autowrited and have to figure out mentally what's going to be applied by checking the source + the xml. While it gets verbose, at least if it's all in the xml, then you only have one place to look. Again, this is just my experience - once you get out of the realms where you can hold the whole structure in your head, every additional place to check for information adds greatly to the maintenance overhead.
  26. Agree with you. There have been a lot of discussions about this topic. Check out my blog to see some pragmatic solutions: http://lofidewanto.blogspot.com/2006/08/heavyweight-champions-are.html Cheers, Lofi.
  27. People need to proceed with caution when it comes to using Annotations, XML, or pure Java code. Far too often, people tend to accommodate and abuse new technologies. I believe a good balance between the options is a best of breed. Although, I think its good for Spring to offer another alternative to doing DI, but I strongly encourage people to select a good balance in the previous methods mentioned above. @Signature(display=true) Best Regards, Richard L. Burton III
  28. Auto wiring and Annotations are options. We have a choice to use it. But, look at what Spring Framework offers today for J2EE applications, it is one place to get all the abstract implementations.
  29. Perhaps I just missed it in the blog and Spring 2.1 documentation, but I would want take this one step further and specify the bean to be injected in the annotation itself: @Inject("customerFooDao") public void setFooDao(FooDao dao) If a name is provided, the bean in the current context with that name is used. Otherwise, the dependency is autowired. There are times when autowiring is sufficient, but I do have cases in my own app where there is more than one implementation of an interface being used in parallel for different situations. Annotations can support this, so I do not see a reason for requiring XML configuration to do it.
  30. This is exactly what JSR-250's @Resource annotation allows for - already supported by Spring 2.1 M1. This resolves the field name / bean property name (or explicitly specified resource name) as Spring bean name, analogous to @Resource's behavior in Java EE 5. Injecting such a named resource significantly differs from Spring's @Autowired behavior - which can apply to methods and constructors with an arbitrary number of arguments as well, not just to fields and setters. As a consequence, those variants are represented by different annotation types: the standard @Resource and Spring's @Autowired. Juergen
  31. In May 05 2006, it was suggested to the spring framework team to include this approach as an option for configuring a session factory (http://opensource.atlassian.com/projects/spring/browse/SPR-1987), and it was told that they would not include this kind of configuration in the spring framework. The Spring-Annotations (http://sannotations.sourceforge.net) project was born to supply this option to the spring framework users, just because it would not be included in the core. Now a crippled version of the project (Ok, maybe it is not a crippled version, but it looks like) is included in the spring framework core, probably killing the possibility of new users for the secondary project, because most will prefer not to include more additional libs in the project. and without giving credit for the idea or using the initial contribution. Maybe it was not what happened but to me, it looked like making a good suggestion, being told it is not a good idea, and it will not be used, and after a while the "boss" tell me: Hey, look the great idea I have! PS.: the Spring-Annotations already do the bean scaning, enables you to use an arbitrary annotation to mark your beans, enables the registration of beans in any scope, you can use autowire ot configure properties manually (@Property, ok, this is more like a service lookup), has many other facilitators ... PS2.: sorry for the almost off-topic post.
  32. Rodrigo, You've now written essentially the same message in 3 different places, here on TSS, and here: http://blog.interface21.com/main/2007/05/14/annotation-driven-dependency-injection-in-spring-21/ http://opensource.atlassian.com/projects/spring/browse/SPR-3486 and I have to say it's getting sort of old... I am just going to quote myself from the above blog entry:
    Comment 1: Rodrigo, You wrote a similar question in this Jira entry: http://opensource.atlassian.com/projects/spring/browse/SPR-3486 Mark has replied there, but I'll quote his reply: """Spring's annotation-driven configuration code has been introduced in the first milestone release of version 2.1. As a milestone release it will definitely continue to evolve, but it is in no way a "crippled" implementation. The implementation model we have chosen does not follow the approach of the spring-annotations project. We did not feel that mirroring the XML elements and attributes within annotations was the correct approach for our needs. We have a strong responsibility to provide support that will work in a complementary way with other Spring configuration options (including XML bean definitions as well as Java Config), and we are providing support for JSR-250 annotations with a clear focus on consistency. Since we are taking a different approach than the spring-annotations project, it did not make sense for us to consider re-using some of the spring-annotations code. As always, we welcome feedback from the Spring user community and for Spring users to build upon Spring in any way; it's great that people are trying to push the boundaries of what Spring can do. That said, after considerable thought and prototyping on how to best do annotation-driven dependency injection in a manner that is consistent with Spring in general, the Spring team decided this approach - implemented from scratch - was the best choice.""" I think Mark's reply is pretty good on its own, but I can comment along the same lines. It's absolutely great the other projects try to build on Spring functionality to implement things that people need, and it's a testament to the flexibility of IoC, and how Spring was built, that it's possible to do this kind of stuff without having to modify Spring. However, that doesn't automatically mean when/if the core project tries to approach the same problem space it makes sense to reuse the same approach or even the code as somebody else may have used. Last year, while we had some decent experience in implementing annotation driven injection via the Pitchfork project, we first of all did not think it was the right time to do any sort of annotation driven injection in core Spring itself, and fundamentally the spring-annotation model didn't feel quite right either. This year, while we think many/most people will prefer to stick to XML, there is some demand for an annotation driven approach, and we're trying to meet this need (along with trying alternative Java-focused approaches like Java Config), in the fashion that feels best to us. I do think it's a bit disingenuous to try to imply that this new code uses or borrows from spring-annotation (with or without credit given). None of us have ever been in the code for spring-annotation, the model is pretty much different, this problem space has been tackled by other projects (EJB 3, our own Pitchfork, etc), and we've thought a lot about how to approach this, and hopefully have come up with a usable solution. Colin Comment 2: Of course I forgot to mention Bob Lee's Guice in my last paragraph above. Colin Comment 3: The other thing that needs emphasizing here (as Mark has said a few times) is that this stuff is going to continue to evolve. This is just an M1 release and this is just an initial cut of functionality that we feel pretty good about. For example, as Mark has said to me previously, it would take about a minute to support defining scope with an annotation, but right now we're not sure we necessarily think that's actually appropriate (should a bean really know about its own scope, is that not something for the deployer/configurer to worry about?). So for this release we've left scoping as something to be configured only via XML, which is actually quite easy to do… Colin
    I don't know how much more succinct I can be than the above. What we are trying to do here, is in the time frame that makes sense for the resources we have and the actual needs of our users, give them the best (in terms of fit, feature set, quality, etc.) product that meets those needs. It did not make sense last year or more recently, to try to use the approach (or the code) from the spring-annotations project. It's that simple. Please stop acting like a jilted lover. The beauty of Inversion of Control, and the fact that Spring itself is built on this concept, is that it's very easy for people to add on to Spring to make it work exactly like they wish. If you think you have a better approach in spring-annotations, I encourage you to keep on enhancing it to meet that need and serve the market for that approach... Regards, Colin -- Colin Sampaleanu Principal, Interface21 Spring Training, Consulting and Support - "From the Source" http://www.interface21.com
  33. Please stop acting like a jilted lover.

    Regards,
    Colin

    --
    Colin Sampaleanu
    Principal, Interface21
    Spring Training, Consulting and Support - "From the Source"
    http://www.interface21.com
    The duplicated posts are due to the lack of an answer ... PS.: Good argumentation, personal offenses are always a good way to end a discussion where you do not have a good point. PS2.: thanks for the credits not given.
  34. Please stop acting like a jilted lover.

    Regards,
    Colin

    --
    Colin Sampaleanu
    Principal, Interface21
    Spring Training, Consulting and Support - "From the Source"
    http://www.interface21.com


    The duplicated posts are due to the lack of an answer ...

    PS.: Good argumentation, personal offenses are always a good way to end a discussion where you do not have a good point.

    PS2.: thanks for the credits not given.
    Rodrigo, I have to apologize for the comment about acting like a jilted lover. Saying something like that is unprofessional and not the sort of thing I normally do. However, you have now posted the same sort of thing in about 5 or 6 different places, and I honestly don't know what you want. How can you talk about lack of answers when I've very patiently explained (multiple times) that: - last year we did not feel it was appropriate to put in annotation driven injection in Spring itself. This was a product decision based on how we felt about the whole model (what it might look like) and what the market wanted. At the end of the day, it's really that simple. - we still think annotation driven injection is more invasive than alternative approaches, and most people will prefer alternative approaches, but given the existence of something like Guice, there are obviously some people who wish to at least experiment with this model. It is now the appropriate time to offer a dependency injection option using this model, so people can pick and chose and use whatever fits their needs best It did not seem to make any sense to try to leverage anything from your spring annotations-project. We did not look in great depth at spring-annotations (the Javadocs are very sparse, and nobody has ever been in the code itself) but the model is quite different; you have annotations mirroring the XML elements in Spring) while the model we chose is a combination of support for a new @Autowire annotation for autowiring specific fields, properties, and even arbitrary methods, along with support for JSR 250's @Resource annotation to wire based on a bean definition. We were also under a heavy time constraint, in trying to get something ready for release at or immediately after JavaOne. So, starting from scratch, Mark Fisher was able to create a good quality implementation of the model we chose, in under a week. In retrospect, I don't think we could have gotten what we needed in the time frame we needed it, any other way. I do need to state, VERY concretely, that we have not ever taken any code from your spring-annotations project. Some of your posts (e.g. "even the code being very similar") would seem to make this accusation, and that is absolutely, completely untrue. Before yesterday, Mark had never even looked at any aspect of your project (Javadoc, documentation, etc. never mind code) while some of us have looked at the Javadocs in the past, but as I said, there is not a lot there. The model we finally went with is based on thinking about how everybody we know of (EJB 3, our own Pitchfork project, Guice, spring-annotations, etc.) has tackled the problem, and trying to think about what is the best fit for Spring. I am (sincerely) really sorry that you are obviously hurt that you were not involved in the process of creating this implementation. As I said, the time factor ruled out any other way of getting there. We honestly welcome your contribution, in the form of constructive suggestions on how we can improve the model as it evolves more along the way to Spring 2.1 final. If this is going to work, you do need to stop slinging around words like "crippled". For better or for worse, this is the basic model we've chosen. So as I was (not very clearly) trying to say in a previous post, you need to fundamentally buy into this model and try to improve it in a compatible fashion, or otherwise, you do always have the option of doing it another way, if that makes more sense to you... Regards, Colin -- Colin Sampaleanu Principal, Interface21 Spring Training, Consulting and Support - "From the Source" http://www.interface21.com
  35. Rodrigo, I have to apologize for the comment about acting like a jilted lover. Saying something like that is unprofessional and not the sort of thing I normally do.
    Colin, I have to apologize here, I agree that the @Autowire annotation is great, and a lot better than @Property that is not the point. I have too wrote things like "crippled version" that are not very professional too, and I'm sorry for that, I do not do it usually ... all this "problem" I have created was about the @Component X @Bean annotations, that do almost the same thing. and what I wanted with that? in the first post (spring framework blog I think), just closing the JIRA issue telling that it would be implemented in a different way would have been good enough. And I have to apologize again for telling that the code was similar, I never wrote that it was equal, but some could understand that, I'm very sorry for this.
  36. Rodrigo, I think you will be interested in some of the customization capabilities that will be presented in the next blog entry (hopefully tomorrow) at http://blog.interface21.com. It turns out that the @Component annotation is just one of the defaults; others include @Repository and @Aspect. The underlying model is based upon "type filters" however and can accommodate non-annotation filters as well. For example, you can include (or exclude) based on user-defined annotations, assignable types (any interface or class), or regular expressions (such as "org\.foo\..*Dao"). It is at the level of these expressions that we are likely to bring in the scope configuration. Additionally, the @Autowired annotation can be replaced with a custom type. Please continue to share your thoughts. It is always important to us and even more so during these milestone release phases. Mark Fisher Interface21 http://blog.interface21.com/main/author/markf/
  37. The underlying model is based upon "type filters" however and can accommodate non-annotation filters as well. For example, you can include (or exclude) based on user-defined annotations, assignable types (any interface or class), or regular expressions (such as "org\.foo\..*Dao").
    Hmmmm...kinda sounds like it may cover some of the same ground that Chris Richardson's Arid POJOs (http://code.google.com/p/aridpojos/) covers, only a bit more.