On Wed, Mar 11, 2009 at 1:36 PM, Alan D. Cabrera <[email protected]>wrote:
> There's a lot of jargon in your explanation below. For example, "collect > distributed configurations". Not sure what that exactly means though I have > some hunches. Could you restate what you've said for those of us who are > not Guice or Tapestry users? It's a simple concept. A constructor accepts some type of collection of objects that can be injected (contributed) from multiple different libraries in classpath. More about it at http://tapestryjava.blogspot.com/2007/04/tapestry-5-ioc-from-guice-perspective.htmland http://tapestry.apache.org/tapestry5/tapestry-ioc/. Of course, anything can be done - for example I've implemented something similar for seeding a database from entity beans using Spring's ContextAware interfaces, but not quite as simple. Kalle > On Mar 11, 2009, at 12:27 PM, Kalle Korhonen wrote: > > 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 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>> >>>> >>> > >
