Yes, for single types using @Autowired in case of annotations, but still missing being able to collect distributed configurations. In essence, this is how the the ki/tapestry integration library I'm working on is meant to be used; the library configures some defaults and users of the integration library can add their own; they'll all be collected and injected to the constructor of the same security service. But this is getting off-topic.
Kalle On Wed, Mar 11, 2009 at 11:43 AM, Les Hazlewood <[email protected]>wrote: > I'm not sure what you mean by that Kalle - Spring supports type and > constructor-based wiring... > > On Wed, Mar 11, 2009 at 1:55 PM, Kalle Korhonen > <[email protected]>wrote: > > > Annotations can make Spring easier, but please don't assume Spring is the > > best it can be. Until you've used Guice or tapestry-ioc you won't know > how > > much simpler IoCs and autowiring can still be with type and > > constructor-based injection. > > > > Kalle > > > > > > On Wed, Mar 11, 2009 at 10:29 AM, Jeremy Haile <[email protected]> > wrote: > > > > > I don't have time to do a point-by-point response to this at the > moment, > > > but I'm currently at the DevNexus conference in Atlanta. I was just > > talking > > > to Keith Donald of SpringSource and watching his presentation, and he > > spent > > > considerable time talking about how they view annotations as the best > > > practice when using Spring. From Spring 3.0 going forward, annotations > > will > > > be the best practice and will be communicated as such in their > > > documentation. There are definitely ways to work around the concerns > you > > > brought up, such as configuring your application differently in > different > > > contexts. If you want, I can try to do a point-by-point analysis > later, > > but > > > the SpringSource guys know their stuff and are very clear that > > annotations > > > are the best practice. > > > > > > > > > On Mar 11, 2009, at 11:10 AM, Les Hazlewood wrote: > > > > > > Yeah, I didn't mean the example per se, but you had mentioned best (or > > >> maybe > > >> just current) practices before. > > >> > > >> Of course annotations clean up xml significantly, but I'm not so sure > > that > > >> they are a 'best practice'. It is convenient for many, sure, but it > has > > >> downsides that might preclude it from being used. > > >> > > >> For example, I encountered something just 2 days ago that required a > > >> configuration change from something that was running in a publicly > > >> available > > >> beta environment. We were stuck for time and we couldn't re-build the > > >> project. We were able to go in, change a config file, restart Tomcat, > > and > > >> the stake holder was quite happy. We couldn't have done that with > > >> annotations. > > >> > > >> And there is another thing about annotations that I'm not too keen on > - > > >> the > > >> required mix of XML and Annotations. For large projects, some of your > > >> beans > > >> can be annotation configured, while many others cannot (Hibernate > > session > > >> factory, connection pool, 'frameworky' proxy stuff, prototype scoped > > >> beans, > > >> etc). Then you'll have to hunt down which objects are configured in > one > > >> way > > >> vs another. I like consistency, especially when 20+ developers have > > their > > >> hands in the mix. > > >> > > >> I honestly haven't made up my mind about this issue. I like the > > >> cleanliness > > >> of annotations, but I wonder what would happen if dynamic > configuration > > >> would be required in a pinch. That it saved my team's arse only 2 > days > > >> ago > > >> leads me to believe it might happen again, and having that in my back > > >> pocket > > >> is really comforting... > > >> > > >> On Wed, Mar 11, 2009 at 10:28 AM, Jeremy Haile <[email protected]> > > >> wrote: > > >> > > >> I think using annotations to configure Spring singletons is very nice > - > > >>> it > > >>> minimizes XML while still allowing you to configure things in XML > when > > >>> desired. This seems to be the trend in Spring usage as well, as > Spring > > >>> 3.0 > > >>> will be very focused on the annotation configuration support - in > fact > > >>> Spring MVC will be deprecating all XML configuration of controllers > in > > >>> favor > > >>> of annotations. > > >>> > > >>> Look how simple the Spring XML files are in the project. I think > it's > > >>> nice > > >>> to have an example app that shows off the latest Spring technology as > > >>> well. > > >>> > > >>> I think it's debatable as to whether annotations "couple" you to > Spring > > - > > >>> obviously the JAR file is required, but there's no reason I couldn't > > >>> dependency inject them using some other framework. Spring won't even > > >>> create > > >>> these singletons unless I tell it to in the XML file using the > > >>> context:component-scan tag, so they can be configured differently in > a > > >>> "unit > > >>> test" context, etc.. That being said, I'm not worried about it being > > >>> "coupled to Spring" since it is the spring-hibernate example. > > >>> > > >>> Jeremy > > >>> > > >>> > > >>> > > >>> On Mar 9, 2009, at 10:09 AM, Les Hazlewood wrote: > > >>> > > >>> Hi Jeremy, > > >>> > > >>>> > > >>>> Why did you decide to use Spring Annotations to wire your objects > > >>>> instead > > >>>> of > > >>>> autowiring? Now most of the business objects/DAOs in the sample app > > are > > >>>> coupled to Spring's API. I'm curious as to why you went down that > > >>>> road... > > >>>> > > >>>> Les > > >>>> > > >>>> > > >>> > > >>> > > > > > >
