Discussions

News: Company Migrates Application from Struts to JavaServer Faces

  1. In the Trenches is a new series about real world projects that use JavaServer Faces. This installment looks at how Global Apparel Network BV migrated an existing application from Struts and Hibernate to JSF, JDO, and Magnolia. They have since standardized on JSF as the corner stone of their new web development projects.
    Senior Developer Dave Sag and his team at Global Apparel Network BV decided to get their feet wet with JavaServer Faces (JSF) by migrating an internal customer support tool from Struts. "We wanted a small and simple, real project to prototype JSF, having worked with Struts for years and built v1.0...with Struts. We migrated from Hibernate to JDO (Java Data Objects) at the same time, so that was interesting too." Instead of migrating from Struts incrementally using the Struts-Faces integration library, the team chose to migrate the whole application at once. Even though Sag believes there are a few things Struts makes easier, overall he found JSF to be simpler and more robust. The main mental hurdle for the team was thinking in terms of JSF events instead of Struts Actions.
    Read Company Migrates Application from Struts to JavaServer Faces.

    Threaded Messages (27)

  2. Why hibernate to jdo?[ Go to top ]

    I respect jdo, but I'm just curious why the call was made on this project to migrate from hibernate to it. What was so compelling about jdo over hibernate, especially when you hear stuff like this:

    http://www.theserverside.com/news/thread.tss?thread_id=32200
    The existing JDO community will be supported, and we should expect to see a 2.1 release in the near term that outlines migration to EJB 3. Beyond that the expectation is that EJB 3 will continue as the sole persistence mechanism for Java.

    On the other hand, with Gavin on the ejb3 expert group, and hibernate3 being used by jboss to be their ejb3 implementation...

    Why put so much effort to migrate to a technology that seems to be stuggling to stay alive? No matter how great jdo is, perception seems to govern many IT decisions. The perception is that ejb3 will win out, and the only reason jdo 2.0 was approved was so that people that have been stuck on the current version for so long can finally get the 2.0 features they've been waiting for.
  3. Why hibernate to jdo?[ Go to top ]

    I respect jdo, but I'm just curious why the call was made on this project to migrate from hibernate to it. What was so compelling about jdo over hibernate, especially when you hear stuff like this:http://www.theserverside.com/news/thread.tss?thread_id=32200
    The existing JDO community will be supported, and we should expect to see a 2.1 release in the near term that outlines migration to EJB 3. Beyond that the expectation is that EJB 3 will continue as the sole persistence mechanism for Java.
    On the other hand, with Gavin on the ejb3 expert group, and hibernate3 being used by jboss to be their ejb3 implementation...Why put so much effort to migrate to a technology that seems to be stuggling to stay alive? No matter how great jdo is, perception seems to govern many IT decisions. The perception is that ejb3 will win out, and the only reason jdo 2.0 was approved was so that people that have been stuck on the current version for so long can finally get the 2.0 features they've been waiting for.

    I choose JDO for what I do because (1) with JDO 2.0 it is a rich and full-featured JSR specification for POJO persistence and (2) there are many vendors providing competing implementations (as well as free versions). Even though Hibernate is a high-quality product, I prefer to have multiple suppliers for technologies I use. Also, I know that many JDO vendors will implement both JDO 2.0 AND EJB 3.0 POJO persistence in the same product, and will allow the use of both APIs at the same time in the same code. This gives developers an easy mechanism for gradually migrating to EJB 3.0 POJO persistence if that API turns out to be richer and more powerful than JDO 2.0. (Hibernate may well intend to provide an equally easy migration to EJB 3.0 POJO persistence - I don't know enough about this to comment).

    JDO is certainly not 'struggling to stay alive' - as one member of the EC said: there is a 'vibrant JDO community'. When EJB 3.0 comes out, JDO will not suddenly vanish, with the JSR specification being erased from the JCP site! Also, no amount of 'expectation' that one spec should be standard will force developers to switch unless that spec is better.

    There are many JDO people in the EJB 3.0 expert group: it is a collaboration.
  4. Why hibernate to jdo?[ Go to top ]

    I choose JDO for what I do because (1) with JDO 2.0 it is a rich and full-featured JSR specification for POJO persistence and (2) there are many vendors providing competing implementations (as well as free versions). Even though Hibernate is a high-quality product, I prefer to have multiple suppliers for technologies I use. Also, I know that many JDO vendors will implement both JDO 2.0 AND EJB 3.0 POJO persistence in the same product, and will allow the use of both APIs at the same time in the same code. This gives developers an easy mechanism for gradually migrating to EJB 3.0 POJO persistence if that API turns out to be richer and more powerful than JDO 2.0. (Hibernate may well intend to provide an equally easy migration to EJB 3.0 POJO persistence - I don't know enough about this to comment).JDO is certainly not 'struggling to stay alive' - as one member of the EC said: there is a 'vibrant JDO community'. When EJB 3.0 comes out, JDO will not suddenly vanish, with the JSR specification being erased from the JCP site! Also, no amount of 'expectation' that one spec should be standard will force developers to switch unless that spec is better.There are many JDO people in the EJB 3.0 expert group: it is a collaboration.

    Have you looked enough in Spring? It gives you a much more elegant way for mixing different DB-access approaches than what you will, probabely, get with the mentioned vendors.

    Also, I do not think calling Hibernate a single-vendor product is accurate. Hibernate, unlike many vendor-products, is an open-source code that guarantees that you will not be locked into one vendor. That's what matters, so I do not buy that argument.
  5. Why hibernate to jdo?[ Go to top ]

    Have you looked enough in Spring? It gives you a much more elegant way for mixing different DB-access approaches than what you will, probabely, get with the mentioned vendors.

    I don't see how having interchangeable of products implementing the same API (excluding, of course, vendor extensions!) and even the same Object/Relational Mapping can be less elegant that having to abstract away the details using Spring or any other mechanism. No matter how much you hide the persistence mechanism, you are always going to have to do something API-specific somewhere.
    Also, I do not think calling Hibernate a single-vendor product is accurate.
    Who else provides and maintains the Hibernate source code?
    Hibernate, unlike many vendor-products, is an open-source code that guarantees that you will not be locked into one vendor. That's what matters, so I do not buy that argument.

    I think this is a common myth regarding open source. Having the source code for a product is nice, but I would not expect that many commercial developers would have the time (or motivation) to debug that source code or add new features themselves. Also, any changes you make for your own use will have to be re-applied to each subsequent release of the product. Finally, if you make changes, it becomes your responsibility to support them in deployed applications.

    Please don't take this as any criticism of Hibernate - but there are good reasons why many of us prefer products which can be obtained from multiple suppliers.

    In theory you aren't locked into one vendor, but in practice, you are.
  6. Why hibernate to jdo?[ Go to top ]

    Steve, forgive me, but I don't see why other vendors would write a better abstraction layer for JDO and Hibernate, than what is in Spring. But that's just my oppinion, hard to argue, because we do not know, yet. Future will show...

    In my mind, Hibernate is not what people, usually, call one-vendor product, because it's life does not depend on one vendor. Hibernate existed before JBoss would take the management of it, and can exist if JBoss, suddently dissapears. Also, people who submit code to Hibernate, are not all JBoss employs. That - on the code side. On the support side, I think third-party companies will emerge that will provide Hibernate support (if they do not, already, exist). Apache web-server is, also, officially associated with the Apache Foundation but a lot of consulting companies do third-party support for it.

    I agree with you, that most of the time you do not want to dig into the source-code of components that you use. But no component is perfect, right? When you have a critical problem and are able to go into the code and change it, to suite your needs - it is absolutely invaluable. This is why I, always, prefer to use OSS components, if possible. Also, so far, in my experience - Hibernate has been great in adopting outside code. They have been very understanding and much less possessive, than I have seen with some other projects.

    Back to the main topic - can anybody post an example code where JDO is, clearly, more efficient that Hibernate? I, still, do not understand why did that company switch from Hibernate to JDO. :(
  7. Why hibernate to jdo?[ Go to top ]

    Steve, forgive me, but I don't see why other vendors would write a better abstraction layer for JDO and Hibernate, than what is in Spring.

    You are missing the point. As I said, no matter how much you abstract - with or without Spring - at some stage you will have to have write code and XML specific to the persistence API. At some point you have to write query language, and O/R mapping. Wit JDO 2.0 these are (largely) interchangeable between different vendors implementations.

    Once you have spend time designing a mapping and tuning your JDOQL you can re-use it with another product.
    Future will show...In my mind, Hibernate is not what people, usually, call one-vendor product, because it's life does not depend on one vendor.

    So where are the other vendors supplying different implementations of Hibernate, and competing for performance of these implementations? That is one-vendor by any definition.
    I agree with you, that most of the time you do not want to dig into the source-code of components that you use. But no component is perfect, right? When you have a critical problem and are able to go into the code and change it, to suite your needs - it is absolutely invaluable. This is why I, always, prefer to use OSS components, if possible.

    There are open source JDO implementations, such as JPOX, so the same advantage applies.
    I, still, do not understand why did that company switch from Hibernate to JDO. :(

    Well, I don't know why they did, but I have given you clear reasons why some developers decide that they want multi-vendor products.

    Why the unhappiness? Hibernate is hugely successful, and is likely to remain so. However, competition is good.
  8. Why hibernate to jdo?[ Go to top ]

    Fair enough. Thanks, Steve.
  9. Why hibernate to jdo?[ Go to top ]

    Spring supports many different pesistence options... including JDO. We use JDO and Spring heavily in our software, which not only gives us the flexibilty to use a great persistence API (JDO), but also gives us the flexibility to change out persistence components ad-hoc (among other layers). I guess my question is if you have a great persistence API like JDO and Spring supports it, why even ask if he's considered looking into Spring (which I'm sure he's aware of)? Either way, it doesn't really speak to any reason he should favor Hibernate over JDO... it would just provide added flexibilty with a low-invasive profile. Snapping Spring into the equation isn't hard or too time consuming - even after the fact.

    I respect the argument about open-source code solutions. I am a contributor myself - and will always be. However, JDO is a spec and the only place you really start to run into vendor lock-in is if you use any of the "vendor specific" API's that go beyond what the original spec mandates. Albeit, pre-JDO 2.0, you may need to make changes to your descriptor file because the tags weren't standardized.

    I didn't mean for this to become a big Viva-la-JDO repsonse, but you should look into it more... especially if you are architecting solutions that will be distributed to multiple large-scale clients - each with customizations. There are many attractive attributes to JDO that align well with business. Especially if they are stand-offish towards open source.
  10. Why hibernate to jdo?[ Go to top ]

    I respect jdo, but I'm just curious why the call was made on this project to migrate from hibernate to it.

    read this as try hibernate *before* jdo ;)
  11. one company?[ Go to top ]

    If this is news, I think that it´s that JSF doesn´t go well in the market.
    I think Struts is far far away of disappearing, and it won´t be because of JSF...
  12. one company?[ Go to top ]

    If this is news, I think that it´s that JSF doesn´t go well in the market.I think Struts is far far away of disappearing, and it won´t be because of JSF...

    What substantiates that claim? Based on the amount of users that have adopted JSF, especially within larger companies, it seems to be accepting pretty well :-)

    It helps that there are JSF tools out there that can help maintain long term internal applications, even by lower caliber developers.
  13. one company?[ Go to top ]

    What substantiates that claim?

    Based on the amount of users that have adopted JSF, especially within larger companies, it seems to be accepting pretty well

    So did these guys switch to Magnolia at the end for majority or...?

    .V
  14. one company?[ Go to top ]

    If this is news, I think that it´s that JSF doesn´t go well in the market.I think Struts is far far away of disappearing, and it won´t be because of JSF...

    6 months ago I was looking for any GUI drag and drop Struts tool and I did not find anything

    With JSF I can go for SUN's Creator and Oracle JDeveloper.

    IMO there is no big difference between Struts and JSF, but JSF:
    - 4 implementations
    - at least 2 GUI drag and drop tools
    - component market

    Why should I go for Struts???
  15. one company?[ Go to top ]

    6 months ago I was looking for any GUI drag and drop Struts tool

    Like this?
    http://www.scioworks.com/scioworks_camino.html

    .V
  16. one company?[ Go to top ]

    6 months ago I was looking for any GUI drag and drop Struts tool
    Like this?http://www.scioworks.com/scioworks_camino.html.V

    I do not see it has an DRAG and DROP GUI for HTML components (e.g. buttons, tables, ...)
  17. They have since standardized on JSF as the corner stone of their new web development projects.

    My heartfelt condolences to them.
  18. Go JDO![ Go to top ]

    I know that this thread is more about the virtues of JSF than anything else......but I just have to say it:

    "Go JDO!"

    Nice to see another satisfied consumer of a fantastic persistence API. :-)

    Can't wait until the TCK tested versions of JDO 2 implementations start to arrive!
  19. Did they use a WYSIWYG IDE or did they hand code the JSF?
  20. This article misled me :([ Go to top ]

    I intended to study Struts first, then JSF later because as far as I know (after reading some articles about Struts and JSF, one of which is from someone from Sun), we should use Struts for the Front Controller and JSF for the View. Am I right? If you, Struts and JSF gurus, say that I am correct then I will go that way, ignore this article temporarily and read it back when I understand Struts and JSF to get their point of migrating from Struts to JSF.
  21. Struts-JSF, Hibernate - JDO?[ Go to top ]

    I can well understand why somebody would get dissapointed with Struts, but to switch to even worse - JSF?

    Now, why "worse"?

    The thing is, IMHO, main thing about MVC is the _separation_ of UI layer from the model layer. But what does "separation" mean? Does it just mean - UI code is separate from the Model code? I strongly doubt it. What it should mean - people who are supposed to do UI - designers, can do it their own way, without worrying about developers, and developers do not need to touch the UI templates. That's when the productivity boosts - everybody is doing what s/he is best at and does not step on each-other's foot.

    Problem with Struts is - the UI layer is JSP. Custom tags are not HTML-editor friendly, hence designers are not fond of them. Try have designer edit Struts+Tiles pages in Dreamweaver. No fun.

    JSF is even worse, as it takes the Desktop application development approach - widgets. But widgets, inherently, have standard look-and-feel. Widgets approach is not well-suited with custom design. That is more than fine in desktop applications. Actually, the whole culture of the Desktop applications is that they better have standard L'n'F. Web is a totally different story - nobody wants to look like the other site. Neither are web-designers used to writing, what in desktop applications is called, skins (neither are there any decent web-skinning frameworks, even less - standard ones). So, if you want to have your designers happy - you need to allow them to edit L'n'F just like a standard HTML, in a Dreamweaver or whatever.

    The only place I can imagine JSF being OK, is corporate intranet sites, where functionality matters way more than the design. That is so not applicable to Internet sites, though.

    It may just be my distorted mind, but somehow I think the bright future of vendor-provided JSF components (or even Portlets, for that matter) that you just plug-in into your custom application is as much an utopia as the previous attempt to create reusable, vendor-provided Domain components. Was not that what the initial idea of EJB was all about? Did it ever happen? Seems like the great example of Visual Basic components was only true to VB and the attempt to recreate its success in non-applicable areas may be just a waste of time.

    And I really can not imagine why would anybody switch to JDO from Hibernate. That just does not make _any_ sense to my limited mind. It would be appreciated if, instead of the eye-catching title, we would get some more justification for the decision.

     So far, it looks like somebody just made a wrong decision in the pursuit of what looked, to a particular group of developers, "the future of the web development".
  22. The only place I can imagine JSF being OK, is corporate intranet sites, where functionality matters way more than the design. That is so not applicable to Internet sites, though.

    You should check out my blog entry on component development and web standards-- how both designers and programmers can each be as expressive as they need. You'll find out that UI component development is the most optimal way of providing a consistent/flexible design.
  23. [...]
    The thing is, IMHO, main thing about MVC is the _separation_ of UI layer from the model layer. But what does "separation" mean? Does it just mean - UI code is separate from the Model code? I strongly doubt it. What it should mean - people who are supposed to do UI - designers, can do it their own way, without worrying about developers, and developers do not need to touch the UI templates. That's when the productivity boosts - everybody is doing what s/he is best at and does not step on each-other's foot.
    [...]

    Sounds like you want to create a presentation that has no knowledge about the data being presented. I'm just wondering how that is supposed to be accomplished. IMHO, the scenario you describe is a problem of the SW development process, rather than a problem of application design (or framework usage).

    Regards,
        Dirk
  24. Struts-JSF, Hibernate - JDO?[ Go to top ]

    Sounds like you want to create a presentation that has no knowledge about the data being presented. I'm just wondering how that is supposed to be accomplished. IMHO, the scenario you describe is a problem of the SW development process, rather than a problem of application design (or framework usage).

    Regards,    Dirk

    I agree that mixing designers and programmers within the same document is the wrong approach, my blog entry discusses this point and how each can cooperate. If it's the programmers' intentions to put together the UI in the most optimal way using the DRY principle, then a framework like JSF wins hands down.
  25. I agree that mixing designers and programmers within the same document is the wrong approach, my blog entry discusses this point and how each can cooperate. If it's the programmers' intentions to put together the UI in the most optimal way using the DRY principle, then a framework like JSF wins hands down.
    Jacob, thank you for the blog post URL. I liked it a lot - very thoughtful and clear. I absolutely agree that CSS and <div> approach is much better than the old-fashioned table layouting. But, forgive me, I have a problem seeing why this approach has to do anything with the JSF.

    JSF, "enforces" the use of CSS because of its problems (tight coupling of HTML and Java code), not its glory, - CSS is, pretty much, the only way to modify the design, in JSF, without modifying Java code, which, clearly, is unthinkable for a designer.

    It is, probabely, my fault that I was not clear-enough about this: I am not against component-based UI assembly, in general. What I criticize is the widgets-approach when the UI is _rendered_ by Java code, instead of Java code just dynamically inserting data in the UI renderred by the traditional Web means: HTML, CSS, Javascript.

    On the other end of criticism, I think that using custom-tags (the main idea behind the JSP) is very inneficient from the viewpoint of a WYSIWYG editor, that a lot of designers use. Embedding dynamic information through attributes (which WYSIWYG editors ignore) rather than custom tags in (X)HTML (which WYSIWYG editors show as rubbish) seems much better. So, I am generally pessimistic about JSP, neverthless if it is used by JSF, Struts or whatever other framework. JSP is programmer-friendly, not designer-friendly, but it is used in the area where designers should work, so - does it make any sense?

    Custom-tags, have another problem, too: by the rules of XML, a tag can not be an attribute of another tag. That limits the way you can combine JSP tags, a lot. For example, you can not write:
    <my:link href="<bean:write ...>" />

    It is a non-well-formed XML and illegal.

    I do understand that many web-designers are hand-coding HTML, but many of them - do not, or - not all the time. Besides, we may want to allow, end-users to change template. End-users can not hand-code HTML. They need a WYSIWYG tool. Custom tags are hated by WYSIWYG XHTML editors - problem, problem!

    Try posting the three examples (Tapestry, Struts+XSLT, Pure Struts), I posted above, in a WYSIWYG HTML editor and see how each of them renders. All of them will render the same under the container, but do you expect a web-designer to install a J2EE server and run her pages under it?

    In another life, I do some PHP development, too. The major UI Templating engine in PHP is Smarty. Interestingly enough, it is not cutom-tags based. When I was younger and stuppider, I wrote PSP - JSP-like custom-tag templating engine for PHP. It was quite a full replica of JSP and it was very fast because XML parsers are well-written and perform way better than plain text parsing. But, compared to Smarty, it was much harder to use and non-attractive. That was a good lesson to me.

    But it's not about just personal lessons in life. I have never ever, in my life, seen a web-designer that would admire JSP. Have you?
  26. I agree that mixing designers and programmers within the same document is the wrong approach, my blog entry discusses this point and how each can cooperate. If it's the programmers' intentions to put together the UI in the most optimal way using the DRY principle, then a framework like JSF wins hands down.
    Jacob, thank you for the blog post URL.... But, forgive me, I have a problem seeing why this approach has to do anything with the JSF.

    End-users can not hand-code HTML. They need a WYSIWYG tool. Custom tags are hated by WYSIWYG XHTML editors - problem, problem! ..., but do you expect a web-designer to install a J2EE server and run her pages under it?

    I think you missed the point of my blog. The beginning stated that the designer just does HTML and the programmer uses JSP/JSF/Whatever to their full advantage. The designer designs in CSS using web standards and just uses HTML mock-ups to provide a skeleton for a programmer to replicate efficiently using component methodologies. The merge point is the CSS document that the designer produces. The programmer includes the CSS in order to decorate the rendered output from JSF. The designer really shouldn't give a lick what server side technologies are being used. If you read some of the web standards sites such as A List Apart, designers are realizing that CMS/server technologies are pushing to a point where the designer no longer really 'makes' pages, only designs them. The programmer now 'makes' the page.
  27. Jacob,

    hm, with all due respect, don't you think, leaving only CSS and initia HTML to a programmer, may be kind of too extreme? Not that I am insisting it is, but just wondering.

    You see, I totally share the respect to CSS and that it has come a long way, but still think there is only so much that you can do with CSS. You can not change a list of radio buttons or checkboxes with a dropdown and vice versa, can you? Also, when you go with the components model, you will really want to create new components, based on simpler components. That will make things even harder, no?

    I may be speculating and exaggarating here, a little bit, but I think it still demonstrates, though in an oversimplified form, that - it strongly smells like programmers blantly introding into the UI layer and then coming up with all kinds of "excuses" that a designer is still "free" :)

    When a good deal of HTML (component's rendering skeleton before the customization) comes from the Java code:
    1) Do not you think it is Model sneaking into the View?
    2) How do you expect a designer tu costimize a component, represented as <my:spreadsheet/> custom tag in a DreamWeaver, even using CSS? The HTML that the CSS operates on will, only, be rendered after the system is run under an Application Server. So, you are asking a designer to use an application server and do not allow an "offline" work?
    3) Whose life does it make easier, really? Ours, developers, or designers? Have you ever seen a graphic/web designer that would love that idea? Or should we forcefully impose it on them?
    4) How easy/possible does it make creating a WYSIWYG skin-editors for End-users, who you can not expect to be CSS experts?
  28. Sounds like you want to create a presentation that has no knowledge about the data being presented. I'm just wondering how that is supposed to be accomplished. IMHO, the scenario you describe is a problem of the SW development process, rather than a problem of application design (or framework usage).Regards,&nbsp;&nbsp;&nbsp;&nbsp;Dirk

    Dirk,

    I agree that it is not an easy problem, but I think Tapestry approach is a big step forward in that direction. Their documentation gives a very clear overview of how they are different from Struts, JSF et al.:
    http://jakarta.apache.org/tapestry/doc/TapestryUsersGuide/template.html

    I find it much more designer-friendly to have the following code in a template:
    <a jwcid="@DirectLink" listener=". . ." href="#"> Lorem Ipsum </a> (Tapestry)
    than:
    <a href="${foo.link}"><c:out value="${foo.bar}"/></a> (JSTL + Struts)
    or even worse
    <a href="<bean:write name="foo" property="url" />"><bean:write name="foo" property="bar" /></a> ("Pure" Struts)

    Only the Tapestry example will render nicely in HTML editors and browsers. That's what matters.

    Interestingly enough, Struts+JSTL can be easier on the developer (that's why I guess programmers favor it) but what good is it for a programmer if his designers are suffering and complaining?