Thanks Dhanji. I sorta figured that was the case. <rant> This seems extremely cumbersome and limiting to me. I see provider methods primary being used for third-party classes. In many cases, entire dependency trees can be determined via bindings and/or ImplementedBy. Forcing me to use constructors and methods seems really painful. Since most of my systems are based purely on interfaces I end up with many of these factories calling each other, all of which I need to maintain as I refactor. I just can't figure out what the Spring developers were thinking and why people are still using that framework. </rant>
-bp On May 7, 2010, at 7:16 PM, Dhanji R. Prasanna wrote: > Last time I checked that's how springs javaconfig worked. It's a bit > like a module with only provides methods. > > Dhanji. > > On Saturday, May 8, 2010, Brian Pontarelli <[email protected]> wrote: >> I have a client that is using the full Spring stack and I'm trying to figure >> out good ways to use their setup. I figured there might be other Guice users >> that have been in the same situation and could help. >> >> I wanted to use JSR 330, which I've recently realized is severely lacking. >> That API doesn't have any configuration interfaces or @ImplementedBy and >> that's where this process appears to get annoying. Spring provides the >> ability to declare a class as @Configuration, but then it appears to force >> me to define all my injections using factory methods and constructors. This >> essentially forces me to construct all the implementations of any interface >> by hand. If I have to write factories and constructors for everything I >> might as well use XML since they are essentially the same thing. >> >> Is this accurate or am I missing something vital that makes Spring actually >> a DI container and not a factory facade? >> >> Any suggestions would be much appreciated. >> >> -bp >> >> -- >> You received this message because you are subscribed to the Google Groups >> "google-guice" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/google-guice?hl=en. >> >> > > -- > You received this message because you are subscribed to the Google Groups > "google-guice" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/google-guice?hl=en. > -- You received this message because you are subscribed to the Google Groups "google-guice" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-guice?hl=en.
