1 2 3 Previous Next 63 Replies Latest reply on Nov 13, 2009 2:07 PM by Pete Muir

    It's not about dependency injection

    Arbi Sookazian Master

      http://www.jboss.org/feeds/post/it_s_not_about_dependency_injection


      I've had some very recent experience with the front controller pattern (used in Struts and Spring MVC).  And generally speaking, I favor component-based MVC like JSF, Wicket, Tapestry over action-based MVC.


      But is 299 more about contexts or DI?  or event notification mechanisms?  or all in equal portions in terms of importance?


      B/c it seems to me that it in fact to a certain extent is about DI...

        • 1. Re: It's not about dependency injection
          Arbi Sookazian Master

          And if you are talking about a better Spring, Seam does not even have the equivalent of Spring's JdbcTemplate which is a very useful data access component which makes JDBC much cleaner and easier (i.e. no connection leaks and boilerplate code).  In some cases JPA and/or Hibernate is not a good option for legacy schemas which may be missing foreign keys and not in 3NF, for example.  So JDBC or iBATIS (sql mapping) may be better options.  Of course, we can use Spring modules as integrations in our Seam apps.


          People are going to evaluate EE 6 and ask what does this stack offer that we can't currently accomplish with Spring 3 and dm server

          • 2. Re: It's not about dependency injection
            Gavin King Master
            Seam does not even have the equivalent of Spring's JdbcTemplate which is a very useful data access component which makes JDBC much cleaner and easier.


            I'm sure you'll find it's trivial to integrate a JDBC framework as a portable extension to CDI. The idea that anyone would choose to adopt the entire Spring application architecture just to get a JDBC framework is absurd.


            I'm sure if someone cares enough, they will port the Spring JdbcTemplate stuff to CDI. That's not at all a difficult task.


            (It's even completely trivial to integrate iBATIS in Seam.)


            People are going to evaluate EE 6 and ask what does this stack offer that we can't currently accomplish with Spring 3 and dm server?


            I certainly hope they do, since there are so many good answers to that question.

            • 3. Re: It's not about dependency injection
              Nicklas Karlsson Master

              Arbi Sookazian wrote on Nov 04, 2009 06:41:

              People are going to evaluate EE 6 and ask what does this stack offer that we can't currently accomplish with Spring 3 and dm server


              Shouldn't the first question asked be Now that we get this for free as a standard, what added value do we get from a VC backed framwork? ;-)


              And yes, Spring Framework is open source but any project has a number N where N is the number of people removed from the top of the hierarchy after which the project is pretty much doomed. Seam is not exception. That's why standards are good. A vendor switch results in rewriting but the amount of work shouldn't be huge if both are based on the same standard.

              • 4. Re: It's not about dependency injection
                Gavin King Master

                what added value do we get from a VC backed framwork?

                Rrrrm, that would be a VMWare backed framework now, Nick :-)

                • 5. Re: It's not about dependency injection
                  Nicklas Karlsson Master

                  Gavin King wrote on Nov 04, 2009 08:36:


                  what added value do we get from a VC backed framwork?

                  Rrrrm, that would be a VMWare backed framework now, Nick :-)


                  Oh right! Forgot about the deal. But the point stands, if company X pays big bucks for something, they will want to have their ROI even if it means twisting the product to whatever their needs happen to be.


                  Sounds a but FUD:dy but it's not paranoia if they really are out to get you ;-)

                  • 6. Re: It's not about dependency injection
                    Arbi Sookazian Master

                    Perhaps a lot of these technologies, concepts and integrations, etc. are trivial for the JBoss team.  Not for me and other corporate developers in the real world.  I spent hundreds of hours over the last few years learning EE 5 and Seam, etc. and still don't consider myself a master by any means.


                    Remember, just b/c it's trivial for you (someone who designed and implemented an ORM technology, for example) does not mean it will be trivial for everyone else.


                    Is it trivial to use Hibernate with legacy db schemas that don't have proper referential integrity (i.e. foreign keys) defined in all the places they should be defined?  Most likely not, and then you may choose to use iBATIS or Spring JDBC (yes, I know Hibernate supports stored procs but JPA 1.0 does not AFAIK).


                    One of these days, web app technology with AJAX and distributed tx's and HTTP/REST will be very old school.  Isn't the Commodore 64 completely forgotten now?

                    • 7. Re: It's not about dependency injection
                      Werner Keil Newbie

                      That is a little bit like the impression SpringSource's (that would be VMWare now, too ;-) lack of interest in the DI standard (JSR-330) they actually had SpecLead responsibilities in seemed to me...


                      Twisting the product of course means, people not only have to buy or at least download the latest version, you can also justify the low innovations elsewhere with some changes in this area. And have people pay for training to adopt to those twists.

                      • 8. Re: It's not about dependency injection
                        Francisco Jose Peredo Noguez Master

                        Arbi Sookazian wrote on Nov 05, 2009 00:51:


                        Perhaps a lot of these technologies, concepts and integrations, etc. are trivial for the JBoss team.  Not for me and other corporate developers in the real world.  I spent hundreds of hours over the last few years learning EE 5 and Seam, etc. and still don't consider myself a master by any means.

                        Remember, just b/c it's trivial for you (someone who designed and implemented an ORM technology, for example) does not mean it will be trivial for everyone else.


                        Totally agree with you here.



                        Is it trivial to use Hibernate with legacy db schemas that don't have proper referential integrity (i.e. foreign keys) defined in all the places they should be defined?  Most likely not, and then you may choose to use iBATIS or Spring JDBC (yes, I know Hibernate supports stored procs but JPA 1.0 does not AFAIK).


                        It is not trivial, of course (it is not even trivial to deal with nulls between different JPA implementations)



                        One of these days, web app technology with AJAX and distributed tx's and HTTP/REST will be very old school.  Isn't the Commodore 64 completely forgotten now?


                        I can not wait for the day when the world finally leaves AJAX, HTTP and REST behind!

                        • 9. Re: It's not about dependency injection
                          Gavin King Master
                          Perhaps a lot of these technologies, concepts and integrations, etc. are trivial for the JBoss team. Not for me and other corporate developers in the real world.


                          I didn't say that you had to personally do it. But someone will do it. That's the value of having a standard like CDI and the portable extension SPI: it's a common environment that open source framework developers can target. I certainly hope that JBoss are not going to be the only folks building portable extensions for CDI. The whole idea is to open up a new ecosystem there.

                          • 11. Re: It's not about dependency injection
                            Gavin King Master

                            Kungfu Panda, please use your real name here. We're fussy about that stuff ;-)

                            • 12. Re: It's not about dependency injection
                              Arbi Sookazian Master

                              perhaps that is his real name (e.g. Marilyn Manson and Hollywood actors).  and does it really matter?  It's bad enough that we're forced to use action-based MVC frameworks in the real world like Struts 1.x and Spring MVC.  I'm really starting to get a feel for how unnecessarily complex and over-complicated Spring 2.x framework really is...  Missing Seam...  Juergen Hoeller is a dork.



                              One goal of the JPA specification was to make the technology pluggable. To enable this, the roles of container provider (the container or the side that has control of the runtime threads and transactions), and persistence provider (the provider or the part that implements the persistence API and manages the persistent entities) were defined, and a service provider interface (SPI) binds the two at deployment and runtime. A compliant JPA host container correctly implements this SPI from the container perspective. A compliant JPA persistence provider implements the SPI from the provider perspective. If both sides follow the rules, a compliant container should be able to run any compliant persistence provider implementation, and similarly, a provider should plug into any container.

                              http://java.sys-con.com/node/366275


                              The SPI idea is a good one...


                              btw, I said: Not for me and other corporate developers in the real world.


                              But that's ok.  JBoss is human, or perhaps becoming oragnicized with OSGi compliance?

                              • 13. Re: It's not about dependency injection
                                Francisco Jose Peredo Noguez Master

                                Arbi Sookazian wrote on Nov 06, 2009 00:35:


                                One goal of the JPA specification was to make the technology pluggable. To enable this, the roles of container provider (the container or the side that has control of the runtime threads and transactions), and persistence provider (the provider or the part that implements the persistence API and manages the persistent entities) were defined, and a service provider interface (SPI) binds the two at deployment and runtime. A compliant JPA host container correctly implements this SPI from the container perspective. A compliant JPA persistence provider implements the SPI from the provider perspective. If both sides follow the rules, a compliant container should be able to run any compliant persistence provider implementation, and similarly, a provider should plug into any container.


                                Nice idea in theory (that about multiple compatible JPA implementations) not true in practice, but nice in theory.




                                The SPI idea is a good one...
                                btw, I said: Not for me and other corporate developers in the real world.



                                As I was saying, nice in theory, sadly we work in the real world. Unless the TCK (or something equivalent that makes it possible for the community to objectively test compatibility) because easy available interchangable SPIs will remain as only a nice dream.




                                But that's ok.  JBoss is human, or perhaps becoming oragnicized with OSGi compliance?


                                Not sure what do you mean, but I certainly hope JBossAS (and all other Jboss projects) gain OSGi support soon.

                                • 14. Re: It's not about dependency injection
                                  Gavin King Master

                                  Nice idea in theory (that about multiple compatible JPA implementations)

                                  Francisco, I'm getting increasingly annoyed with you posting the same pet issue on every single thread in every message board. The Hibernate team has many important issues to deal with like implementing JPA2 and fixing actually important bugs. The question of what exception type gets thrown when you have marked your attribute as not-null at the schema level, but not at the object level (which is more or less your own programming error) is just not one of them. So please give it a rest for f***s sake.



                                  Unless the TCK (or something equivalent that makes it possible for the community to objectively test compatibility) because easy available interchangable SPIs will remain as only a nice dream.

                                  The 299 SPI is part of the spec and therefore it is of course tested by the TCK.


                                  Is it going to be as well-tested by the TCK as other parts of 299, well, no, probably not. Is it likely that there will initially be some teething problems with some kinds of portable extensions? Yes, I imagine there probably will be. However, I'm quite certain that the Open Web Beans, CanDI and Weld teams will all be very keen to work together to get the wrinkles ironed. If anything needs spec clarification, we can do that in the first maintenance release of 299.

                                  1 2 3 Previous Next