Should you consider how the Java version handles it?
-----Original Message----- From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Ross Sent: Friday, December 02, 2005 11:49 AM To: [email protected] Subject: [coldspring-dev] More autowire fun On 12/2/05, Adam Crump <[EMAIL PROTECTED]> wrote: > > My conern here was not only for the init method. The autowire will > fail for any inherited method. This could lead to missing/unset > dependancies if one relies completly on the autowire. > For inherited setters, I believe it will set those methods when they are explicitly defined in the xml (not autowired). Autowiring is a double edged sword, it's nice because it prevents you from having to repeat the same xml tags over and over, however it also hides the dependencies from someone looking *only* at the xml (just like inheriting setters/constructora-args hides dependencies from someone looking *only* at the code). I typically only use autowiring for "utility" or "plumbing" classes, which I don't typically consider first-class business objects. I like being able to add a setSomeUtility() to a class and then not have to reconfigure the xml to make ColdSpring pass it in. I also recommend that anyone getting started with ColdSpring should stick to explicitly defining dependencies in the xml. I'm really not sure how I feel about the autowiring code walking up the inheritance tree, since my initial feeling is that inheriting setters and constructor args for dependency resolution is not that great of an idea, and it would add some additional overhead during framework startup. Again, I'd love to hear other's thoughts on these issues... -Dave
