Any disadvantages of the struts framework.

[Gayatri Ganesh]

I have been hearing all nice things about the struts framework.
Does it have any disadvantages ?
Thanks,
Gayatri

[Rick Hightower]

yes.

[David Yutzy]

I've encountered these:
* It can become difficult to debug with the various .xml files that Struts relies on. If you have a setting out of wack, it's not very descriptive on how to fix it or what the issue is.
* Figuring out what all the .xml attributes and tags is another issue. Get a GUI plug-in for Eclipse or whatever IDE you use. They are very useful when learning the Struts ropes or setting up something such as Validator.
* Using the custom JSP tags, especially iterate, can be slightly confusing. Same thing with the link tag. There are scenarios that often come up where you say "I know if I just used a scriptlet, I could get this to work in seconds!" So the difficultly comes when you ask "how do I do this using Struts tags?"

[Ken Robinson]

David brings up a few good points, but I believe those are not very STRUTS specific as web.xml can also get out of hand and the JSTL tags could also get a bit 'wordy' instead of a scriplet.

Things I can think of are:
1- You take a small performance hit, but hardly noticable. Depends on how much you want to harp on this, but the web server is going to do it's thing regardless (map the URL to the ActionServlet), then STRUTS is going to map the same URL to it's Action class. Then the mapping to an ActionForm, reflective population of beans, lookup of ActionMappings and so on. Little things, but they may add up on very high traffic servers.
2- STURTS is very popular, today. What about tomorrow? Java Server Faces is on the horizon and has the potential to become the buzzword of choice. Who knows if the level of support for STRUTS today will be there tomorrow.
3- Action class parameters. I do not recall (correct me if I'm wrong) if an Action class can have parameters defined in struts-config.xml. In web.xml, a Servlet can have parameters which make it easy to modify settings.
4- Not THE standard. Currently, I do not believe there is a 'standard'. If in the future you have to hire a new developer, are they more likely to know STRUTS, the J2EE standard or some other framework that they where exposed to at their last job.

My biggest issue with these web 'frameworks' that float around is that they bring this very question up. Sometimes the amount of time used to determine which one is 'better' offsets the actual amount of time saved.

[Rick Hightower]

* It can become difficult to debug with the various .xml files that Struts relies on. If you have a setting out of wack, it's not very descriptive on how to fix it or what the issue is.

I agree with this. There are several ways to get around this.
The first and proably most important is use commons logging. Turn on the long level to debug (in you development envrionment). Get log4j. Put the jar file in your WEB-INF/lib directory and configure log4j.properties (put it in WEB-INF/classes). commons logging uses log4j.
Second, and very important, use Struts Console (an eclipse, jbuilder, et al plugin) to help you debug bad struts-config.xml files. It takes you to the line that is having the problem.
Third, addopt TDD, use Struts Test case. Write tests for your actions, and tile controllers. Create a model tier that works independent from your actions and is testable. (look into mock object testing) Also, start using JUnitWeb to test your JSPs. Tesing makes debugging sessions small exercises instead of all nighters.

* Figuring out what all the .xml attributes and tags is another issue. Get a GUI plug-in for Eclipse or whatever IDE you use. They are very useful when learning the Struts ropes or setting up something such as Validator.

YES! I agree. There are some good plugins and WSAD 5.1 has great support as well.

[Rick Hightower]

1- You take a small performance hit, but hardly noticable. Depends on how much you want to harp on this, but the web server is going to do it's thing regardless (map the URL to the ActionServlet), then STRUTS is going to map the same URL to it's Action class. Then the mapping to an ActionForm, reflective population of beans, lookup of ActionMappings and so on. Little things, but they may add up on very high traffic servers.

Early optimization is the root of all Evil (Donald Knuth--paraphrased). I've developed an ASP (application services provider) that used Struts. We used caching and other techniques to optimize the pages that got hit the most. Struts encourages MVC. My advice to the original poster, read the blueprint before you start using Struts or any framework. The key is understanding the J2EE blueprint and model 2.

2- STURTS is very popular, today. What about tomorrow? Java Server Faces is on the horizon and has the potential to become the buzzword of choice. Who knows if the level of support for STRUTS today will be there tomorrow.

Struts is embracing JSTL and JSF. My advice to the original poster, follow the developer list. There is a good article on IBM developerWorks that covers using Struts, JSF and Tiles on a project. Struts and JSF compliment each other nicely. There is some overlap.

3- Action class parameters. I do not recall (correct me if I'm wrong) if an Action class can have parameters defined in struts-config.xml. In web.xml, a Servlet can have parameters which make it easy to modify settings.

You are wrong (you asked). You can pass a parameter to an Action. You can also create a custom config object that has any properties you like.

4- Not THE standard. Currently, I do not believe there is a 'standard'. If in the future you have to hire a new developer, are they more likely to know STRUTS, the J2EE standard or some other framework that they where exposed to at their last job.

It is the defacto standard. Example, Tomcat console is built with Struts so is the IBM WebSphere console and the WebLogic console. Struts is the framework that is closest to the J2EE blueprint suggestions.

[Ken Robinson]

Early optimization is the root of all Evil (Donald Knuth--paraphrased). I've developed an ASP (application services provider) that used Struts. We used caching and other techniques to optimize the pages that got hit the most. Struts encourages MVC. My advice to the original poster, read the blueprint before you start using Struts or any framework. The key is understanding the J2EE blueprint and model 2.

The caching and other techinques you used are not STRUTS related, they are just good design. Those optimizations could have been placed into any framework and are not provided by STRUTS. Each request that is actually fulfilled via STRUTS does have the small STRUTS overhead.
I always see people say the STRUTS encourages MVC. This has nothing to do with choosing STRUTS. Anything can encourage MVC. Unless it enforces it, it's not worth mention. It is just as easy to break the MVC model in STRUTS as it is in anything else.
You do bring up a very good point, learing the J2EE Blueprint and model 2 is key. I just don't think many people understand that the Servlet Spec provides a very rich model 2 framework as is. STRUTS actually follows the Front Controller pattern, but is usually used to fit the MVC pattern (which it does as well as the Servlet Spec in much the same way).

Struts is embracing JSTL and JSF. My advice to the original poster, follow the developer list. There is a good article on IBM developerWorks that covers using Struts, JSF and Tiles on a project. Struts and JSF compliment each other nicely. There is some overlap.

Exactly my point. JSTL and JSF are attempts at a standard, STRUTS was not (it helps that Sun put out JSTL and JSF, they dictate many standards - JSF is obviously very STRUTS like). STRUTS had many of the tags JSTL now has well before JSTL, and that was a great benifit. My point is that the JSTL tags, not STRUTS, became the standard. Changing from one STRUTS implementation to an other is still change. Again, the web framework is just an 'adapter' between the client (browser) and the actual app (EJBs, Business Objects, etc.). It's just a small tool in the big picture. I really think only one standard is needed.
Look at all the frameworks currently considered 'popular'. STRUTS, Spring, TEA, WebWork and Turbine are just five. How many do we need? Each of these list many of the same features. It's just overkill.

You are wrong (you asked). You can pass a parameter to an Action. You can also create a custom config object that has any properties you like.

With any class, not just STRUTS, I can pass a parameter in or open a config file. With a servlet, I only need to access the ServletConfig object passed in automatically by the container to the init(ServletConfig) method. All of the parsing of the parameters is taken care of.
This allows the coding of one Servlet that can be registered infinite times in web.xml with different <init-param> values to allow for different behavior with one source file. While this can be done in any class, the init(ServletConfig) method in a Servlet makes the overhead of finding the config information almost non-existent. It is also much nicer to see the init information along with the servlet information in the same config file, same location.

It is the defacto standard. Example, Tomcat console is built with Struts so is the IBM WebSphere console and the WebLogic console. Struts is the framework that is closest to the J2EE blueprint suggestions.

Before that many used a Servlet/JSP solution, and before that a straight Servlet solution. Some vendors have even used their own home grown solution. Who knows when they will switch to a JSF solution, but we have to assume that once JSF is the new buzz, that will be what is used. The vendors are smart, STRUTS has a large base. Either their developers preferred STRUTS or they want to appeal to the STURTS users out there. You won't see a server use an 'older' solution, even if it is still a valid one since they are always promoting their product as the latest and greatest.
When I see a web server console that allows me to examine struts-config.xml and present me with the information contained in that file, then that will be something to look at. Currently, they vast majority of web servers with decent consoles show each and every Servlet/Filter in a web app along with the config values and other information in the console. Since STRUTS only uses the ActionServlet, information on individual Action classes are available in the web console. While both web.xml and struts-config.xml have much of the same info, it's usually easier to find information on a specific Servlet by using the web container's GUI.
Basically, I'd suggest not spending much time on choosing one way or the other. No matter which 'framework' you choose, there are going to be issues, problems or just 'things' you have to account for at some point. Make sure that whatever 'framework' you choose, you know it inside and out. If you don't, you'll always spend time coding complex solutions to simple problems that already provide the solution for you.