1 2 Previous Next 26 Replies Latest reply on Oct 7, 2009 4:08 PM by luxspes

    Manning DI book

    asookazian

      So I was briefly reading the new DI book from Manning.  It briefly mentioned Seam in the intro to dependency injection frameworks but I did not see any reference to 299 or Web Beans.  I also did not see the author mention the fact that Seam uses dynamic DI whereas Spring uses static DI. Or any general coverage on the differences b/n the two approaches/techniques.  But I didn't read too much of it honestly.  Now I'm wondering if Guice (which 299 is partially based on) uses static or dynamic DI.

        • 1. Re: Manning DI book
          meetoblivion

          Dynamic DI is essentially what the @Produces is for.  From what I remember, Guice doesn't support this currently either.


          Personally, I don't see much of a difference between these two statements:


          #{myProducerFacade.someProducedType}


          and


          #{someProducedType}


          I mean, all you're doing is exposing an object from the getter/setter, so using a producer facade (or factory) that can return current instance of whatever you're dealing with (I do it right now in some JSF apps, while I wait for CDI to become more production ready)


          You figure the backing code for #{someProducedType} is going to be something like:


          @Produces @SomeBindingType public SomeProducedType makeSomeProducedType() { /** **/ }


          what that seems to mean to me, is that the bean that makes SomeProducedType cannot save SomeProducedType (at least not without some circular dependency issues...)

          • 2. Re: Manning DI book
            crazybob.seamframework.crazybob.org

            John,


            @Produces was actually inspired by Guice's @Provides, which is almost exactly the same except for the name.


            Bob

            • 3. Re: Manning DI book
              asookazian

              So why don't Spring DI and Guice support dynamic injection?  Are there minimal use cases that utilize those frameworks that need dynamic injection?


              I know that Seam is stateful and Spring is stateless, but that may have nothing to do with it...


              So there is no way to configure Spring DI or Guice to become dynamic (freshly injected values like in Seam components)?

              • 4. Re: Manning DI book
                gavin.king

                Bob Lee wrote on Oct 05, 2009 20:41:


                @Produces was actually inspired by Guice's @Provides, which is almost exactly the same except for the name.


                Actually, if I recall correct, it came from Seam's @Factory.

                • 5. Re: Manning DI book
                  crazybob.seamframework.crazybob.org
                  Gavin, I'm not trying to take credit for your idea. I didn't even come up with the idea of provider methods in Guice (http://is.gd/3ZcjO). I was just emphasizing that Guice not only does have them, but it's had them for some time.

                  Arbi, are you talking about re-injecting the fields of an object every time you call a method on it? This approach doesn't scale when applied to wider scopes like application scope. This is why 299 uses proxies instead.

                  Guice doesn't support proxies because they make code more difficult to understand. We prefer to inject Provider<T> instead of a proxy of T. Then, the user controls when the object gets resolved, the object's identity is meaningful (for example, having N OrderLine instances is more straighforward than 1 OrderLine instance that magically changes its state depending on the context), and you can safely take the object and use it outside of the current context (comparing it for equality or storing it in a collection, for example).

                  I think Spring supports proxying, too.
                  • 6. Re: Manning DI book
                    gavin.king

                    IMO, reinjection and proxies are just two different implementations of the notion of dynamic injection, i.e. the idea that the identity of the object referred to by the injected reference depends upon the context in which the reference is invoked.


                    After practical experience with Seam, we ended up deciding that reinjection was not the best approach, and decided to switch to the use of proxies in JSR-299 and Weld.

                    • 7. Re: Manning DI book
                      asookazian

                      Bob Lee wrote on Oct 05, 2009 23:33:


                      Arbi, are you talking about re-injecting the fields of an object every time you call a method on it? This approach doesn't scale when applied to wider scopes like application scope. This is why 299 uses proxies instead.



                      Yes, that's exactly what I'm talking about.

                      • 8. Re: Manning DI book
                        asookazian

                        Gavin King wrote on Oct 06, 2009 00:31:


                        IMO, reinjection and proxies are just two different implementations of the notion of dynamic injection, i.e. the idea that the identity of the object referred to by the injected reference depends upon the context in which the reference is invoked.

                        After practical experience with Seam, we ended up deciding that reinjection was not the best approach, and decided to switch to the use of proxies in JSR-299 and Weld.


                        If Spring supports proxying and reinjection and proxies are essentially the same in terms of the end result of dynamic injection, then why does DAllen refer to Spring as providing a static injection mechanism via setter and constructor injection? 


                        What do you mean by after practical experience with Seam?  You mean clients who have had performance problems using Seam 2.x and prior apps?  I know a CTO in LA who hired DAllen and they ended up not using bijection at all using in order to bypass interceptors as a performance optimization.  They simply use setter injection.


                        And what is Weld, never heard of that...

                        • 9. Re: Manning DI book
                          asookazian

                          Perhaps Spring supports dynamic injection via multiple calls to setter methods in the same classes?

                          • 10. Re: Manning DI book
                            asookazian
                            Web Beans = Weld

                            |http://jboss.org/feeds/post/the_jsr_299_reference_implementation_gets_a_new_name|

                            how many more name changes dude?  it's getting old already...

                            Why aren't there any frameworks out there named Annihilator or Gojira or something more "fun" than Hessian and Burlap???

                            Weld?
                            • 11. Re: Manning DI book
                              gavin.king

                              If Spring supports proxying and reinjection and proxies are essentially the same in terms of the end result of dynamic injection, then why does DAllen refer to Spring as providing a static injection mechanism via setter and constructor injection?

                              I'm not an expert on Spring so I may therefore be wrong about this, but as far as I know, Spring does not use proxies to achieve dynamic injection. It uses proxies for other stuff, like interceptors.

                              • 12. Re: Manning DI book
                                gavin.king

                                This is the first time the name of the RI has changed. What happened previously was that the name of the specification changed. Of course neither name change was our preference, so it's a bit unfair to be bitching at us about it.

                                • 13. Re: Manning DI book
                                  meetoblivion

                                  Gavin King wrote on Oct 06, 2009 02:07:


                                  This is the first time the name of the RI has changed. What happened previously was that the name of the specification changed. Of course neither name change was our preference, so it's a bit unfair to be bitching at us about it.


                                  it seems odd that other vendors get to choose the name of your software.  if that's the case, all other webmail providers should force google to rename gmail to grope.



                                  Gavin King wrote on Oct 06, 2009 02:05:


                                  If Spring supports proxying and reinjection and proxies are essentially the same in terms of the end result of dynamic injection, then why does DAllen refer to Spring as providing a static injection mechanism via setter and constructor injection?

                                  I'm not an expert on Spring so I may therefore be wrong about this, but as far as I know, Spring does not use proxies to achieve dynamic injection. It uses proxies for other stuff, like interceptors.


                                  like i wanted to say earlier, calling proxying and reinjection the same thing doesn't work.  you're correct, the primary use of proxies in spring is AOP.  when you say reinjection and proxies are just two different implementations of the notion of dynamic injection should probably be more like dynamic injection can be implemented using proxies or the reinjection principal

                                  • 14. Re: Manning DI book
                                    asookazian

                                    Gavin King wrote on Oct 06, 2009 02:07:


                                    This is the first time the name of the RI has changed. What happened previously was that the name of the specification changed. Of course neither name change was our preference, so it's a bit unfair to be bitching at us about it.


                                    Well, I guess I can't argue.  But you'd imagine that if you were a spec lead and the other members of the EG (or the community?) forced or mandated a name change against the direction of the spec lead, something may be amiss.


                                    So, sorry, but the EGs should try to at least nail down the names in the beginning of the JSR formations, etc.


                                    So Weld it is (for now).

                                    1 2 Previous Next