Does Struts 2 suck?
As far as I can tell, Struts 2 sucks. To be fair, so does Stripes. Why? Because there's no developer feedback for invalid properties or OGNL Expressions. What does this mean? It means if you fat-finger a property name, nothing happens. The OGNL exception is swallowed and you never know you did anything wrong. Furthermore, no one seems to care. The XWork folks will help you build, but not solve the problem. This seems like a major deal-breaker to me, However, I also believe it can be fixed - so maybe there's hope.
To demonstrate the problem, I did an experiment. I used the "user details" page in AppFuse Light to fat-finger a property name for the following frameworks: Struts 1, WebWork, Struts 2, JSF, Spring MVC, Stripes, Tapestry and Wicket. First, I tried changing the "lastName" property to "LastName" to see if the framework's property evaluation was case-sensitive. I found that with WebWork/Struts 2, Stripes and Tapestry, the property is not case-sensitive. I prefer case-sensitivity, but maybe that's because I prefer Unix over Windows.
The 2nd thing I tried was changing "lastName" to "pastName" to see if I'd get an error. An error occurred for all the frameworks mentioned, except for WebWork/Struts 2 and Stripes. This makes me believe these frameworks suck. The both use OGNL, so they could blame it on that, but Tapestry uses OGNL and it presents an error message. After this small experiment, my conclusion is the following frameworks have the best developer feedback:
- Struts 1
- JSF
- Spring MVC
- Tapestry
- Wicket*
* Wicket seems like it needs some work as all it presents is "Internal Error" and makes you dig through your log files to find the problem.
Without good developer feedback, how can you have good productivity?
Dear Struts 2 and Stripes Developers,
What do you think about improving your error messages for invalid properties and expressions? Is this a feature you think you could add? We'd love it if you did.
Sincerely,
Your Users
Click here for some screenshots of how a fat-fingered property looks in various frameworks:
Update: Stripes doesn't suck and Wicket has excellent error reporting. See my comment below for more details.
Update 2: I've created a patch to (hopefully) solve this issue in XWork. If you have any feedback on ways to improve this patch, I'd love to hear about it.
Peace
Gregg
Posted by Gregg Bolinger on September 05, 2007 at 11:35 AM MDT #
Posted by GB on September 05, 2007 at 11:41 AM MDT #
Posted by Demian Neidetcher on September 05, 2007 at 11:48 AM MDT #
Here's the debug for Stripes:
It's not an immediate result when the page is displayed but it does inform you to exactly what the problem is.
Posted by Gregg Bolinger on September 05, 2007 at 11:57 AM MDT #
IMO it's a very nice way to deal with errors, end users should not have to see stack traces or detailed error messages.
Posted by Xavier Hanin on September 05, 2007 at 12:07 PM MDT #
Thanks for the tip Greg - I didn't realize I needed to turn logging on in Stripes to see this. It looks like all you need is the following in your log4j.xml:
<logger name="net.sourceforge.stripes"> <level value="DEBUG"/> </logger>Then you get:
Of course, you could use INFO and get the same error. I'd expect this to be WARN though since it seems like a pretty big issue to me. With my level set to DEBUG for Stripes - I am impressed with the nice and readable logging:
GB - I filed XW-557 last week.
Xavier - good point, I forgot I was using Application.DEPLOYMENT. Changing it to Application.DEVELOPMENT results in an excellent error message. I agree that having different error messages for different deployments is a great feature. Here's a screenshot in development mode.
Posted by Matt Raible on September 05, 2007 at 12:44 PM MDT #
I can't remember if I've implemented this yet, but I believe that when you "fat finger" a property name, Tapestry will now (in the exception report) list the known properties. I know we have all the right information to accomplish this, but I need to double check if it exists yet. That's a common feature in T5: if you are selecting a name from some preset list, is case insensitive, and on a no-match failure, lists the possible matches.
Posted by Howard Lewis Ship on September 05, 2007 at 01:18 PM MDT #
Posted by musachy on September 05, 2007 at 02:44 PM MDT #
Posted by JIRA: XWork on September 05, 2007 at 03:18 PM MDT #
Posted by James McIntosh on September 06, 2007 at 04:56 AM MDT #
Posted by Keith Weinberg on September 06, 2007 at 07:12 AM MDT #
Posted by Jay on September 06, 2007 at 07:57 AM MDT #
Posted by Jay on September 06, 2007 at 08:00 AM MDT #
Posted by dave on September 06, 2007 at 09:02 AM MDT #
Have you tried working with devMode turned on? * http://struts.apache.org/2.x/docs/devmode.html For example, if I add to the form on MailReader Login.jsp <s:textfield name="doesntexist" /> and submit the form with devmode=true, the following is logged Sep 6, 2007 11:14:52 AM com.opensymphony.xwork2.validator.ActionValidatorManagerFactory <clinit> INFO: Detected AnnotationActionValidatorManager, initializing it... Sep 6, 2007 11:15:01 AM com.opensymphony.xwork2.interceptor.ParametersInterceptor setParameters SEVERE: ParametersInterceptor - [setParameters]: Unexpected Exception caught setting 'button.save' on 'class mailreader2.Login: Error setting expression 'button.save' with value '[Ljava.lang.String;@e33e18' Sep 6, 2007 11:15:01 AM com.opensymphony.xwork2.interceptor.ParametersInterceptor setParameters SEVERE: ParametersInterceptor - [setParameters]: Unexpected Exception caught setting 'doesntexist' on 'class mailreader2.Login: Error setting expression 'doesntexist' with value '[Ljava.lang.String;@15f1f9c' Note that devmode also reports things like there not being a property to catch the values submitted by the buttons. At one time, our examples had it turned on by default, but people were neglecting to disable devmode in production, which was leading to performance issues. In some cases, the debugging interceptor might also be of use: * http://struts.apache.org/2.x/docs/debugging.html If a post like this is not answered on user@, please feel free to repost to dev@, in case there is a need for new functionality. After that, also feel free to open a JIRA ticket to track any work on the issue, including any patches of your own that might address the problem. HTH, Ted. http://husted.com/ted/blog/Posted by Ted Husted on September 06, 2007 at 09:34 AM MDT #
Posted by giesen on September 06, 2007 at 10:56 AM MDT #
Posted by Jonathan Locke on September 06, 2007 at 11:22 AM MDT #
Giesen: FreeMarker is an easy sell to me, but often not to my clients. While it may be easy enough to use and learn, it's difficult to hire for. JSP is easy. You and I realize a good developer can learn any templating language, but companies often like the buzzword-compliant technologies they think they can hire for. Another problem with FreeMarker is I haven't used it enough to get be productive, so I still tend to do a lot of searching through documentation and macro libraries.
Has anyone used the FreeMarker Eclipse Plugin? It's nice having code-completion with JSPs. Unfortunately, it looks like IntelliJ users are SOL when it comes to FreeMarker.
I've done a lot of work with JSP Tag Files recently and I think I prefer Ctrl+Shift+R -> search for tag filename over opening a macro file and searching for the macro you're trying to use.
Posted by Matt Raible on September 06, 2007 at 11:23 AM MDT #
Matt: If that's your itch, then please scratch it. (IOW: Thanks for volunteering!)
Both the Struts and the XWork teams are always on the lookout for good patches from great developers, like you! Products like Struts aren't created behind closed doors. Struts is now (and always has been!) created by volunteer developers, who work another job all day and then tinker at night. If Struts doesn't work the way you think it should, then, please, show us the patch.
Though, be careful, we have a bad habit of offering karma to people who submit patches! :)
-Ted.
Posted by Ted Husted on September 06, 2007 at 07:03 PM MDT #
Posted by Derik on September 07, 2007 at 01:55 AM MDT #
Posted by Jesse Kuhnert on September 07, 2007 at 05:51 AM MDT #
Posted by JIRA: XWork on September 07, 2007 at 12:24 PM MDT #
Posted by anand raman on September 07, 2007 at 09:01 PM MDT #
I was inspired, so I added the "show me the possible properties" feature to Tapestry 5:
[Link to Screenshot]
Posted by Howard Lewis Ship on September 08, 2007 at 09:45 AM MDT #
Posted by Chris on September 10, 2007 at 12:54 AM MDT #
Posted by Eelco Hillenius on September 10, 2007 at 08:03 PM MDT #
Posted by Johan Compagner on September 11, 2007 at 01:51 PM MDT #
> Matt, What is your favorite Java Web framework these days? Also, if you were to develop a Digg-like Web application what framework would have you chosen?
I think it all depends on the application you're writing, as well as a number of other factors, including: application type, ease of development, project community, prooject future and roadmap, maintenance and technical features. I'll be talking about this a lot at this year's Colorado Software Summit. I've changed the title of my talk from Choosing a Web Framework to Choosing a JVM Web Framework.
I hope to make the talk an interactive discussion that leads to some conclusions I can use to write some sort of article or whitepaper on.
Posted by Matt Raible on September 20, 2007 at 06:53 AM MDT #
Here's a FAQ entry describing various ways to change the configuration mode.
Posted by Ryan Holmes on September 24, 2007 at 01:52 PM MDT #
Posted by Ryan Holmes on September 24, 2007 at 02:10 PM MDT #
Posted by Matt Raible on September 24, 2007 at 02:12 PM MDT #
Posted by JIRA: XWork on November 02, 2007 at 10:14 PM MDT #
Just did a cursory evaluation of struts2 and stripes in WebSphere. The overhead of both of these (especially stripes) was not worth the benifits and I stayed with struts. RAD/WebSphere is a heavy development environment as it is and either of these put it over the edge as unusable. Stripes especially, inventoring every jar in the project on load was completely unacceptable.
I guess having worked with struts from the beginning and finding solutions to all the perceived problems with struts also makes these shortcomings seem larger than they might be otherwise.
Edgar
Posted by Edgar Dollin on January 25, 2008 at 11:00 AM MST #
Rather than solve hard problems, the framework guys keep solving easy ones. E.g. why not have support for 200 common business data types and an integrated way to validate these. Now that would save everyone some time. Yet another way to handle web requests is just plain redundant. Worst of all, the Struts 1 framework binds the display to the backend. Struts architects will tell you it doesn't but every implementation which uses it does. Perhaps Struts 2 with REST approach will be better.
I'm just starting to look at Struts 2. Incredibly poorly documented on even the helloworld example. For instance, it cannot just be dropped into IBM's RAD7 and run. It doesn't work. Perhaps some special mappings need to be added to support the "action" extension; but the point is these special steps to make their framework work should be clearly documented.
Not being backward compatible is a trademark of Apache projects. It is against the software industry standard of being compatible with the last two releases. It is not professional.
Posted by MadHacker on October 17, 2008 at 04:21 AM MDT #
the best think on wich struts2 sucks is that there is no servlet as there was with Webworks. Instead, there is a filter.
the problem is that you *can't* use request dispatcher to forward to another action. You can't because the lack of a servlet make the application server answer with a "404 not found".
I know you can use "action chaining" but it breaks servlet apis and it's not always possible.
For example, I recently had the problem because I had to use a client api that make use of request dispatcher ...
Also, request dispatcher allow to make dispatch to someting like "/other.do?var=value". Actually, it's impossible. For action chaining, I have to had parameters names that matchs. I can't give an arbitrary action.
Also, with action chaining, insterceptors stack is not called again.
And last, wth action chaining, you can't call code that use "request.getParameter()". You could with a standard request forward.
well there is hundreds of reason to use request dispatcher but struts2 broke it. I asked why, but I never had an explanation. If anybody had an Idea, I would love to read it ...
Posted by Mike on December 21, 2008 at 05:23 AM MST #
Well I won't say it "sucks", but I will say I don't see the point of having created a new framework. It would have been a whole lot better for everyone if they just appended to Struts1. After all there's a zillion lines of code for Struts1 and we wouldn't have to re-learn everything all over again. Sure Struts2 purports to "fix" all of Struts1's problems but again, what's the point when all those "problems" were already handled.
So now we've got Struts2 and are at square 1. Samething happened when we coded against the straight servlet model, everything worked! Then all these damn frameworks, more and more code, more and more development time, more and more bugs.
You tell me, so far I would say on the whole frameworks suck. Next will be Struts3, etc, ad naseum.
With everyone coding AJAX, the "view" of MVC is out the window, so now we've got Struts with no real need for all the view portion which then begs the question, well if no view then why have all the code which handles the UI side of things in the framework.
Again more and more code, more and more bugs, more and more development time.
So no Struts2 doesn't "suck" but the paradigm of never ending frameworks just might.
Posted by raka on October 01, 2009 at 12:07 PM MDT #
Posted by levan on February 03, 2010 at 09:50 AM MST #
I agree : it's the biggest problem. I asked for this to Patrick Lightbody 3 years ago.
http://www.opensubscriber.com/message/[email protected]/6107198.html
and his reply :
http://www.opensubscriber.com/message/[email protected]/6107712.html
There are some args here :
http://www.coderanch.com/t/363824/Servlets/java/Filter-vs-Servlet
But I'm not convinced.
At webwork's time, we were able to choose between servlet and filter. When it become strut2, the servlet part has been removed.
Posted by mike on February 26, 2010 at 09:21 AM MST #
Posted by Igor on February 26, 2010 at 09:21 AM MST #