J2EE Web Frameworks

by david on October 18, 2004

We are preparing to move away from Fusebox and Coldfusion. We are moving to Tomcat and have been looking for a new web application framework. Matt Raible compares web frameworks including:

  • Struts: Pros and Cons. Pretty much a standard, lots of examples, HTML tag library kicks ass. ActionForms kinda suck, can’t unit test (only StrutsTestCase integration tests), Mailing list is swamped.

  • Spring MVC: Nice lifecyle (for overriding binding, validation, etc.) integrates with many view options seamlessly, IoC for easy testability. Not widely used, requires lots of code in JSPs, almost too flexible (no parent controller for SimpleFormController and Controller).

  • WebWork: Simple architecture, tag library easy to customize, interceptors are pretty slick. Documentation only recently written, few examples, client-side validation needs work.

  • Tapestry: Very productive once you learn it, templates are HTML (great for designers), healthy project. Documentation very conceptual, rather than pragmatic (lots of “read the book”). Steep learning curve, few examples. Impossible to test – page classes are abstract.

  • JSF: J2EE standard (lots of demand and jobs), fast and easy to develop with, rich navigation framework. Tag soup for JSPs, a bit immature (doesn’t come with everything), no single source for implementation.

We’ve been playing with SiteMesh, which Matt speaks very highly for it’s flexibility and integration to all of the frameworks. This is a great review and it looks like we still have some work to do, but I think we will try out each and see what works best for us. (We also looked at Ruby on Rails by David Heinemeier Hansson but it has been much harder to get the IT group to support Ruby on Solaris, basically they don’t understand it but they understand Java so we can always try JRuby if we feel so inclined. We are also looking at Groovy to many of our projects.)

Popularity: 1% [?]

  • David Crow

    One option that we've been looking at is J2EE unlying engine (Tomcat) and then ColdFusionMX (preferably Blackstone version 7.0), JRuby and Jython. But you're right, the complexity (development environment, tools, configuration) and development cycles (time = money) is what we are experiencing. It feels like 4 times the code, 6 times the configuration.



    Coldfusion is great, we just need something a little more elegant for our non-user driven events and data manipulations. The combination of Fusebox and CFCs has worked really well for most projects, but we need a more robust abstraction and persistance layer. We have been looking at moving a lot of our data access objects into Hibernate objects and continuing to use CFMX as the presentation layer and the controller. But when we start to look at the nice-to-have features (incepetors, validators, workflow, etc.) we have found that other solutions offer more.



    Part of our difficulty is addressed in Fusebox 4.x. We need to begin moving away from Fusebox 3.0, but since our latest application has only been live since July a major rewrite is not happening.



    We probably need to move from CFMX for Windows to CFMX for J2EE. Currently, the systems administrator does not (and will not allow) any additions to the CLASSPATH on our production Windows 2K3 machine running IIS and CFMX6.1. This has hampered any extensions or augmentation to the existing Coldfusion apps using other technologies.



    We've tried using a skunkworks approach to add rogue servers and functionality, but since there is no support at the very top for anything that would rock the status quo, it becomes very hard to implement. All of our machines are behind atleast 2 layers of firewalls and are not accessible to the outside world. For the inside world our boxes are only accessible on the same subnet. The servers are controlled by a separate department with separate reporting structures. There are obvious team and organizational issues that dampen our spirits.



    However, we seem to have support to move to J2EE and Oracle (9.2), but still in a very locked down, controlled fashion. But we have some support. Moving to J2EE appears to give us the flexibility to do things like Ruby on Rails using JRuby if we choose.





  • Solomon

    Wow. It's really too bad that you guys are moving to J2EE from ColdFusion. 4 times the code, 6 times the configuration, and unlimited headaches to boot. I would be really interested in hearing what the business/technical justification is for the move. My team is experimenting with Ruby on Rails, although there is not much in the way of documentation for using it on Windows. From a J2EE prospective, our clients are growing tired of the development cycles, maintenance and resource costs, as thee growing complexity of J2EE. They are looking for robust alternatives to cut cost, PHP, Ruby, Python, we will see.

  • David Crow

    My IT group has a hard time understanding n-tier development, never mind a scripting language like Ruby for enterprise development. We've fought long an hard to move them to J2EE (we were using COBOL, PL/SQL and a little bit of Perl for most projects, not just legacy systems). Their not (enterprise systems) group has gone with the Macromedia product suite, lots of ColdFusionMX, Breeze, Flash Communication Server, etc. This works just fine, but it ties me to a single vendor, and excludes a lot of other (easier, better, faster) solutions to many of the problems.



    We've had 2-3 major projects that has forced the rest of the IT to understand newer platforms. But for the most part they don't actually understand, they just follow route directions. So there is no support and no reward for learning new technology.



    With JRuby, Ruby on Rails might be back on the list of tools. My staff and I have zero experience with Ruby or Python and a fair bit of experience with J2EE. The Instiki and Basecamp projects are fabulous and we should probably have another look at Ruby.



    Any insight into J2EE versus Ruby would be great?







  • David Heinemeier Han

    I'm sad to hear that Ruby on Rails is out of the race merely because the IT gatekeepers haven't heard of it. What exactly were their reasoning for shuning Ruby? Couldn't they get it to compile? Didn't they even want to try?



    Hopefully, you'll dig deeper for an answer. Maintaining the status que due to ignorance is a terrible way work.

blog comments powered by Disqus

Previous post:

Next post:

Get Adobe Flash playerPlugin by wpburn.com wordpress themes