1 2 3 Previous Next 66 Replies Latest reply on Jan 24, 2011 2:40 PM by asookazian

    Selling Weld and EE6

    asookazian

      So regarding the issue of selling Weld and EE6 to developers/shops....


      How bout a JdbcTemplate Spring equivalent in the case of projects using legacy db schemas where we can't use Hibernate due to normalization problems, recursive joins, etc. and/or want to hand-tune our own sql?


      http://static.springsource.org/spring/docs/2.5.6/reference/jdbc.html


      This could be a portable extension to Weld (I view it as a sub-component/JAR).  This is one of the main reasons we are using Spring at my current shop (along with DI, of course).  Others will argue against reinventing the wheel, but isn't that what Microsoft does (so well) all the time?

        • 1. Re: Selling Weld and EE6
          william.drai

          Honestly I don't see any value in switching to CDI if it is to reproduce the same awful patterns.


          It would probably be useful to have a portable extension to deal with plain JDBC, but please not this Dao/Template mess. Otherwise just use a Spring adapter for CDI.

          • 2. Re: Selling Weld and EE6
            asookazian

            Part of the goal of CDI/EE6 is to switch over Spring users, no?  Spring, Struts 1.x, and Hibernate are the Java frmwks that are currently deployed all over the world in production clusters, no?  So switching Struts/Spring projects over to EE6 (or related) would be a good thing, no?


            So making some tools available that Spring users currently use would be beneficial as bait, unless it's really trivial to integrate Spring with Seam or Weld, for example, and then perhaps there's no need to have something basic and useful like JdbcTemplate already available as part of a portable extension.


            IIRC, the Spring-Seam integration chapter of SiA (online) was not trivial...

            • 3. Re: Selling Weld and EE6
              gavin.king

              William Draï wrote on Nov 24, 2009 23:57:


              Honestly I don't see any value in switching to CDI if it is to reproduce the same awful patterns.

              It would probably be useful to have a portable extension to deal with plain JDBC, but please not this Dao/Template mess. Otherwise just use a Spring adapter for CDI.



              Amen. Their template pattern is a solution in search of a problem.

              • 4. Re: Selling Weld and EE6
                asookazian

                Well, the reason we like it is that it's better than using straight JDBC with the boiler-plate cleanup code and possible connection leaks, etc.  JdbcTemplate handles this for you.


                Here is an interesting blog: even the so-called Spring Templates actually uses the Strategy pattern. - http://ice09.wordpress.com/2009/11/09/scala-mashup-series-the-template-method-in-java-spring-and-scala/


                My point is not to reuse Spring HibernateDaoSupport and JdbcTemplate types in EE6.  It's to make something similar available to those who will be using CDI/Seam3...


                I guess it may help to forget about Spring specifically and think about what current Java devs are using in terms of tools and patterns/APIs so a proper stepping stone to EE6/Weld can be created.  So contexts, interceptors (alternative to AOP), DI are good examples that are already covered.


                What about if you need a remoting solution like we have in Seam 2.x (Seam remoting) but don't want to use Seam3?  So a remoting PE for Weld?  What if I only want to use part of Seam3 and not necessarily the core (Weld)??  Pluggable architecture.

                • 5. Re: Selling Weld and EE6

                  Arbi Sookazian wrote on Nov 24, 2009 23:36:


                  So regarding the issue of selling Weld and EE6 to developers/shops....

                  How bout a JdbcTemplate Spring equivalent in the case of projects using legacy db schemas where we can't use Hibernate due to normalization problems, recursive joins, etc. and/or want to hand-tune our own sql?


                  Why no use JdbcTemplate directy... all the beans in there are independent from Spring core. You can easily use then in Weld:


                  
                  @Produces
                  public JdbcTemplate createJdbcTemplate(javax.sql.DataSource datasource){
                  
                  return new JdbcTemplate(datasource);
                  
                  } 
                  
                  
                  




                  http://static.springsource.org/spring/docs/2.5.6/reference/jdbc.html

                  This could be a portable extension to Weld (I view it as a sub-component/JAR).  This is one of the main reasons we are using Spring at my current shop (along with DI, of course). 


                  As I have shown, it is as easy as writing a @Produces method... if you need it you can do it for your app...



                  Others will argue against reinventing the wheel, but isn't that what Microsoft does (so well) all the time?


                  Like when the created .NET with a solution for classpath hell since version 1.0? or like when they added annotations to C# before Java? or perhaps like when they added generics before Java?... no no... it is like when they added closures before Java!... mmmmm, no I must be confused, this looks like Sun does this all the time... ;-)


                  The truth is in this business (like in many others) everybody copies everybody, the important thing is doing it better, but Spring-JDBC beans can be used as they are in Weld so... what new feature would your Weld-Jdbc provide?



                  • 6. Re: Selling Weld and EE6

                    Arbi Sookazian wrote on Nov 25, 2009 00:11:


                    IIRC, the Spring-Seam integration chapter of SiA (online) was not trivial...


                    The non trivial part was integrating JPA, plain bean integration was extremely  easy... and with Weld, I hope it gets even easier...

                    • 7. Re: Selling Weld and EE6

                      Gavin King wrote on Nov 25, 2009 01:18:


                      Amen. Their template pattern is a solution in search of a problem.


                      Really? And what would be your proposal for dealing with JDBC? JPA? Remember that JPA only works for databases that are explicitly designed for it...

                      • 8. Re: Selling Weld and EE6
                        gavin.king

                        Francisco Peredo wrote on Nov 25, 2009 01:48:



                        Gavin King wrote on Nov 25, 2009 01:18:


                        Amen. Their template pattern is a solution in search of a problem.


                        Really? And what would be your proposal for dealing with JDBC? JPA? Remember that JPA only works for databases that are explicitly designed for it...


                        There are plenty of JDBC helper frameworks. Google can help you find them. Very few of them use the template pattern, since it is a seriously backward way to do resource and exception handling. You might notice that JPA and EJB work together to manage your transactions, persistence contexts and exceptions for you very nicely and cleanly, without any templates or other weird inner classes. You can easily do the same with any other simple JDBC wrapper.

                        • 9. Re: Selling Weld and EE6

                          Arbi Sookazian wrote on Nov 25, 2009 01:41:


                          My point is not to reuse Spring HibernateDaoSupport and JdbcTemplate types in EE6.  It's to make something similar available to those who will be using CDI/Seam3...


                          Sounds doable... but you need to be more concrete...



                          I guess it may help to forget about Spring specifically and think about what current Java devs are using in terms of tools and patterns/APIs so a proper stepping stone to EE6/Weld can be created.


                          Well, a lot of people here are not going to like what I am going to write but: current Java devs... use Spring.



                          So contexts, interceptors (alternative to AOP), DI are good examples that are already covered.

                          What about if you need a remoting solution like we have in Seam 2.x (Seam remoting) but don't want to use Seam3?  So a remoting PE for Weld?  What if I only want to use part of Seam3 and not necessarily the core (Weld)??  Pluggable architecture.


                          You can probably use Spring beans as Weld beans with a little glue code... I guess you should try and see what is possible

                          • 10. Re: Selling Weld and EE6
                            gavin.king

                            Well, the reason we like it is that it's better than using straight JDBC with the boiler-plate cleanup code and possible connection leaks, etc. JdbcTemplate handles this for you.

                            Because, of course, there are no other well-known patterns for dealing with boiler-plate cleanup code and connection leaks.


                            This is exactly the kind of brain-damage that Spring does to people! It gives people a half-assed solution, and somehow shuts down their brains so they stop asking themselves how this solution could be improved upon. It's a very impressive magic trick, and I wish I knew how to do it myself. But then, I'm just not like that. I'm always trying to poke holes in things - whether they were Invented Here or Not.

                            • 11. Re: Selling Weld and EE6
                              gavin.king

                              You can probably use Spring beans as Weld beans with a little "glue code"... I guess you should try and see what is possible

                              We will be providing a portable extension that does this for you, with no need for any glue at all. It will automagically discover all the beans you have in Spring, and let you inject them with @Inject.

                              • 12. Re: Selling Weld and EE6

                                Gavin King wrote on Nov 25, 2009 01:51:


                                There are plenty of JDBC helper frameworks.


                                So many and so good you couldn't name one? Mmmmm....



                                Google can help you find them. Very few of them use the template pattern, since it is a seriously backward way to do resource and exception handling.


                                Really? Care to present little example (or at least a link to one) of the great superiority of this frameworks that are much better than Spring-JDBC?



                                You might notice that JPA and EJB work together to manage your transactions, persistence contexts and exceptions for you very nicely and cleanly, without any templates or other weird inner classes. You can easily do the same with any other simple JDBC wrapper.


                                I totally agree that using JPA is much more confortable for cases when you can use JPA, but the reality our here is that a lot of times you can not. I can understand that offering a solution for those cases is not one of your goals, but I do not think it is fair that you discount Spring-JDBC without offering a concrete example of something better.

                                • 13. Re: Selling Weld and EE6
                                  gavin.king

                                  I didn't say use JPA I said use a JDBC framework that wraps it. Lots of people like iBATIS, but that might be too high-level for your taste. Their are other, less-abstract options.

                                  • 14. Re: Selling Weld and EE6

                                    Gavin King wrote on Nov 25, 2009 02:06:


                                    I didn't say use JPA I said use a JDBC framework that wraps it. Lots of people like iBATIS, but that might be too high-level for your taste. Their are other, less-abstract options.


                                    iBATIS is your idea of something better than Spring-JDBC? sigh

                                    1 2 3 Previous Next