6 Replies Latest reply on Jan 7, 2010 7:05 PM by asookazian

    Refactoring Seam project to Spring

    asookazian

      We may need to refactor our existing Seam 2.x project running JSF/RF/EJB3/JPA/Hibernate/Facelets and replace with Spring.  I have never done this before.  Any experiences with this task and what to plan for in terms of man hours and what to expect?  Obviously, it depends whether or not we will even keep the existing presentation layer as JSF 1.2 with Facelets (which I'm assuming Spring 2.5 supports).  Also, Spring 2.x supports JPA and Hibernate as well so the persistence layer may require minimal refactoring.  The main impact will be the DI/IoC and interceptor/AOP code.  Any other major impacts?  I'm imagining refactoring conversation management (LRCs) and page flows.  Does Spring support conversation management without Spring Web Flow?  Also, I don't believe there is any use of SMPC and Hibernate manual flush so this may make the refactoring somewhat easier.


      Spring is our corporate standard and this particular application is a legacy app built by an acquired company and apparently Seam needs to go.  One chief complaint from mananagement is difficulty in finding experienced Seam/EE5 developers.  There also seems to be a partial conception that apps are built faster when used Spring vs. Seam.  I'm really not sure if this blanketed statement is true or not.  The Spring and rest of the Frankenstein stack has a hefty learning curve (especially the unnecessarily complicated AOP) and may take quite a while to learn and code in depending on what libraries you use and your project/use-cases.


      It would be nice if we could use Spring 3 but large companies don't jump on latest releases that quick...

        • 1. Re: Refactoring Seam project to Spring
          asookazian

          Has anybody converted the Seam hotel booking app to a Spring version?  Apparently the faces-config.xml is used for page navigation rather than pages.xml and we need managed beans b/c Seam is no longer there to bridge the presentation tier and business tier.  Although if you use JSF2 and Spring 2.5/3 this is no longer the case?


          This is interesting: The focus of this series of blogs was to show the same app build using first just Java EE , then Java EE with Spring , then Java EE with Seam (with Netbeans and Glassfish). I also did the same app using JRuby and Rails.


          http://weblogs.java.net/blog/caroljmcdonald/archive/2008/01/sample_applicat_5.html

          • 2. Re: Refactoring Seam project to Spring
            lvdberg

            Hi Arbi,


            I can't help you much with your Seam2Spring problem, we basically did it the other way around. To call Seam legacy and to state that Seam has to go, because Seam is not a corporate standard shows that your employer's management is a bit short-sighted and lacks a clear technological vision. (please feel free to send this message also to your managers...)


            I've worked at public administration where corporate standards are a must, but I've seen also a lot of flexibility regarding using these specific involved technology choices. Technologies should be hand-picked for a specific project, if possible from the corporate shortlist, but such a choice should always be based on clear requirements (I've seen a lot of projects where technical managers choose a problem for their preferred technology). We've just started a short review of such a project where a a certain Microsoft java-clone is the preferred standard and where all kind of beautiful not-portable, not open-source libraries are used. The project is nearly dead because of this technology first approach without focussing first on the problem and the requirements for a solution. Another audit we did was to review another port from Microsoft to Java, for exactly the same silly reason of not being a corporate standard. Both projects have a very happy user group , because they only hear about delays, changes in their user-interface and less functionality.


            Hopefully you're not in the same situation and you have managers who know what the're doing. If not, start looking for a more exciting job...


            Best regards and the very best for 2010


            Leo
             


            • 3. Re: Refactoring Seam project to Spring
              gonzalad

              Just a question, are you going to keep Jsf or not ?


              If you're keeping Jsf, then a good way to go IMO (if you absolutely must migrate to Spring that is), would be to keep Spring / Jsf / Richfaces / Facelets stack for the presentation layer and use Spring for your services / data access layer.


              You just need then to configure Seam properly to use Spring txManager, and also you can keep using Seam SMPC (the Seam entityManager being defined in Spring).


              In this way, you can present Seam to your team as just being an add-on on JSF.

              • 4. Re: Refactoring Seam project to Spring
                gonzalad

                would be to keep Spring / Jsf / Richfaces / Facelets stack for the presentation layer

                Sorry errata !


                would be to keep Spring / Jsf / Richfaces / Facelets and SEAM stack for the presentation layer


                • 5. Re: Refactoring Seam project to Spring

                  Arbi Sookazian wrote on Jan 07, 2010 02:01:


                  Spring is our corporate standard and this particular application is a legacy app built by an acquired company and apparently Seam needs to go.  One chief complaint from mananagement is difficulty in finding experienced Seam/EE5 developers.


                  Well, if the place where you work is full of Spring experts, I guess it makes sense to unify the code into a single platform.



                  There also seems to be a partial conception that apps are built faster when used Spring vs. Seam.   I'm really not sure if this blanketed statement is true or not.


                  Why? Did they built a Seam application that end-up taking much more time than planned? It is often important to find out the source of this kind of conceptions... maybe they tried Seam, and then rejected it because of the time the had to use to learn it? time they could have used actually building something with business value in a technology they already know... IMO it almost always slower to try something new than to continue with something you already know, regardless of the merits of the new technology...



                  The Spring and rest of the Frankenstein stack has a hefty learning curve (especially the unnecessarily complicated AOP) and may take quite a while to learn and code in depending on what libraries you use and your project/use-cases.


                  That sounds like you are having the exact same problem they have with Seam, but with Spring... the difference is that you have more experience with Seam, and therefore you assume it is better, but it may only seem like that to you because you are more experienced with it than with Spring... on the end you might be as much a victim of your own bias as they are... ;-)



                  It would be nice if we could use Spring 3 but large companies don't jump on latest releases that quick...


                  Latest releases? Seam 3 has already been released? AFAIK Seam 3 is still unreleased software...

                  • 6. Re: Refactoring Seam project to Spring
                    asookazian

                    There are no finalized plans.  Perhaps going forward we can do http://www.manning.com/dallen/SeamIACH15_bonus.pdf Seam/Spring integration and write Spring beans for new use cases.  That way there is no drastic overhaul complete replacement of Seam with Spring.


                    Anybody have experience with this?