Is Struts the most popular J2ee framework?
[68 byte] By [ Kizza] at [2007-9-26 17:29:44] 
Is there any other popular J2ee framework easy to use?
Do this mean that you know a popular j2ee frame? Please, tell me!
llturro at 2007-7-2 22:37:11 >
I think Struts is a really nice implementation of MVC. It's certainly a lot quicker and easier to use than writing one yourself - I know, I've done both!If you have a specific question relating to Struts, I'll try to answer it.
rgunder at 2007-7-2 22:37:11 >
I'd like to use struts instead of petstore for my future application. The only problem is the implementation of an EJB framework on struts. You have to do it by yourself, and perhaps it could be too slow to implement!Let me know your experience.thanx
ivanbatty at 2007-7-2 22:37:11 >
I work in an environment where we must use STRUTS. My personal opinion of it is that it is worthless.
Keep in mind, I prefer system performance over anything else, and STRUTS does add overhead.
In my opinion, STRUTS is smoke and mirrors. Instead of using the HttpRequest object to look for parameters, STRUTS requires that you build and object that extends the ActionForm (if I have the wrong name, please correct me). The set methods in this form must match the name of the parameter coming in (a TextBox with the name jimbo will only be set in a object with a setJimbo() method). Now, regardless of if you use the Request object or STRUTS form, you still need to know the names of the parameters you are looking for.
STRUTS then forwards the ActionForm to an Action. This is for the work you want to do. A Servlet calls the doPost/doGet to do this.
STRUTS allows for a Mapping type structure. Using a return value from the logic you've coded, it determines which JSP page to forward the request to. This can be done very easy without STRUTS.
In my opinion, it is MUCH better to learn the Java Servlet specs instead of STRUTS. The arguement for using STRUTS is that it gives you an MVC environment. If you think about this, the Servlet Container gives this to you already. The client (Brower) is the view. Only the HTML/WML you send is seen by the client. JSPs where created just for this purpose. The web container and servlets you develop are the controller. When you deploy a servlet, you can configure the URL or URL pattern that servlet will answer for. Servlets should only verify the incoming data and prepare the outgoing data. The JSP (view) will take that data and format it for the client. The Model is of course any data (usually a JDBC Database) that is used to perform the requested logic.
Why this needs to be changed is beyond me, especially considering the Servlet spec provides for everything you should need.
ken_robinson at 2007-7-2 22:37:11 >
I agree with you Ken, 100%
I am currently involved in building reusable frameworks for our web infrastructure. One of these frameworks is a template implemenetation of the Front Controller pattern. I thought about using Struts instead of writing the code myself, but since Struts is not a standard, and, not to mention, implementing Front Controller is not very difficult, I choose to write the framework instead.
I'm a firm believer in using frameworks, but there are some that are worthless, such as Struts. The overhead involved in learning Struts and customizing it for your environment can be spent writing the entire framework yourself. You will also learn much more about the Servlet API, as Ken mentioned, if you write the framework yourself.
Even though Struts is 100% Java, it's still a 3rd party proprietary API, which means that if you implement it, your are dependent on it. Always stick to standards.
SAF
SAFM at 2007-7-2 22:37:11 >
While struts is a 3rd party API, I would not be suprised if it became part of the J2EE servlet, JSP specification.
chiltown at 2007-7-2 22:37:11 >
Why would you be surprised if STRUTS became a standard?Everything STRUTS allows you to do can already be done. Why would SUN add the overhead of STRUTS while adding no new functionality?Learn the Servlet/JSP specification, you'll be MUCH better off.
ken_robinson at 2007-7-2 22:37:11 >
There are a couple alternatives. One is XMLC by Enhydra and an increasingly popular one is webwork which is Rickard Obergs project on SourceForge. http://sourceforge.net/projects/webwork
swatdba at 2007-7-2 22:37:11 >
Ken, i wouldn't call Struts worthless. It depends on what you're trying to do and what skills you're having in your company. While Struts is definitely useful for your web-centric applications, you'll need something else for your EJB-centric applications. While servlets are cool, i'm very happy with Struts' form handling. If you prefer system performance over anything else, you'll almost always end up writing something by yourself. But what about contributing your performance tipps to the Struts developers?
SAF, i have to disagree with your 'The overhead involved in learning Struts and customizing it for your environment can be spent writing the entire framework yourself.' For me this was simply not true. When i started with Struts, it was somewhat difficult to get recent documentation but this has changed. If you have a look at the Struts resources, you'll find a bunch of articles, papers and the like. For 3rd party proprietary APIs: the Apache Software Foundation develops Struts, not somebody as proprietary as for example Microsoft. Struts lead developer is a member of JSR052 and you get the full source code.
'Everything STRUTS allows you to do can already be done.' Well, everything Java allows you to do can already be done with C++. So why not stick with this ISO standard?
And finally: this is version 1.0! Not much other software is that useful in such an early release. I'm personally very happy with Struts and recommend it for web-centric applications.
Markus
Howlingmad at 2007-7-2 22:37:11 >
If it where my money I was spending to build an app, I would no doubt require that the J2EE servlet spec be used.
In my opinion, any java web developer worth their weight will know servlets. This gives me a larger pool of talent to select from and allows for zero time training on a internal/3rd party API.
I believe that there is ZERO reason to build a 'framework'. Again, I think the Servlet API is more than what is needed.
Sometimes I think people get sucked into the idea of following certain buzzwords like 'pattern' and 'framework'. EVERY application will have it's own requirments. I want to hire the person who can look at a set of requirements and build an app using industry standard tools.
Just because you CAN fit an app into a pattern does not say you SHOULD make it fit a pattern.
As for frameworks, the application itself should dictate how it is built. Too many times I have seen a simple problem solved in a way to requires too much overhead, just to conform to the current 'framework'. Frameworks should only be used when they lower development/training time, not just to have one.
ken_robinson at 2007-7-2 22:37:11 >
ken, i agree with you that frameworks, patterns and the like can be used and abused (which applies to every technology, of course). One should only use a framework if it helps to solve the task at hand. And yes, servlets are essential for web development. Anyway, i'll continue to have a look at frameworks and patterns and i encourage everybody to do the same. They give us something to think about, even if we don't use them.
Markus
Howlingmad at 2007-7-2 22:37:11 >
Struts resources:
http://jakarta.apache.org/struts/index.html
http://www-106.ibm.com/developerworks/ibm/library/j-struts/
Alternatives to Struts:
Tea
http://opensource.go.com/Tea/index.html
XMLC
http://xmlc.enhydra.org/
WebWork
http://sourceforge.net/projects/webwork/
Tapestry:
http://tapestry.sourceforge.net/
Maverick
http://mav.sourceforge.net/
Velocity:
http://jakarta.apache.org/velocity/
WebMacro:
http://www.webmacro.org/
Jetspeed:
http://jakarta.apache.org/jetspeed/site/index.html
Jakarta Taglibs:
http://jakarta.apache.org/taglibs/index.html
Barracuda:
http://barracuda.enhydra.org/index.html
Freemarker:
http://freemarker.sourceforge.net/
JSPTAGS:
http://sourceforge.net/projects/jsptags
Related information:
http://barracuda.enhydra.org/cvs_source/Barracuda/docs/landscape.html
http://java.sun.com/products/jsp/
http://java.sun.com/blueprints/patterns/j2ee_patterns/model_view_controller/
scsulliv at 2007-7-2 22:37:11 >
> Re: Is Struts the most popular J2ee framework?
> Is there any other popular J2ee framework easy to use?
I think most Enterprises currently working in J2EE, roll their own J2EE frameworks. (I'm on my second), this is mainly because Struts is only just becoming complete. I think that in the future this is likely to change with a lot of late adoptors of J2EE starting to use Struts.
MartinS. at 2007-7-2 22:37:11 >
> I think most Enterprises currently working in J2EE, roll their own J2EE frameworks.
Hrm, object-oriented programming has promised code-reuse for years now (or was that decades?), but still fails. When will this dream come true? Anyway, i'm having the impression that code-reuse works better for Java as for C++.
Thank god we're already in the 'post OOP era' and we're now entering the 'component-oriented programming era' which will do better, of course. :-)
Markus
Howlingmad at 2007-7-2 22:37:11 >
>I believe that there is ZERO reason to build
>a 'framework'. Again, I think the Servlet API is more
>than what is needed.
Wow!
I can't beleave some one is thinking like this.
Really strange for a Java guy. I would think like this only if I would have to build only one application during my whole carrier...
There are a lot of benefits in building your own framework or even using a 3rd party open source framework. One is that the anoying part of building the skeleton of the application is off and main concern is to develop the bussines logic and how to use your own components
Servlets only are fine for small, tiny apps. When you want a MVC or a template system you have to thing further.
This is my opinia and I think everybody is entitled to have one.
All the best.
M-
Mircea at 2007-7-2 22:37:13 >
Mircea73, while i disagree with ken's "there is ZERO reason to build a 'framework'", i somewhat see his point. One should take care that the development process benefits from using a framework. Unfortunately it's not that easy to achieve this goal. IMHO it's not a good idea to *force* people to use a framework.
Markus
Howlingmad at 2007-7-2 22:37:13 >
I think that, like any other project, it all depends on who you are and what you need to accomplish. If you're a rather large company with many small, related projects, it makes sense to adopt some sort of framework. In fact, it's necessary to do so despite the overhead incurred.
With a framework, you can adopt gating and promotion procedures against some sort of checklist, you can create training and orientation suites for your developers, etc. Even more importantly, you can pass the buck to other developers who may be support specialists, or people coming in to enchance a product or application.
Can you do these things with the standard API? Of course you can, but the API leaves it up to the developer as to how he or she is going to implement the solution. The framework, while adding overhead, restricts your implementation somewhat while not being prohibitive. Also, in very large companies the adroitness of your developers may be in question, and you may not be able to do much about it. Having a framework provide a lot of the core compontants makes this easier to deal with as well.
Just MHO. /jac
vextor at 2007-7-2 22:37:13 >
Micrea, you are right, Servlets are only good for small, tiny apps.
I like to use Servlets as part of the view and nothing else. Something else (RMI, EJB, DataBase) will contain all logic. The Servlet just calls this piece for the info it needs and is only responsible for 'drawing' the next screen.
My main problem with STRUTS (and things like it) are that is does the exact same thing as a web container, just at a different point in time. The web container has already taken the role of a 'delegator' since all request through the web go to it. It determines which Servlet to delegate the request to. STRUTS just utilizes a Servlet to again match the request to a Class (a handler in this case, not a servlet).
Like you said, everyone has an opinion. I just really see frameworks such as STRUTS as a way of saying you are doing things one way while really getting nothing more than you already had.
ken_robinson at 2007-7-2 22:37:13 >
Over the last year, there have been several commercially available frameworks for J2EE announced that while don't have the "popularity" of struts, they are definitely being adopted.
A previous comment in this thread mentioned that most companies "roll their own" framework - this is ceertainly what I have seen over the the last two years I have spent working with framework technology in J2EE. It is very similar to the early days of app servers when (believe it or not) many compnaies built their own app servers (or pieces of technology that resembled app servers). Over the next 2 years it will be less and less likely that companies continue to build their own frameworks - more than likely they will extend the commercial and open source options out there.
Wakesoft has a framework that spans all the logical layers of your application from presentation/interaction to business logic to integration/persistence. Struts overlaps without about 15% of Wakesoft's framework, all in the presentation layer; so with Wakesoft, you get Struts like benefits across your entire application. Wakesoft will be announcing some neat Struts integration stuff in the coming months. The Wakesoft framework also implements many design patterns including those from the BluePrints team.
hsitner at 2007-7-2 22:37:13 >
> > I think most Enterprises currently working in J2EE,
> roll their own J2EE frameworks.
>
> Hrm, object-oriented programming has promised
> code-reuse for years now (or was that decades?),
> but still fails.
That is an unjustified & orthogonal conclusion to draw from my comments.
1) Reuse is a consequence not the intention of OO, the aim is to make Software Engineering more effective, and productive, any specialisation of an existing code base is reuse. Using the JDK is reuse, using the VM is reuse.
2) Not experiencing some reuse with the vast majority of new code, means you are not doing OO; you are doing something wrong, very wrong.
3) The OO paradigm is not a panacea, it is not a guarantee, it makes reuse easier. Increasing reuse is a matter of knowledge and experience, these skill allow the ready identification of opportunities for reuse. If you fail to exploit those opportunities do not blame the tool/approach, your process or knowledge is flawed.
4) A Framework is a classic reuse, it is reuse incarnate; if not, it is not a Framework, it is an architecture.
Indeed your conclusion so far wrong I have to question if have even the slightest understanding of what is being discussed here.
> When will this dream come true?
> Anyway, i'm having the impression that code-reuse works better
> for Java as for C++.
Using an OO language does not make a programmer or project OO.
> Thank god we're already in the 'post OOP era' and
> we're now entering the 'component-oriented
> programming
> era' which will do better, of course. :-)
>
> Markus
Post-OOP ?
So in your own word how does and Object differ from a Component?
MartinS. at 2007-7-2 22:37:13 >
> That is an unjustified & orthogonal conclusion to draw from my
> comments.
It was not a conclusion. It was an attempt to provoke some more responses. Looks like you are the only one having a problem with my statements, which is a bad thing, of course. Many people should scream out loud, but they don't. Interesting, isn't it?
> 1) Reuse is a consequence not the intention of OO,
Disagree. 'Don't reinvent the wheel; use libraries' (Bjarne Stroustrup: The C++ Programming Language). Reuse is included in my personal definition of OOP.
> the aim is to make Software Engineering more effective, and
> productive, any specialisation of an existing code base is reuse.
Agree.
> Using the JDK is reuse, using the VM is reuse.
Disagree (somewhat). The JDK and the VM only provide the platform for reuse. Examples for reuse are: buy a component from ComponentSource and use it in your application, use a library another developer has written. I include 'binary' in my definition of reuse.
> 2) Not experiencing some reuse with the vast majority of new
> code, means you are not doing OO; you are doing something wrong,
> very wrong.
So why do most enterprises roll their own J2EE frameworks?
> 3) The OO paradigm is not a panacea, it is not a guarantee,
[...]
Fully agree.
> 4) A Framework is a classic reuse, it is reuse incarnate;
[...]
Agree. That's why i utilize the Struts framework and that's why i wonder about ken's 'I believe that there is ZERO reason to build a 'framework''.
> Post-OOP ?
Yes. After reading various magazines (SD Times, Computerworld, InfoWorld and the like) i'm getting the impression that there's a shift towards the term 'component-oriented' instead of 'object-oriented' (see http://java.sun.com/features/2002/03/compsource.html ). Please note the ':-)'.
> So in your own word how does and Object differ from a Component?
A component is made of objects. It provides binary reuse not source reuse. Examples are Component Object Model (COM) and EJB.
Martin, i apologize for utilizing your posting. It was not my intention to attack you. It would have been better to start a new thread. I will do better next time.
Markus
Howlingmad at 2007-7-2 22:37:13 >
> > Using the JDK is reuse, using the VM is reuse.
> Disagree (somewhat). The JDK and the VM only provide
> the platform for reuse. Examples for reuse are: buy a
> component from ComponentSource and use it in your
> application, use a library another developer has
> written. I include 'binary' in my definition of
> reuse.
I clipped most of this, as I don't want to get into the middle of this, heh. Anyway, Markus, I have to disagree a bit here... JDK is definately reuse as well as a platform. For instance, you could write your own Socket implementation, but most don't, must reuse the objects in the java.net package for that. You could write your own implementations of most of the junk in java.util, but again, most don't. You can take these examples on ad nausiem, but I won't.
Just my toughts.
vextor at 2007-7-2 22:37:13 >
> Looks like you are the only one
> having a problem with my statements, which is a bad
> thing, of course. Many people should scream out loud,
> but they don't. Interesting, isn't it?
Yes, revealing, and rather 'worrying' that it passed with so little response/comment. Especially in this forum, where it's reasonably to expect to find a fair amount of OO proficiency.
> > Using the JDK is reuse, using the VM is reuse.
> Disagree (somewhat). The JDK and the VM only provide
> the platform for reuse. Examples for reuse are: buy a
> component from ComponentSource and use it in your
> application, use a library another developer has
> written. I include 'binary' in my definition of
> reuse.
I'd advocate that using the JDK is pretty good example of reuse. If you examining the JDK source, you'll find a lot of reuse, for example consider the java.lang.Object class, this is reused extensively, the collection classes are reused a lot within the JDK alone, each time a class is extended or composite is reuse.
I accept the VM being a weaker example, I too regard binary sub-routines as reuse.
> > 2) Not experiencing some reuse with the vast
> majority of new
> > code, means you are not doing OO; you are doing
> something wrong,
> > very wrong.
> So why do most enterprises roll their own J2EE
> frameworks?
IMHO, A mixture of reasons, mostly commercial and partly pragmatic, generally not technical or paradigmatic reasons.
In my case, when we started no server-side framework existed beyond the Servlet API. My first server side Java framework was a templating and front controller/command handler system, then WebMacro/Tea & finally JSP appeared. This prompted a rewrite/refactoring using JSP and recently adding a pretty extensive XML soft coded MVC architecture. We are still using this because its currently superior to Struts (I would think that I'm its architect:) however given time, I have little doubt, Struts will overhall it, and then I will port.
Then there is the OpenSource/Proprietary play off, whilst I'm open minded, even pro-open source, many are not, including my manager. I would quite like to open 'my' framework, and intergrate some of my idea into Struts, but its not my decision.
> > Post-OOP ?
> Yes. After reading various magazines (SD Times,
> Computerworld, InfoWorld and the like) i'm getting the
> impression that there's a shift towards the term
> 'component-oriented' instead of 'object-oriented' (see
> http://java.sun.com/features/2002/03/compsource.html
> ). Please note the ':-)'.
> > So in your own word how does and Object differ from
> a Component?
> A component is made of objects. It provides binary
> reuse not source reuse. Examples are Component Object
> Model (COM) and EJB.
OK, I can agree with that. Though I regard Components as meta-OO, rather than post-OO.
> Martin, i apologize for utilizing your posting. It was
> not my intention to attack you. It would have been
> better to start a new thread. I will do better next
> time.
>
> Markus
OK, Thanks.
I also apologise for jumping to conclusions and my implications, which are clearly wrong. I get a little 'up-tight' about this type of stuff.
Martin.
MartinS. at 2007-7-2 22:37:13 >
I thought everybody in this thread might be interested in reading this article:
Robert Simmons, J2EE Platform Independence: Have We Regressed: 'The object-oriented line of "Why develop if you can buy it?" has been horribly perverted.'
http://www.theserverside.com/resources/article.jsp?l=Regressed
Make sure you read the comments too.
PS: And you might be surprised to hear that objects are the past with their peak in 1993:
http://www.sun.com/executives/sunjournal/v5w3/feature3.html
(Please note that this is for executives only! :-)
Howlingmad at 2007-7-2 22:37:13 >
That is a very good article, and I think the comment "We now have web developers that couldn't understand the raw code with a road map and two hunting dogs" describes STRUTS to a tee.
Let me make this simple comparison. One of the big reasons people are moving to EJBs is that fact that objects (not code) are shared. The container creates X number of EJBs and use them over and over again, thus cutting out the need to produce new objects for each request. In STRUTS, you give up the benefit of having the Servlet instance already created because you are now generating a ActionForm and Action instance for EVERY request. In my mind, this is like taking one step forward and three back, making it easier for the developer at the cost of performance. I have to wonder how many of the people who are so big on STRUTS actually understand the Servlet Specification and how things really work.
ken_robinson at 2007-7-2 22:37:13 >
> generating a ActionForm and Action instance for EVERY request.
I think that is not the case. In the javadoc comments for the Action class, Craig McClanahan writes the following: 'Actions must be programmed in a thread-safe manner, because the controller will share the same instance for multiple simultaneous requests.'
In the log file of a typical Struts application, you will find the following entries after a request for, lets say '/dummy':
action: Processing a GET for /dummy
action: Setting locale 'en'
action: Looking for Action instance for class foo.bar.DummyAction
action:Double checking for Action instance already there
action:Creating new Action instance
Now the Action instance exists and if you request '/dummy' again, only the following log entry is generated:
action: Processing a GET for /dummy
action: Looking for Action instance for class foo.bar.DummyAction
And as ActionForm beans are stored in the users session to redisplay form entries the user has already entered, there's no need to generate them for each request (see The Struts User's Guide, 2. Building Model Components, 2.3 ActionForm Beans, http://jakarta.apache.org/struts/doc-1.0.2/userGuide/building_model.html#actionform ).
Markus
Howlingmad at 2007-7-2 22:37:13 >
> I think the comment "We now have web developers that couldn't
> understand the raw code with a road map and two hunting dogs"
> describes STRUTS to a tee.
Maybe, but is it a drawback or an advantage? Does one really have to know each and every detail? I think this is not necessary if you work in a team. With frameworks like Struts, even junior developers can build web applications without knowing all the details. Of course, there should be a senior developer at hand if there's a problem that can only be solved by understanding the raw code.
Howlingmad at 2007-7-2 22:37:13 >
My point is that, in my opinion, the Servlet API is already VERY simple.
Does anyone REALLY think that the Servlet API is hard? Again, I prefer knowing the base API and getting performance over the 'any old java guy off the street can do it' solution. Any java developer should be able to figure out the Servlet API.
Think about it, STRUTS does not perform VooDoo. It just uses the underlying Servlet API, along with other APIs like reflection, to get it's job done. There is no way STRUTS is faster at runtime as it is an other layer over top of a working API.
Why would one spend the time to learn STRUTS when, in my opinion, you can learn the Servlet API in a comparable amount of time? Really, is getting a RequestParameter at run time that much harder than at development time? You need to know the name of the parameter in either case, and in either case you get the parameter as a String. Why go through the trouble of learning an API that says Toe-May-Toe instead of Ta-Ma-Toe while adding overhead to the Server?
Sad to say it looks like this will be an issue that will have two distinct groups of believers. Those who prefer the Servlet API and those who prefer STRUTS. While I see STRUTS as a buzzword more than a viable API, there are others who think STRUTS is worth using. Everyone is entitled to their opinion, this is mine.
ken_robinson at 2007-7-2 22:37:14 >
There is no reason to use STRUTS unless you are completely dumb. You should design and implement your own frameworks. The MVC architecture is so easy to understand. I don't want my jsp code to following rules defined by STRUTS...
thunderBolt at 2007-7-2 22:37:14 >
> There is no reason to use STRUTS unless you are completely dumb.Thank you! :-)
Howlingmad at 2007-7-2 22:37:15 >
Well, I wouldn't quite put it that way.
The point I am trying to make is that the J2EE standard (for Servlets anyway) IS a framework. You should only need to add a few items, if anything.
It seems a lot of attention is given to the ActionServlet because it acts as the 'controller'. Why is it so hard to see that the web server ALREADY does this for you? Whatever URL comes in, it is mapped to a servlet to call. Why map that call to an other class? A Servlet is very, very easy to write. There are no constructors and only three methods (usually two) you need to worry about.
With Filters and LifeCycle events we already see two BIG tools that are not supported by STRUTS and any other home grown framework.
ken_robinson at 2007-7-2 22:37:15 >
Hi guys
i am confused about MVC and struts.
As for as understand ,it seperates logic from view.
But why Controller servlet?
if Controller servlet is for redirecting
then web server is already doing it!!!?
may be I dont know What is the adv of having this.
if anyone can suggest me any url resource for the above
or any ideas about this
raghu_raman_k at 2007-7-2 22:37:15 >
> But why Controller servlet?Have you read the messages in this topic?
Howlingmad at 2007-7-2 22:37:15 >
Raghu, that is one of the points I have been trying to make. In my opinion, you are correct in thinking that the webserver is the controller. It takes nothing more than a URL and determines which Servlet to call. STRUTS uses only one servlet to determine which Action to create/call. Basically they are adding a step to the process.
STRUTS is smoke and mirrors.
Learn the Servlet/JSP API, you will be MUCH better off.
ken_robinson at 2007-7-2 22:37:15 >
I have mixed feelings about using framework like Struts. I mostly agree with Ken - that everything that struts does can be done using java servlet api. I have developed controller servlets that somewhat follows the struts pattern, without much of the struts overhead. I have experience developing J2EE apps that way using both JavaBean to support JSP, as well as XML. When we did the initial study on struts last year for a project we found it too much overhead. So decided to go with creating a contoller servlet that does action forwarding and request handling.
IMO it is pretty easy to create all that you need from struts, for most J2EE projects with Servlet API.
mankesh at 2007-7-2 22:37:15 >
My framework, theseus (www.theseus.org) is very small, fast, lightweight and while doesn't provide the robustness of Struts, offers quite a bit. I am also working on an event based MVC framework (appended to theseus), with the Servlet 2.3 spec in mind. Just a note, if anyone is interested.
buckman at 2007-7-2 22:37:15 >
Struts resources:
http://jakarta.apache.org/struts/index.html
http://www-106.ibm.com/developerworks/ibm/library/j-struts/
http://www.jguru.com/faq/Struts
Alternatives to Struts:
Tea
http://opensource.go.com/Tea/index.html
XMLC
http://xmlc.enhydra.org/
WebWork
http://sourceforge.net/projects/webwork/
Tapestry:
http://tapestry.sourceforge.net/
Maverick
http://mav.sourceforge.net/
Velocity:
http://jakarta.apache.org/velocity/
WebMacro:
http://www.webmacro.org/
Jetspeed:
http://jakarta.apache.org/jetspeed/site/index.html
Jakarta Taglibs:
http://jakarta.apache.org/taglibs/index.html
Barracuda:
http://barracuda.enhydra.org/index.html
Freemarker:
http://freemarker.sourceforge.net/
JSPTAGS:
http://sourceforge.net/projects/jsptags
Related information:
http://barracuda.enhydra.org/cvs_source/Barracuda/docs/landscape.html
http://java.sun.com/products/jsp/
http://java.sun.com/blueprints/patterns/j2ee_patterns/model_view_controller/
scsulliv at 2007-7-2 22:37:15 >
Yet another resource: http://www.must.de/cameleon.html(the ultimate reuse - no matter whether Servlet, JSP or Swing)
CMueller at 2007-7-2 22:37:15 >
See also:
http://www.waferproject.org/index.html
{
"Wafer is a research project which compares the many open source web application frameworks which are available using a common example application. This research project is designed to compare the application frameworks on a level field by specifying an example application so that the application features become irrelevent and the merits of each framework becomes the focus.
The first phase of this project is to identify and examine the numerous open source web application frameworks written in Java. The reason for the focus on Java is because it is one of the primary languages used for developing web based applications for Enterprises at this time."
}
scsulliv at 2007-7-2 22:37:15 >
Hi,I am just against any framework which provides a wrapper over html tags.Follow this link for more discussions on this: http://forum.java.sun.com/thread.jsp?forum=45&thread=273726Any voters for this ?Thx
jocky at 2007-7-2 22:37:15 >
Just to throw in my two cents about Struts... I work in a mid size engineering firm with a number of large internal applications. Many of these must be available in at least three languages, and many have literally hundreds of different JSP's and views avaialable to the client applications. Of these applications the oldest is build on Python, the newer app on JSP and Servlets and the very newest on Struts. By far the application built on Struts is the easiest to maintain and most reliable. Having a common framework that enforces accepted design patterns throughout the application allows us to easily change templates and language resource files that effect the entire site. As well with many developers it makes understanding and modifying existing code a lot simpler. Though much of this is possible using JSP and Servlets, or yes even Python, it is much more work to implement and requires that both these applications keep a larger pool of developers while maintaining less pages on less trafficed sites. In fact our company has just approved a new team that will transfer the existing Python application to the Struts framework. Though I wouldn't say that Struts, or any framework for that matter, is the answer to all the web application problems out there it can make it easier for large projects. On the other hand there is usually more setup when using a framework so if you're just doing something that is quite small or needs to be developed quickly and not maintained for very long you may be better off coding everything on your own. Before you start a project you should do your homework and see what your getting yourself into both while your building the site, and once your maintaining it.
Cheers
-Mark
runningboy at 2007-7-2 22:37:15 >
> Many of these must be
> available in at least three languages, and many have
> literally hundreds of different JSP's and views
> avaialable to the client applications.
> Having a common
> framework that enforces accepted design patterns
> throughout the application allows us to easily change
> templates and language resource files that effect the
> entire site.
I have used STRUTS and just disagree with this, nothing personal.
STRUTS does not make it easier to manage JSPs, you still have to have as many as before. The main difference is that STRUTS allows you to map page A to servlet B in an xml file. This is easily done (although not many people do) with servlet parameters. In either case you have to look for a hard coded value (something like "SUCCESS" in STRUTS) to get the page URL or ID you want. This option is a solution that was always there, but not everyone used.
I cannot for the life of me see why people associate internationalization with STRUTS. The language resource files are part of the JDK, nothing special about them. Even if you like this option, it is not an inovation added by STRUTS.
Again, the J2EE classes, in my opinion, ARE a Framework. The problem is too many people either do not know them or do not want to know them. Again, the webserver acts as the Controller already, there is nothing that can be done about that. Just think, when the browser sends the URL to the server, the server looks at it and decides which servlet to forward the request to. That right there is the Front Controller Patter. Why are people obsessed with taking an already forwarded request and doing the work again?
Everything 'good' I have seen about STRUTS is someone saying how it lowers development time. While faster development time can be a very good thing, it becomes a bad thing when done at the cost of performance.
When STRUTS gets each HttpServletRequest, it looks for EACH AND EVERY parameter, via reflection, in the ActionForm for a matching method. Is it really so hard to map an HttpServletRequest object to a form that it is not thought to be 'good' to have it done for you without thought?
Again, Learn the JSDK and use the JSDK, you will be much better off. Oh, and if your developers do not know (or cannot learn very quickly) the JSDK, get new developers, it is no harder than STRUTS.
ken_robinson at 2007-7-2 22:37:15 >
Does anyone try the JADE,it became open source not long ago,and much more powerful and easier than struts
wqhhust at 2007-7-2 22:37:15 >
This should be considered in favour of frameworks in general rather that STRUTS in particular.
> > Many of these must be
> > available in at least three languages, and many
> > have
> > literally hundreds of different JSP's and views
> > avaialable to the client applications.
>
> > Having a common
> > framework that enforces accepted design patterns
> > throughout the application allows us to easily
> > change
> > templates and language resource files that effect
> > the
> > entire site.
>
> I have used STRUTS and just disagree with this,
> nothing personal.
Perhaps you should be more specific about what you disagree with because the following paragraph looks contradictory to me. It appears to be a strawman. In the first instance it disagrees in principal, then supports one of the mechanisms, with the suggestion that it should be wastfully re-implemented each time it's needed. This is a waste of resources, including developer, hardware and time.
> STRUTS does not make it easier to manage JSPs,
> you still have to have as many as before.
Strawman.
The *number* of pages has little to do with complexity or maintainability.
I suggest you study decomposition, complexity, 'N' and 'P# type problems.
> The main
> difference is that STRUTS allows you to map page A to
> servlet B in an xml file. > This is easily done
> (although not many people do) with servlet parameters.
> In either case you have to look for a hard coded
> value (something like "SUCCESS" in STRUTS) to get the
> page URL or ID you want. This option is a solution
> that was always there, but not everyone used.
I presume by 'Servlet Parameters' you mean URI parameters. These offer a *very* poor solution to softcoded workflow, they are insecure, inflexibly, and couples presentation with the workflow/business logic.
There is nothing inherently wrong with hardcoded values for constants, assuming otherwise suggests a cargo cult understanding of prohibitions against magic numbers. Constant values do not equal hardcoded workflow.
STRUTS does not require hardcoded values for workflow constants. A resource bundle offers an good alternative, this has the advantage that the values can be easily [re]loaded dynamically.
The consequences of a constant can be easily softcoded, so it is possible to softcode the results thoughout a system. If you are using STRUTS or not.
Consider the following hybrid, a 100% softcoded workflow using constant results.
<request name="/entity_display" class="com...EntityCRUD" access-control="com...FullAccess">
<mapping action="forward" result="200" page="/entity_display.jsp"/>
<mapping action="forward" result="201" page="/entity_created.jsp"/>
<mapping action="forward" result="400" page="/error.jsp"/>
<mapping action="forward" result="401" page="/unauthorised.jsp"/>
<mapping action="forward" result="403" page="/forbidden.jsp"/>
<mapping action="forward" result="404" page="/not_found.jsp"/>
<mapping action="forward" result="100" page="/lookup_not_found.jsp"/>
<mapping action="redirect" result="888" page='/logon.jsp'/>
<mapping action="redirect" result="999" paremeter="GOTOURI">
</request>
> I cannot for the life of me see why people associate
> internationalization with STRUTS. The language
> resource files are part of the JDK, nothing special
> about them. Even if you like this option, it is not
> an inovation added by STRUTS.
I cannot why you've confused supporting multiple languages with internationalisation.
Consider the following scenario.
- 3 Languages (English, French, German)
- 3 Styles (Normal, Low Graphics/Printer, Disabled Access)
- 5 Client devices (PC,STB,WAP,3G,PDA]
Your suggested solution requires; number of templates * 45 (languages(3) * styles(3) * client devices(5)) JSP pages. A similar framework solution requires one set of templates + 2 style sheets. Yes 2, one for the client devices and one for the style. A lot less work and produces a more robust solution.
MartinS. at 2007-7-2 22:37:15 >
The above response is EXACTLY the ignorance about the J2EE spec I am talking about. STRUTS uses the J2EE spec, but with a new wrapper on top of it. For some reason, many people seem to think it is new, an alternative.
About the JSPs, my point was exactly what you said, the number of pages has NOTHING to do with how complex an app is. With or without STRUTS, you still have the same number to maintain. One thing that needs to be understood, a Servlet Parameter is a parameter used by the Servlet Instance. A Request Parameter is a parameter used for each unique HttpServletRequest. I am speaking of the first, Servlet Instances. STRUTS does nothing more than map a hard coded value to a forward URL. In your example I believe (correct me if I am wrong) it is the value in the result attribute. My suggestion was instead of creating objects to do this, load the JSP's URL into a String via a Servlet Parameter (from the ServletConfig during the init() method). Now at runtime, you do not have to use an object that will look up the value (this is what STRUTS does), you already have it. Use the request dispatcher and forward the request.
In either case, the end result is the same. With the J2EE way, you get a faster response (this is what I prefer). If you decide to change from a forward to an include, it is a quick code change and a redeploy. With STRUTS, you get a slightly slower response since the value you use must be mapped, for each request, to the request URL. If you decide to change from a forward to an include, you change the struts config file instead of the code and restart. You can choose either method you like, but personally I would much rather have the runtime speed.
As far as the internationalization goes, I believe you have not understood my point. You solution to this problem would no doubt work. However, it also defers the translation of the template to which language, style and device to a runtime process. Again, more overhead. While maintaining 45 different templates is also a solution, it is not one I would employ. I would rather use a cross between both solutions you have mentioned. Simply create the templates you have mentioned. Before deployment, combine that (I'd use a tool, not a manual process) with the data in the Resource File and create the required number of templates. The advantage is you only do the merging of the data once and thus each request is handled much faster. The disadvantage is that you now have a greater number of JSPs in memory. Personally I would rather spend a few dollars on more memory (given it's current cost) than lengthen my response time.
ken_robinson at 2007-7-2 22:37:18 >
> The above response is EXACTLY the ignorance about the
> J2EE spec I am talking about. STRUTS uses the J2EE
> spec, but with a new wrapper on top of it. For some
> reason, many people seem to think it is new, an
> alternative.
Why do you insist on trying to construct strawmen and being offensive ? If you want to troll take it to a more appropriate forum like the Water Cooler.
MartinS. at 2007-7-2 22:37:18 >
First, if you think the work 'ignorance' (uninformed) to be offensive, again you misunderstand my meaning. My point is that many people seem to think STRUTS offers new technology, when in fact it just rewraps what is already provided (thus some people are uninformed, or ignorant).
Second, I think you are being a bit close minded. STRUTS is not a Silver Bullet, it is just an alternative to doing things in the J2EE world. I could really care less which road you choose, mainly because I do not work with you. If you think my examples are 'strawmen', then that is your opinion. However, your use of the word 'strawmen' did not upset me or cause me to think you should go running to an other forum.
I do not want to fall into using these forums as a way of having it out with any one user. I really doubt I am able to change your mind, and I can tell you I am not going to change my view on STRUTS. Good Day.
ken_robinson at 2007-7-2 22:37:18 >
> First, if you think the work 'ignorance' (uninformed)
> to be offensive, again you misunderstand my meaning.
> My point is that many people seem to think STRUTS
> offers new technology, when in fact it just rewraps
> what is already provided (thus some people are
> uninformed, or ignorant).
>
Yup!!! I Agree with you!!!!!!!
> Second, I think you are being a bit close minded.
> STRUTS is not a Silver Bullet, it is just an
> alternative to doing things in the J2EE world.
Of course it is not panacea either !!!!!!!!!!
jocky at 2007-7-2 22:37:18 >
> Why would you be surprised if STRUTS became a
> standard?
>
> Everything STRUTS allows you to do can already be
> done. Why would SUN add the overhead of STRUTS while
> adding no new functionality?
>
> Learn the Servlet/JSP specification, you'll be MUCH
> better off.
To extend that argument(?), I guess you could also say:
Everything that J2EE can do, Corba or .Net can do?
Everything that Java can do, C++ can do?
Everything that C++ can do, Assembler can do?
Everything that Assembler can do, machine code can do?
Everthing that a computer can do, I can do with pencil and paper?
That isn't the point. Neither is, to a lesser extent, performance. Not that performance isn't important, but a repeatable framework that performs reasonably is also useful. If all you are concerned about is performance, machine code is fantastic!
The primary purpose of Struts is to enable the quick and efficient implementation of well-architected web applications. Its intent is to support using JSPs, Servlets and model components (EJBs, Web Services, or whatever) in an efficient manner to *quickly* implement web applications with a toolkit that allows a certain amount of decoupling/abstraction between view and model.
It complements J2EE, but doesn't throw in every bell and whistle for marketing and advertising purposes, like certain petstore applications I've seen.
It implements a pattern that is fairly quick to learn, allows repeatable processes to create application components, and allows me to easily find developers that are already up to speed on this pattern.
David Tomlinson
Enterprise Architect
EACG, Inc.
dtomlinson at 2007-7-2 22:37:18 >
> Just to throw in my two cents about Struts... I work
> in a mid size engineering firm with a number of large
> internal applications.
>...
> By far the application built on Struts is the easiest
> to maintain and most reliable. Having a common
> framework that enforces accepted design patterns
> throughout the application allows us to easily change
> templates and language resource files that effect the
> entire site. As well with many developers it makes
>
Yowza, somebody that finally talks about what is important in web application development! Maintenance, reliability, and accepted design patterns are, in the long run, more important that any argument that relies upon repeating "Learn the Servlet API" over and over again.
David
dtomlinson at 2007-7-2 22:37:18 >
...>
> Second, I think you are being a bit close minded.
> STRUTS is not a Silver Bullet, it is just an
> alternative to doing things in the J2EE world. I
> could really care less which road you choose, mainly
> because I do not work with you. If you think my
> examples are 'strawmen', then that is your opinion.
> However, your use of the word 'strawmen' did not
> t upset me or cause me to think you should go running
> to an other forum.
>
Close minded! Who is the one who keeps repeating "Struts is not needed, learn the Servlet API", over and over and ...zzzzzzz
David
dtomlinson at 2007-7-2 22:37:18 >
Here we go again.
At risk of sounding rude, I state the following:
STRUTS is nothing more than a way of coding. There is ZERO performance advantage to using STRUTS (quite the opposite in my opinion). Most people work on sites that do not require high speed performance and thus do not notice this.
The most common 'advantage' I here people state is that STRUTS is Model 2. A web container (J2EE, .NET or anything, even CGI) can be defined as Model 2. Is it really so hard to see that the container itself is a controller? The first thing a container does is examine the URL and decide what to do with it (server an image, HTML file or forward to a servlet/.Net object/PHP script/CGI). In the case of STRUTS, it forwards to the ActionServlet which in turn examines the same URL again. Ugggh.
I could go on and on about the 'advantages' of STRUTS and the overhead they cost (ActionForms being the worst).
It is my opinion that many who use STRUTS do it because of one of the following reasons:
1) It is the 'new' thing. Everyone is doing it. I'll just follow without doing my own evaluation of overhead vs. actual benifit.
2) I have to use Model 2, and this is the most popular way to do it. I probably haven't given any thought to why Model 2 is needed, but I know I want it.
3) Instead of making coding standards that best benifit my environment, I will just implement STRUTS and say that is our standard (can't tall you how many people say 'We Use STRUTS' when asked about their standard). Never mind I don't seem to realize ALL the logic that would be required for any other framework/method is needed, I seem to think that this Web Framework also provides a standard for how I maintain my actual code. If you think managing a site is easier because of STRUTS, you just do not understand all involved technogies/APIs. Resource/Message files are the most common API usually grouped as an advantage when they are part of Java.
I have asked this question over and over and have yet to hear an answer instead of people just defending STRUTS.
QUESTION: I am a very good J2EE developer who understands everything that J2EE can do out of the box. As the head of many projects, I have enforced strict coding standards that ensure all developers (both senior and junior) develop their solutions in a common way. Give me a sound technical reason, with explanation, of why I should switch from this method to STRUTS. Keep in mind, if I disagree with anything submitted, I will provide a technical reason for my opinions.
ken_robinson at 2007-7-2 22:37:18 >
On a side note, I just installed the 1.4 J2EE SDK and notice Struts in there--used in the admin app.
stevedorato at 2007-7-2 22:37:18 >
www.waferproject.org. This project compares various J2EE frameworks and developed a matrix of the features. Check this out.
jkicha at 2007-7-2 22:37:18 >
> QUESTION: I am a very good J2EE developer who
> understands everything that J2EE can do out of the
> box. As the head of many projects, I have enforced
> strict coding standards that ensure all developers
> (both senior and junior) develop their solutions in a
> common way. Give me a sound technical reason, with
> explanation, of why I should switch from this method
> to STRUTS. Keep in mind, if I disagree with anything
> submitted, I will provide a technical reason for my
> opinions.
Hmmmm... I would like to know the answer to this as well, especially a counter to the argument that the container acts as the controller, while the servlets themselves can be action handlers.
sysop at 2007-7-2 22:37:18 >
What ever be the pros and cons of Struts
There is lot of demand for struts in the market.Increases your job prospects. I dont know why big comapanies are going for struts or they are fooling their clients by creating hype just as web-services is doing (CORBA is already there doing all the things)
Indeed struts unnecessary add performance overhead by wrapping request paramenter in beans then acessing those fields using reflections.
Other features are also and already there. like internationalization, templates(many source code examples are there)
Ashwani
ash_k at 2007-7-2 22:37:18 >
> QUESTION: I am a very good J2EE developer who
> understands everything that J2EE can do out of the
> box. As the head of many projects, I have enforced
> strict coding standards that ensure all developers
> (both senior and junior) develop their solutions in a
> common way. Give me a sound technical reason, with
> explanation, of why I should switch from this method
> to STRUTS. Keep in mind, if I disagree with anything
> submitted, I will provide a technical reason for my
> opinions.
i thought struts, with its extensive taglib, allowed you to more easily create and manage your jsp and servlet structures. rather than creating a jsp/servlet combo for each sequence of events you could create the jsps that would provide instructional objects through one common servlet. is it not easier than creating a seemingly endless number of servlets. doesn't the elimination of that redundancy allow for improved efficiency?
my understanding is that struts is simply an extension of j2ee, and a model that enhances the development process.
please don't lambast me here, i am just discussing the topic.
i guess development, maintainability and performance would be my reasons. although, its been my experience so far, that robustness may be a major issue.
tpinard at 2007-7-2 22:37:18 >
> i thought struts, with its extensive taglib, allowed
> you to more easily create and manage your jsp and
> servlet structures. rather than creating a
> jsp/servlet combo for each sequence of events you
> could create the jsps that would provide instructional
> objects through one common servlet. is it not easier
> than creating a seemingly endless number of servlets.
> doesn't the elimination of that redundancy allow for
> improved efficiency?
>
> my understanding is that struts is simply an extension
> of j2ee, and a model that enhances the development
> process.
>
> please don't lambast me here, i am just discussing the
> topic.
>
> i guess development, maintainability and performance
> would be my reasons. although, its been my experience
> so far, that robustness may be a major issue.
>
In J2EE you would have X number of Servlets. In STRUTS you would have X number of Actions.
The Taglibs in STRUTS where in my opinion (except the HTML tags, why learn that again) one of the more useful offerings of STRUTS. However, with JSTL fast becoming the standard I think they've served their purpose and should be phased out. Not because I hate STRUTS, but because JSTL will most likley become the industry standard TagLib.
ken_robinson at 2007-7-2 22:37:18 >
i am planning on implementing jstl, it looks sweet. no comments on performance of one giant struts xml servlet thingy? i'm curious if that would be a bottleneck. that's why i'm leaning away from the framework.
tpinard at 2007-7-2 22:37:18 >
The web container will handle each request in it's own thread regardless of the framework (or lack of). As long as the method calls are thread safe there should not be a bottleneck.
The container will not 'lock' the servlet, do it's work and then unlock it. STRUTS will not 'lock' the Action, it will call the execute/perform (which is it now?) method.
The container will create one instance of a servlet and STRUTS will create one instance of the Action. Again, it's the same logic, just in a different wrapper.
ken_robinson at 2007-7-2 22:37:21 >
>
> i thought struts, with its extensive taglib, allowed
> you to more easily create and manage your jsp and
> servlet structures. rather than creating a
> jsp/servlet combo for each sequence of events you
> could create the jsps that would provide instructional
> objects through one common servlet. is it not easier
> than creating a seemingly endless number of servlets.
> doesn't the elimination of that redundancy allow for
> improved efficiency?
Yes, Structs is about improving the programmers efficiency by re-use and avoiding the need to constantly re-invention the wheel.
> my understanding is that struts is simply an extension
> of j2ee, and a model that enhances the development
> process.
Indeed!
> i guess development, maintainability and performance
> would be my reasons. although, its been my experience
> so far, that robustness may be a major issue.
Yep, these are all important benefits of code-reuse.
MartinS. at 2007-7-2 22:37:21 >
I fail to see how an Action/JSP combo is different than a Servlet/JSP combo in anything but name. Again, please give me an example of how STRUTS enhances the development process.
ken_robinson at 2007-7-2 22:37:21 >
> I fail to see how an Action/JSP combo is different
> than a Servlet/JSP combo in anything but name.
>
> Again, please give me an example of how STRUTS
> enhances the development process.
i like the way i am able to separate presentation aspects, primarily those stuffed into my jsps, from business logic. by using actions, i am able to encapsulate business logic thus, to its detriment couple the servlet with the actions. the alternative, coupling the servlet to the jsp, which is not preferred for one major reason. i don't create the look and feel, or any user interface. it allows me to focus on the business.
servlet/jsp is different than servlet/action/jsp, that is the beauty of extending j2ee with this framework. it allows you to create re-usable widgets, not very object oriented, but who j2ee was right?
i'm sure development seems much easier with this framework(struts), but what about maintaining the struts-config.xml, and performance issues with creating classes at runtime.
tpinard at 2007-7-2 22:37:21 >
> i like the way i am able to separate presentation
> aspects, primarily those stuffed into my jsps, from
> business logic. by using actions, i am able to
> encapsulate business logic thus, to its detriment
> couple the servlet with the actions. the alternative,
> coupling the servlet to the jsp, which is not
> preferred for one major reason. i don't create the
> look and feel, or any user interface. it allows me to
> focus on the business.
?
Take ANY Action. Create a servlet and place the same logic in the Action in the doPost or doGet method. Using web.xml, name the servlet and map it to the URL you want. Forward to the same JSPs you would forward to via the ActionMapping (use init params to map the keys to a JSP instead of hardcoding).
How is this different, except the STRUTS overhead is gone?
>
> servlet/jsp is different than servlet/action/jsp,
You're right. Servlet/JSP step is faster. The ActionServlet step is totally skipped.
> that is the beauty of extending j2ee with this framework.
> it allows you to create re-usable widgets, not very
> object oriented, but who j2ee was right?
How can you not do this with Servlets?
You can create one Servlet and map it to one URL.
You can create one Servlet and map it to multiple URLs.
You can create one Servlet, register it many times (with different <servlet-name> and <init-params> and reuse the same code.
>
> i'm sure development seems much easier with this
> framework(struts), but what about maintaining the
> struts-config.xml, and performance issues with
> creating classes at runtime.
>
I see no difference between maintaining web.xml or struts-config.xml (they both get out of hand). Both create one instance of the Servlet/Action and use it for all threads (SingleThreadModel is now dead in 2.4). ActionForms are just performance dogs. Use reflection EVERY time? Take two minutes and write that code yourself (spend a penny today, save a dollar tomorrow).
My point is reflected in your post. Once you see that the same exact thing can be done (MVC) without STRUTS, it really just becomes an other way to do the same thing.
Container->ActionServlet->Action->JSP
Container->Servlet->JSP
Take a few minutes, learn Servlets (they are VERY easy) and cut an entire step out. Leverage what you HAVE to use since the container is going to do it anyway. Think about it, if STRUTS where the way to go, would not web servers just require a struts-config.xml instead of web.xml? EVERYTHING you do in STRUTS is run through the basic J2EE stuff for you, that HAS to cost overhead.
ken_robinson at 2007-7-2 22:37:21 >
> > i like the way i am able to separate presentation
> > aspects, primarily those stuffed into my jsps, from
> > business logic. by using actions, i am able to
> > encapsulate business logic thus, to its detriment
> > couple the servlet with the actions. the
> alternative,
> > coupling the servlet to the jsp, which is not
> > preferred for one major reason. i don't create the
> > look and feel, or any user interface. it allows me
> to
> > focus on the business.
>
> ?
> Take ANY Action. Create a servlet and place the same
> logic in the Action in the doPost or doGet method.
> Using web.xml, name the servlet and map it to the URL
> you want. Forward to the same JSPs you would forward
> to via the ActionMapping (use init params to map the
> keys to a JSP instead of hardcoding).
>
> How is this different, except the STRUTS overhead is
> gone?
>
lets's say i don't want to have my business logic in my servlet. i want to promote oo principles, and use the servlet as a work flow controller. which is what struts does. it creates one massive servlet, that controls flow. use the servlet for what it was designed, communication not thinking, hence the name servlet sort of sounds like server. by doing this you will be able to change implementation without changing your servlet or 5 servlets that use the same action.
>
>
> >
> > servlet/jsp is different than servlet/action/jsp,
> You're right. Servlet/JSP step is faster. The
> ActionServlet step is totally skipped.
>
>
> > that is the beauty of extending j2ee with this
> framework.
> > it allows you to create re-usable widgets, not very
> > object oriented, but who j2ee was right?
>
> How can you not do this with Servlets?
> You can create one Servlet and map it to one URL.
> You can create one Servlet and map it to multiple
> URLs.
> You can create one Servlet, register it many times
> (with different <servlet-name> and <init-params> and
> reuse the same code.
>
>
> >
> > i'm sure development seems much easier with this
> > framework(struts), but what about maintaining the
> > struts-config.xml, and performance issues with
> > creating classes at runtime.
> >
>
> I see no difference between maintaining web.xml or
> struts-config.xml (they both get out of hand). Both
> create one instance of the Servlet/Action and use it
> for all threads (SingleThreadModel is now dead in
> 2.4). ActionForms are just performance dogs. Use
> reflection EVERY time? Take two minutes and write
> that code yourself (spend a penny today, save a dollar
> tomorrow).
>
again, oo priciples, actionforms are your value objects, they don't perform, and in fact if you are putting implementation in them you are not writing them as they were intended to be used.
>
>
> My point is reflected in your post. Once you see that
> the same exact thing can be done (MVC) without STRUTS,
> it really just becomes an other way to do the same
> thing.
>
> Container->ActionServlet->Action->JSP
> Container->Servlet->JSP
>
> Take a few minutes, learn Servlets (they are VERY
> easy) and cut an entire step out. Leverage what you
> HAVE to use since the container is going to do it
> anyway. Think about it, if STRUTS where the way to
> go, would not web servers just require a
> struts-config.xml instead of web.xml? EVERYTHING
> you do in STRUTS is run through the basic J2EE stuff
> for you, that HAS to cost overhead.
>
your comment about learning servlets can only be construed as being an insult, perhaps it is you that should learn more about struts before arguing points that you clearly have little understanding of based on your comments. to be able to use struts you need to understand the building blocks which are servlets, jsps and tag libraries, so i would say that i do know servlets. i would not say that i am an expert, but i only recently learned struts, before which development of enterprise applications was done oddly enough without struts. the model usually used by applications could be classified as a controller-view, where you have a controller servlet, that forwards requests to other servlets, ejb or whatever. struts merely facilitates that pattern, while adding a means for separating business logic from control. the overhead of struts is insignificant, what are we talking one maybe two classes and the inherited servlet, big deal.
the real problem with struts, imho, is the parsing of the struts-config.xml and creation of classes, which you pointed out that applications not using struts might have a correpsondingly huge web.xml. i still think struts' weakness lies in the struts-config.xml, but apparently there is noone here to comment about that aspect.
tpinard at 2007-7-2 22:37:21 >
> lets's say i don't want to have my business logic in
> my servlet. i want to promote oo principles, and use
> the servlet as a work flow controller. which is what
> struts does. it creates one massive servlet, that
> controls flow. use the servlet for what it was
> designed, communication not thinking, hence the name
> servlet sort of sounds like server. by doing this you
> will be able to change implementation without changing
> your servlet or 5 servlets that use the same action.
Please explain to me how changing a servlet is different from changing an Action? Servlets are NOT meant to communicate. The web container does all of that. The ONLY thing a servlet is given to do it's work is a ServletRequest and ServletResponse object. Is this not the SAME thing an Action is given to do it's work? Again, whatever code would have gone into the Action just goes into the Servlet. It makes not difference if I plug an EJB call, a DAO call or whatever I am using into the Servlet/Action, it's the same business code.
In STURTS, you need the ActionServlet to get to each individual Action. In plain J2EE (what STRUTS is built upon), the container always determines which servlet to forward to. Even in STRUTS this step occurs, it just always forwards to the ActionServlet which goes through the mapping process a 2nd time.
> again, oo priciples, actionforms are your value
> objects, they don't perform, and in fact if you are
> putting implementation in them you are not writing
> them as they were intended to be used.
>
You are correct, zero implmentation should be put into an ActionForm (or any bean meant to simply wrap incoming data).
However, the only reason to use an ActionForm is because you want STRUTS to populate it automatically. While you have the convenience of not having to write the logic that takes the parameter from the request and setting it in the bean, you defer this to a reflective search of EVERY request parameter that comes in for EVERY request. That is overhead.
Writting the code to set a string, convert an Int or parse a Date is very, very simple. I do not see justification in saving minutes (not hours) per bean when the cost are taken at runtime for each and every request. If STRUTS did this at compile time instead of runtime it may be worth it, but that is not how it works.
> your comment about learning servlets can only be
> construed as being an insult, perhaps it is you that
> should learn more about struts before arguing points
> that you clearly have little understanding of based on
> your comments. to be able to use struts you need to
> understand the building blocks which are servlets,
> jsps and tag libraries, so i would say that i do know
> servlets. i would not say that i am an expert, but i
> only recently learned struts, before which development
> of enterprise applications was done oddly enough
> without struts. the model usually used by
> applications could be classified as a controller-view,
> where you have a controller servlet, that forwards
> requests to other servlets, ejb or whatever. struts
> merely facilitates that pattern, while adding a means
> for separating business logic from control.
First, it was not meant as an insult, only to point out that many people view STRUTS as easier or better because of a lack of understanding of the Servlet Spec.
Anyone who would write a servlet for the sole purpose of forwarding to an other servlet is wasting time. Again, the container will do this automatically (this is the SOLE purpose of the <servlet-mapping> tag). Why build a forwarding mechanism or install something like STRUTS when the container is doing this anyway for each and every request?
> the overhead of struts is insignificant, what are we
> talking one maybe two classes and the inherited
> servlet, big deal.
My point is not exactly that STRUTS adds overhead or that it really adds nothing to what you already have. My point is that STRUTS adds overhead AND it provides no value already present.
Say I have two choices. I can buy a stock from a broker or I can call a company direct and buy the stock. In either case the stock itself will look and behave the same once I get it. If I buy it directly I save the cost of paying the broker's fee and I may even get it faster. On the other hand, paying the broker to do it only cost a few more dollars and I've only got to wait a bit longer, but in the end it's the same stock worth the same thing once it becomes mine.
My point is not to insult anyone, and if you feel insulted then I am sorry. Before you respond, please answer me one question. How is putting a block of logic in a servlet different than putting that same block of logic in an Action? Will they both not be executed? Will they both not require (and get) the Request and possibly the Response? Will they both (if done correctly) simply forward to a JSP page when complete (either via the ActionMapping or RequestDispatcher)? Image the ActionServlet is a stock broker. Each time you use him he takes a small bit off the top for himself. After so much time goes by, he's really taken a lot. Cut out the middle man and put the logic in a servlet.
>
> the real problem with struts, imho, is the parsing of
> the struts-config.xml and creation of classes, which
> you pointed out that applications not using struts
> might have a correpsondingly huge web.xml. i still
> think struts' weakness lies in the struts-config.xml,
> but apparently there is noone here to comment about
> that aspect.
ken_robinson at 2007-7-2 22:37:21 >
<q>
lets's say i don't want to have my business logic in my servlet. i want to promote oo principles, and use the servlet as a work flow controller. which is what struts does.
</q>
I'm not using Struts, because I have (I think) a better way:
Instead of Action I'm using Filter. Filter used as adapter from html to regular java.
Before displaying jsp page, Filter converts request's parameters into correct datatypes and pass them to javabeans. Javabeans have business logic, connect to database or EJB, etc. This way I can reuse javabeans for another types of client, another Filter, etc. Then Filter get data from javabeans and put it into Page/Request/Session Attributes.
Finally jsp displays data using JSTL. Very simple, reusable ipmlementation of <oo principles>.
lgurevich at 2007-7-2 22:37:21 >
In my opinions, Filters will make both the Servlet->JSP model and STRUTS obsolute.
If I implement all of my logic (or calls to logic) as a library of Filters, I simply need to 'script' a page using various FilterMapping tags before I reach my JSP. Each Filter is only responsible for getting the data it expects in the Request and setting the Attributes in the Request it is responsible for. It will not (in fact cannot) care which order in the chain it runs or which JSP it is going to.
Also, JSTL is a GREAT addition. Again, STRUTS and other TagLib providers where first, but now that there is a Standard, they need to take a bow for the great work they've done and either fade away or convert.
ken_robinson at 2007-7-2 22:37:21 >
> In my opinions, Filters will make both the
> Servlet->JSP model and STRUTS obsolute.
I agree generally that Filters are more powerful than Servlets, but Servlets are good when you have "end point" processing to do, even if you do forward to a JSP afterward. It doesn't make sense to deal with being part of a chain if you are really an end point. The HttpServlet class is also a useful abstaction when you have uses for responding differently for different HTTP methods, though I suppose an HttpFilter class could be added for this kind of thing. It is also useful when you need to override getLastModified() as you would want to do if your servlet was serving data from a database and it is really the last modification date of the db record that you want to return. getLastModified() only makes sense if you are an end point, so I don't think we'll ever see it in the Filter arena.
Filters are generally quite powerful, but their intent is not quite the same as Servlets, so I don't expect the Servlet class to go away, or the Filter class to be extended to do all the things that the Servlet class does. Struts has similar limitations (HTTP method, getLastModified()), but my argument here is just about the future of the Servlet class, not Struts.
>
> If I implement all of my logic (or calls to logic) as
> a library of Filters, I simply need to 'script' a page
> using various FilterMapping tags before I reach my
> JSP. Each Filter is only responsible for getting the
> data it expects in the Request and setting the
> Attributes in the Request it is responsible for. It
> will not (in fact cannot) care which order in the
> chain it runs or which JSP it is going to.
Configuring the filter mappings manually sounds painful, but an automated step in the build process might alleviate some of those pains. All those mappings might have a noticable performance cost as well, though I have heard that Tomcat 5 has a fancy way to find the right mappings for a given request quickly that other servers could implement. (Struts might do well to use a similar structure for its request routing.)
How would you handle validation in this setup? Sometimes validation might require two or more beans initialized in the filters. I guess you could structure your Filter classes such that their behavior could be reused by another Filter, but you would either have to jump through some hoops by sending them some dead-end chains, or create an abstraction (base class or interface) for having the code outside of the doFilter() method that you would need to develop, explain, and support within your project or organization. Or you could have a Filter that just did validation on beans that were pre-populated by other Filters in the chain, but now you have to worry about order. It might be a good idea at that point to create some bases classes for the different kinds of filters in your system to serve as an indicator of their purpose and collect common services code. I imagine the BeanPopulatingFilter would extend the ValidatingFilter class/interface in this case. I suppose that the filters could add their validation error messages to something in the request along the chain, but you would still need something before the JSP to check if there were any errors and forward the request back to the input form to report the errors and allow the user to correct the problems. That's a third kind of filter that should be recognized with a base class of some sort.
Filters might be a good base class for some of these components, but you would still want to have some kind of framework to identify the purpose and provide services code for each component. One of the big advantages of using a framework that someone else developed is that you don't have to document its operation. Another benefit is that if it has been around a while, its abstractions and behavior will be pretty stable from the testing it has received by others using it. If you develop your own framework, it is fairly likely that you'll have to change it along the way as new problems come up that you did not envision originally. Those changes will surely slow your team and may require rework of existing code. Plus, you've got to implement the changes in the framework code, update the docs, and describe to your team what changed.
I realize that you dislike how Struts initializes its ActionForms via reflection from a performance standpoint, but hand-coding that behavior seems like a bad idea from a general tedium and why-the-heck-isn't-the-someNewProperty-property-being-set-when-it-is-right-there-in-the-request standpoint. Perhaps a more performant, but still not hand-coded, solution is in order. Classes to handle the population of all the properties for a given bean could be generated with the build or even dynamically at runtime. All Struts apps could probably benefit from this dynamically-generated-at-runtime solution without changes. That is another advantage of using a framework -- you can benefit from the work of others.
Having all requests go to something with a .jsp at the end would not be a good match for what is going on when you have requests that need to go to different JSPs. Often the routing depends on various other information in the request or session, or something else in the event of a validation failure. Other requests should be responded to with some processing followed by a redirect; a JSP doesn't make sense for these cases, though you could use a servlet. Using the Servlet/Action abstraction consistently is nice in that someone writing the form that submits to your Servlet/Action doesn't have to wonder if they should be submitting to a JSP instead. The idea of an abstract end point is a useful one in many scenarios -- sending requests to JSPs through filters is missing this idea.
Perhaps the Filter class would be a useful base for some behavior that was implemented in another fashion in Struts or other frameworks. But I don't think we'll see the end of the Servlet class or perhaps even its Action counterpart in Struts. They are still quite useful, as chains still need and end point, and JSPs are not appropriate in some cases, and thus not appropriate generally.
-Max
maxcooper at 2007-7-2 22:37:21 >
> Is there any other popular J2ee framework easy to use?
This is a really good question. I think we must consider following points carefully before saying STRUTS is easier framework to use.
1. STRUTS is a java application. Java is already a slow language. Adding more and more higher level applications to basic java apps is going to make things slower.
2. Java's implementations of servlets already abstracts developers from lower level sockets. Learning STRUTS means you are more abstracted from servlet and jsp framework. This is going to take developers away from basic fundamentals of web-apps programming. Developers are going to become operators.
3. Since STRUTS adds no new technology to existing Servlets/JSP/JavaBeans architectire, its study is just wastage of brain in favour of time. Instead we should consider learning MVC paradigm and try to implement it in our apps imaginatively.
4. How many frameworks we developers have to study if third parties are going to come up with new ones like this? Aren't Servlets/JSP/JavaBeans fundamentals enough for efficient app development? This study is going to take developers away from basic framework and developing new technologies.
5. And above this all, if Sun thinks there is a real need to have a higher level container like Struts, it should come up with a specification so that it becomes standard framework and developers can concentrate on its standard implementation.(Why should Sun come up with?Sun can say we didn't tell you to use Struts!)
k_i_shor at 2007-7-2 22:37:21 >
>I would think like this only if I would have to build only one application during my whole carrier.
Not agree.
yahh you can use your framework in different applications during your whole career.
What are the APIs...create once and use it ..Same for your own framework.Create your own and use it for different applications you want.No need to use struts...just user JSP/Servlets..What extra you need to do is just modify your framework according to your requirments.
Struts is doing the same thing.somebody has developed this framework and made it available for rest of the world to use and modify for their rquirments.
The successfull framework it that which gives you best performance and
best solution to your application.Is anybody agree on this?
manishjoshi at 2007-7-2 22:37:21 >
Just to give you input from struts's users themselves, have a look to the thread i have posted some months ago concerning the design flaw of struts. http://www.mail-archive.com/strutsuser@jakarta.apache.org/msg59079.html
jose.nyimi@proximu at 2007-7-2 22:37:21 >
Dear Struts Users,
I have just bought this book : "Expert one-one-one J2EE Design and Development" by Rod
Johnson.
http://www.wrox.com/news/852.htm
I will greatly appreciate to have your opinion about this "so beeing design flaw of
Struts" described in the above book.
Rod Johnson suggested an alternative framework that takes strengths of following
frameworks : Struts, Maverick and WebWork, then offer solution to their weaknesses.
Codes are available at :
http://www.wrox.com/dynamic/books/download.aspx?isbn=1861007841#downloads
The Autor wrote the following :
" Despite of its popularity, I'm not a big fan of Struts.It's good enough, but far
from an ideal J2EE web application framework:
*The ActionForm approach - central to Struts request processing model - is
poor. Bean binding is primitive, meaning that only string properties are really
useful. This adds little value over simply querying request parameters.The idea of
copying properties from an action form to business command is inelegant and there is o
support for type checking.
*Struts is too JSP-oriented, although it is possible to use Struts with other
templating technologies.
*Struts is based almost entirely on concrete classes. This makes it hard to
customize Struts's behavior.
*Although things have improved significantly with version 1.1, the Struts
codebase is poor. Not surprisingly, there have been numerous deprecations in moving to
1.1.
*Struts ActionForms have several particularities that we must consider. As all
ActionForms must extend the Struts superclass, they all depend on Struts and the
Servlet API. This means that they can not be passed to business objects, as business
objects shouldn't depend on a particular web application framework or the Servlet API.
Secondly, any request parameters that may contain invalid data (such as numeric
inputs, for which the user might enter non-numeric data) must be matched by ActionForm
properties of type String. The bean manipulation code behind the scenes will attempt
to convert string request parameters to the appropriate type, but any exceptions in
attempting to set properties will result in the org.apache.struts.util.RequestUtils
class failing the request by throwing a ServletException.
*Thus a Struts ActionForm is not a true domain object. It's a place to hold
user data until it can be validated and transferred into domain objects such commands.
The advantage of this approach is that invalid data can be re-displayed easily. The
disavantage is that we will need to get this data into true domain object at some
point, so Struts has only taken us part of the way towards true data binding.
*The need to derive ApplicationForms from a single superclass has always seemed
to me a design flaw. Not only does it tie commands to the Struts framework and Servlet
API, it incorrectly exposes inherited framework properties to update via data binding
from request parameters. For example, adding a servlet parameter with a string value
will break just about any page generated by 1.0 application (with a failure to set a
property of ActionServlet to a string) . Struts 1.1 introduces a workaround for this
particular problem, but the root of the problem is the whole ActionForm concept.
*The ActionForm class also defines a validate() method. Subclasses may override
this method to valid the state of an action form after population from request
parameters. Struts also offers alternative approaches to validation.
*Struts 1.1 corrects many (but not all) of shortcomings of Struts 1.0, for
example by allowing the use of multiple controller servletin application.(The
mechanism for this isn't very elegant, however it's clear that it was an
afterthought). Other enhancement in Struts 1.1 include the introduction of the
org.apache.struts.actions.DispatchAction superclass, allowing several actions to be
performed by the same class. This is very useful in cases where many request types
call for simple handling; it avoids the proliferation of many trivial action classes.
Struts also introduces declative exception handling. "
Thanks a lot in advance for your inputs.
Jos.
jose.nyimi@proximu at 2007-7-2 22:37:21 >
I have been looking at struts and can say that obviously after reading this thread it has its followers and those who oppose it.
(I mean this thread has been going for over a year)
Anyway, after reading through the struts documentation, I decided not to use it. why? ironically, some of those points by that author posted above came to mind.
I am seeing both sides, but I am the type of person who likes to dig in and do stuff myself...
matmank at 2007-7-2 22:37:21 >
I wrote my own framework before Struts, and now I use struts. However, Ken, in spite of his screams for performance and urges to "learn the servlet spec", makes some very valid points. How is the MVC framework that Struts provides, different from the one that the servlet container provides?
I always tought of a servlet as the 'beginning' of my application so I saw a need for a framework like Struts. But if you think of the servlet container, as the 'beginning' of the application, the servlet becomes nothing more than an equivalent of a Struts Action class. ActionServlet does the same things the container does. It reads its configuration file and delegates processing to configured actions. The container reads its configuration file and delegates processing to configured servlets. If one thinks of a Servlet as an Action then everything seems redundant. The container is basically Struts minus some utility classes. interesting!
ranko at 2007-7-2 22:37:23 >
The more I think about this, the more its starting to bother me. For example, Struts now has sub-applications capabilities with multiple config files. Isn't that very similar to what the container does with multiple war files (web.xml config files)? In how many different ways is ActionForward different from a RequestDispatcher? With just a little extra classes and additions, the servlet spec would present an equivalent MVC framework to Struts.
For example, let Sun provide an implementation of a Filter that populates a form in the way Struts does so one does not have to write their own populate call. The filter can be configured in a particular servlet section of the web.xml just as the form is configured in a particular action section of the struts-config.xml file.
With several little changes like that and some standardization on how to handle certain repetative tasks, the servlet spec would offer the exact functionality Struts does.
Maybe its the fact that Servlet is called a Servlet and Action is an Action that makes one seem like more of an MVC framework than the other?
ranko at 2007-7-2 22:37:23 >
http://nagoya.apache.org/wiki/apachewiki.cgi?StrutsMoreAboutJSF
Aubbie at 2007-7-2 22:37:23 >
http://nagoya.apache.org/wiki/apachewiki.cgi?BenefitsOfStruts
I think Ken is missing the point. Thanks for pointing out the obvious that Struts is a layer on top of the Servlet API and you can do everything without Struts. I can program everything in Lisp if I really wanted to, who needs Java? ;)
If performance is your main goal and and you really need to squeeze out that extra few milliseconds, then by all means go ahead and roll your own framework. However, my feeling is that most companies would gladly accept the trade-off in their webapps with a standardized and time-tested framework that encapsulates the MVC patttern and promotes solid design principles as well as getting their products released in a consistent and timely manner.
Aubbie at 2007-7-2 22:37:23 >
I think what he is saying is that the servlet spec already provides the same time of MVC framework as Struts does. I don't think the point is that you can do it just by servlets (I mean you can code in assembley too), but that you can do it in exactely the same way.
ranko at 2007-7-2 22:37:23 >
So is using servlets/container as quick and easy as using Struts?It seems that the current servlet spec is...without the overhead of learning the Struts framework.Can anyone comment?
sysop at 2007-7-2 22:37:23 >
ranko2, that is exactly my point. As I've stated before, I can take the exact same code in the Action class, put it in a Servlet and I'm 95% complete. Populating my own form will take a few extra keystrokes, but it does eliminate the cost of reflection for each and every request. Associating URLs, which are read from an <init-param> tag, during the Servlet's init() method will take a few extra keystrokes, but it is more efficient that looking up the same values over and over again in a HashMap (ActionMappings).
Some may argue that the difference is just milliseconds. One can also argue that the cost is a little higher, and that that cost over thousands of request per hour quickly add up. If you where in school and handed in something that was a few minutes faster to code but took this hit at runtime, do you not think you would get a C+ instead of an A? STRUTS works, but in my opinion you are only putting out a average job.
If an API or Framework comes along that provides new functionality, better performance or a better way of doing things (or any combination) without descreasing runtime performance, I will of course be ready to switch from the current standard. In my opinion, STRUTS offers very little new functionality, lowers performance and does things basically the same way. Personally I see zero reason to switch.
ken_robinson at 2007-7-2 22:37:23 >
syspo9, I believe the servlet spec is very easily to learn and provides the same funcationality as STRUTS. I learned the servlet spec well before STRUTS was available, so I am of course going to favor the servlet spec.
In my opinion, they do basically the same thing. I suggest you do a quick evaluation of both (find a few basic examples) and see which you prefer. Just remember, if you see something that one has and the other does not, be sure to ask how it works and what is it's cost.
ken_robinson at 2007-7-2 22:37:23 >