On Wed, Mar 26, 2008 at 2:14 AM, Cassie <[EMAIL PROTECTED]> wrote: > I think guice is a great idea, but I just wanted to mention that your > patch > seemed a little messy. I think there are some unrelated changes in there > which made it a little harder to figure out what the guice change was > actually doing. If the patch was cleaned up a bit it might make for > simpler > evaluation.
Could you elaborate? There shouldn't have been any unrelated changes in there. I wound up moving some code around to make the Guice integration cleaner, but I don't think there is anything in there not directly related to Guice support refactoring. > > That said, +1 for checking it in. > > - Cassie > > > On Wed, Mar 26, 2008 at 9:15 AM, Martin Webb <[EMAIL PROTECTED]> > wrote: > > > Very happy to go down the DI path. I have no experience in Guice, but > > plenty in Spring. We (BT.com) will require consumption of existing > > components built with Spring - so as long as we can inject Spring based > > components within Guice based components failry easily then I have no > > complaints about using Guice. > > > > I'm not sure how we would swap out a Guice based component with a Spring > > based component without wrappering the Spring based one within the Guice > > based one? > > > > We also use Spring for JDNI datasouces, Hiberate and iBatis integration, > > xn > > semantics - does Guice provide any of this? > > > > ps It may sound like it :) but I'm not religious about the use of Spring > - > > I > > just need to know what we do/don't get with Guice, and then how easy it > is > > to use Spring on a needs-by-needs basis. > > > > Martin > > > > -- > > Internet Related Technologies - http://www.irt.org > > > -- ~Kevin
