-
1. Re: Refactoring Seam project to Spring
asookazian Jan 7, 2010 2:14 AM (in response to 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 Jan 7, 2010 10:10 AM (in response to asookazian)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 thatSeam 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 managerschoose a problem for their preferred technology
). We've just started a short review of such a project where aa certain Microsoft java-clone
is the preferred standard and where all kind of beautifulnot-portable, not open-source
libraries are used. The project is nearly dead because of thistechnology 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 avery 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 Jan 7, 2010 12:07 PM (in response to asookazian)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 Jan 7, 2010 12:09 PM (in response to asookazian)
would be to keep Spring / Jsf / Richfaces / Facelets stack for the presentation layerSorry errata !
would be to keep Spring / Jsf / Richfaces / Facelets and SEAM stack for the presentation layer
-
5. Re: Refactoring Seam project to Spring
luxspes Jan 7, 2010 4:32 PM (in response to asookazian)
Arbi Sookazian wrote on Jan 07, 2010 02:01:
Spring is our corporate standard and this particular application is alegacy
app built by an acquired company and apparentlySeam 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 Jan 7, 2010 7:05 PM (in response to 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?