This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I really don't want to start flames, but I am confused.
I've been writing professional Java web applications for ten years. Starting with hand coded servlets and scriptlets embedded in hand written HTML pages.
Before that, I wrote professional Smalltalk code, Visual C++, and other stuff. So I know what a MVC pattern is, but I don't grok how it applied to Java web applications.
As time goes on, better tools have come along, but I've always stayed with servlets and POJO beans, just now they are talking to JSP and using EL.
I tried using J2EE, and even got paid for it a while, and hated it. Too complex. I believe in the "Better, Faster, Lighter Java" from Bruce Tate and Justin Gehtland.
I've just switched to Netbeans 6.1 (years of 5.x use) and it wants to use Struts or Faces, or other frameworks. And I see our own Bear has "Front Man" which implements a lightweight "Front Controller" model, whatever that is.
I looked at Struts, and it seems to be a lot of stuff just to implement a Finite State Machine.
I don't even know the terminology, I can't tell if these "frameworks" will make my life easier or not.
Originally posted by Bear Bibeault: if you want simple, check out my Front Man "framework". It's just a front controller that takes care of command dispatching and stays out of your way for everything else.
I have, and I referenced it in my original post. But saying it "implements Front Controller", as the documentation says, doesn't help much. How do I know I want a Front Controller, whatever it is?
As I wrote, I've been doing servlets for ten years. I know lots of folks use various flavors of frameworks. But I don't understand why I would want any. What do they do? Why are they good? How do I pick one?
The world clearly runs from my hand written servlets and JSP pages up to full blown J2EE. How does one make rational decisions on what to use?
If you don't have that problem, a framework may not help you.
But the detail is that you may be doing something and not consider it a problem, yet if you had used a framework that made that thing simpler, when you went back to try the task without the framework, you find it more tedious, or error prone, or whatever. Now you look at that task and see "it's a problem".
For example, the classic argument against Garbage Collection. "Why would I ever need garbage collection, I've mastered malloc/free/sbrk/etc., etc.". And then you code with GC and "see the light".
For me, specifically regarding a web application, I went bumbling around looking at some, notably Struts, but decided that after seeing the pain in setting it up, that I didn't really understand "the problem" is was trying to solve. So, I wrote my first app in pure Servlets/JSP.
It basically worked, as you'd expect. But I wasn't happy with it.
When I had to do another application, I decided to try again, and again I went with Struts (had a book and everything). And it was allright until I reached a particular sticking point. In this case, it was dealing with indexed property binding.
Struts failed at that point completely. Effectively, I could use Struts and its mechanics for some chunk of my app, but for this area, Struts simply didn't exist -- it offered NO value.
See, at this point I knew what I wanted to do. I knew I could code it up if I wanted to, but I also knew that someone, somewhere, had solved this particular problem. I just had to find it.
This is a particularly black hole to be in, because as you're flailing around the net try to find the magic bullet, you're burning time -- time which could have been used to "just code it".
But on the other side of the coin, from my Servlet experience, I knew that doing it "from scratch" just wasn't what I wanted to do. Nothing draws a crowd like a crowd, and the Web App Framework "market" was crowded.
People weren't making these things to waste time, but to solve the mundane issues that you encounter when doing web applications. Servlets are functional and usable, but the frameworks were solving real issues, not just being make work projects by folks with nothing better to do.
So, the game was to find the right framework for me. Obviously, in my case, at the time, Struts wasn't it.
My wife rejoices the day I finally stumbled on to Stripes, because I was in a sour and surly mood for a week beating my head against the wall trying all these frameworks.
For my case, the Stripes Framework offers 2 major advantages over stock Servlets for Web App development.
1) Stripes Action Beans are thread safe. Each request gets its own Action Bean compared to a stock Servlet, which is shared across requests. 2) Stripes binding. The Stripes binding model is the best I've seen. It's simply fabulous. I can't imagine doing a Web App of any magnitude without something like the Stripes binding and data conversion features.
It's got other things, but those are the "Killer Apps" of Stripes.
The first one is easy enough to roll your own, and many do. But it's still a great feature. Struts 1, for example, followed the original Servlet model of one Action per server -- which is just crazy to work with, frankly.
The second, tho, the binding, is just a plain ol lot of work to do, and I'm glad I'm not the one who did it.
For a web app framework, those are the two things the Stripes brings to the table for me. You may have different pain points and some other framework (or none at all) may suit you.
It's impossible to rate a framework in a vacuum. You need to have a problem you're solving, otherwise you can't judge whether the framework is actually a benefit for you, or simply another way of doing the same thing. At the same time, your use case needs to be complicated enough to really stress the framework. Otherwise you may just get a one trick pony.
That may be all you need, but it's nice to have something reasonably robust that solves a lot of the common issues.
Note, I know it's "pimp Stripes week", but the guidelines apply to any framework. The 3 "hot spaces" on the server for frameworks are the Web/Presentation space, the Logic/Transaction space (Spring, JEE, etc.), and ORMs and other tools for databases (JPA, Hibernate, iBatis).
I threw out Struts for my task because it offered me nothing, and Stripes was able to pick up the ball. Stripes does a LOT of stuff that I DON'T use, but for the stuff I do, I'm grateful that it exists.
If using a framework is valuable, I'll use one. If its just a bunch of theoretical benefits (which is what I think of the full J2EE stuff is) than I'll keep doing it the old way.
Comparing one framework to another doesn't help, it assumes that you start with a framework. Why do I want one?
Or, perhaps the frame work that I have used for a decade is "none" and Bear says his Frontman is not much more than none.
But I lack the understanding of what they claim to do to ask smarter questions.
What do you say we drop the theory here and I'll give you a very concrete example. Now, you say you have been writing Servlets and JSPs for several years, and so you may have over that time built up your own library of reusable utilities and so on. So, if your answer to the example below is "yeah, I already have code to do all that", then what you've done is, in a sense, built your own framework
Instead, imagine you are starting a brand new web application from scratch, using only Servlets and JSPs. Here is the task:
Write a simple HTML form with a Name (String) field and an Age (Integer) field. Both fields are required, and the Name must be between 2 and 20 characters. The age must be at least 18.
When the user submits the form, you must validate the input, converting the Age field to an Integer in the process. If the input is not valid, you redisplay the form, prepopulated with the user's input, and showing error messages.
If the form passes validation, you do something with the data (save it to a database, etc.) and send the user to a confirmation page.
This is not terribly difficult, but it does involve a considerable amount of legwork because you're using only the Servlet API.
Here's how you could do it with the Stripes framework:
That's about it. Stripes automatically maps the input fields to the properties of the Java class by the name= attribute, and calls the method with the same name as the name= attribute in the submit button. But first, Stripes takes care of validating the data according to your @Validate annotations, and also converts the String to an Integer. If the input is not valid, Stripes automatically goes back to the form and displays error messages at the <stripes:errors/> tag, and also automatically repopulates the input fields with the user input.
Now, I don't know about you, but I think that is quite nice. I'd much rather use short, simple code like that and let Stripes take care of all the plumbing for me, rather than do it myself with the Servlet API.
That is just a quick example which hopefully gives you an idea of what the Stripes framework can do for you. Believe me, it can do a whole lot more for you too
Alright, so allow me to show you one benefit. Let's consider a standard login form in Servlets and JSPs. You'll have to forgive the possible errors in the pure servlet class as I am doing this free hand. ;)
Whew! I'm already tired just from writing the servlet. And I didn't even cover everything like a whole slew of other validations like lengths for username and password, I didn't deal with an empty password. So let's see the same thing in Stripes.
Not only is the code a lot more concise and cleaner but the Stripes version actually handles a lot more than the servlet with the nearly the same amount of code.
Now you might be saying to yourself "But I've implemented libraries and utility classes that make it easier than your servlet example". To that I'd say if true, then you already know the value of a framework because you've in some way created one.
Oh, one more thing to note. Mine and Freddy's stripes examples didn't have to touch a single configuration file for it to work. The web.xml is setup with the Stripes filter once and that's it. Just "set it and forget it".
I'm all for code reuse, I've been writing code for 35 years, and I'm plenty lazy. But its got to be usable when reused.
There is more to life than a login bean. Specifically each and every JSP has to check that the user is logged in, and if so, continue, and if not, dispatch the the login.jsp/bean.
Typically, that can just be a jsp fragment in the WEB-INF, but you gotta have it.
Where does the
come from? who defines it, How is it bound to the application?
Does the framework help with boring but important things, like i18n? or displaying properly on all known browsers? and on iPhones and other cell phones? Does it make AJAX less painful? Or at least make it easier to separate business logic from the UI?
Originally posted by Bear Bibeaultid you read the article?
Just finished it. And I totally agree that I hate all the code I wrote nine months ago. Which is why I'm asking this question, hoping to write less bad code.
mostly OT: Writing idempotent web apps is something that I've been doing since 1996 when I joined CyberCash. Its important when moving money to not do it twice when the user reposts.
Making the refresh and back buttons on the browser have been a bain of my life for more than a decade.
Joined: May 22, 2008
Gregg and I just posted a simple example to give you an idea. Of course Stripes does many, many more things for you. To check if the user is logged in, you'd write an interceptor. That's just a piece of Java code, and Stripes automatically calls it on every request. Interceptors are more powerful than Servlet Filters, because you can have them be executed at different lifecycle stages. Also, you don't need to go do configuration in web.xml every time you add an interceptor, or another of the many modules that Stripes gives you to customize your application.
Type conversion, formatting, i18n....of course! I invite you to look at the Stripes book's table of contents to give you a list of the features that Stripes provides:
Sorry to jump in to a discussion, but the question is too generic and the answer too simple. So, I want to give my 2 cents:
The answer is, unless you learn them and understand to use them right, you won't know what they are solving. Once you learn it, you will see your mind expanding and what you would have solved a certain way, you will find ways to solve them better.
I would say, give stripes a shot. It won't take you more than 2 days to get hang of it. You will see your mindset changing.
It won't be a waste of time even if you decide to not use it. Your appetite for newer solutions will grow.
I'd also agree that there is nothing like getting your hands a little dirty to really see if there is a benefit for you. I've tested and played around with nearly every java webapp framework out there. It's the only way to really know which one fits your development style the best.
Originally posted by M Rama: the question is too generic and the answer too simple.
An example is not an answer. So far, I'm not getting answers that I can use.
The answer is, unless you learn them and understand to use them right, you won't know what they are solving.[/QB]
I'm sorry, this make zero sense to me. All learning has to be motivated. I want to know what problem frameworks solve, *before* I take the time to learn one. Bear's paper describes some problems.
I know how to do things, been doing it for over a decade. The default position is to do what I know. So why is it worth the time and effort to learn to use?
I've been in the business too long to believe marketing stuff, every language is the Silver Bullet (tm Fred Brooks) that will make programming enterprise systems easy. So far, none have met the hype, with J2EE probably being the worst miss.
Typically, when you try to sell a tool, you say "This automatic hammer is 10 times faster than a manual one, so when you need to nail 1000 nails, its a winner" but they don't say that it costs $500 instead of the $10 that a manual hammer costs, and they don't say that it takes a half hour to setup before you set the first nail, so a manual hammer is tons faster and cheaper to pound four nails. The power hammer is only a big win when you need to pound in 1000.
I know that my manual way is a pain when you need to make 40 JSP pages, which is what real applications need. So if the first three pages are painful, but the next 37 are easy, that's a benefit that I can understand.
Pat, part of the problem by generically saying "Frameworks solve XYZ" is because some frameworks make claims that they don't live up to. So it is difficult to give you cut and dry answers to what problems frameworks solve.
That is why I suggested trying out one or two frameworks. I don't know what your problems are therefore I can't begin to guess how to best solve them. And I don't know of any dissertation that might answer your questions for you. I can give you a list of reasons I like Stripes when it comes to solving the problems I have with straight servlets/jsps:
complex property binding and type converting - No need to manually pull values out of the request, attempt to convert them to their correct type from a String, and shove them into value objects/POJOs/JavaBeans. Stripes handles all that for you transparently
Validation - With some simple annotations on the action bean forms van be validated and error messages displayed back to the user with minimal effort. This goes hand in hand with my first point because stripes handles type conversion errors as well
Layout - No need to build up jsp:includes and such. A couple of simple tags allow for a very robust and dynamic layour mechanism
handling multiple submit buttons/events - submit button names match up to method names and those methods are automatically called by Stripes to execute. Example might be a single ActionBean with methods add/edit/delete. No need to inspect request values to determine which action to handle. Just create a method and name the button. Done.
Just enough above the servlet API level that you don't have to worry about it if you don't want to. Just above the servlet API level that you can access it directly if you want to.
Simple taglib - Using some very simple tags in your JSP forms automatically repopulate when errors occur or pages need to be displayed for edit purposes. This reduces a lot of needless request handling and value checking on the pages
That is what I have in my head right now. I'm sure there are many more good reasons. Plus, there are a lot of features of Stripes that go beyond your reason for this thread.
Pat, lets use your hammer analogy. You've learned how to use your hammer over the years. It took a while but now you can even hammer a screw in with it too. It's not particularly easy and the screw may not be as reliable as it could be but you can do it.
The Stripes tool is not just a hammer but it has a screwdriver, drill, and rivet gun built into it. It is much easier to use because it automatically selects the correct attachment based on the type of fastener. It also determines if the fastener is defective for you (validation). How many times have you pounded your thumb with that old hammer? Stripes holds the fastener while attaching it so you'll pound your thumb less often.
One of the best features is the ability it gives you to easily add your own chainsaw, fire hose, or whatever else you can imagine without making it unwieldy. These new implements will act exactly like they were part of original features.
So now, after hearing all of the great features how much would you pay for Stripes? $100? $500? $1,000? NO! ;-) Right now you can put this new tool to work for you by following these steps:
Copy stripes.jar file into /WEB-INF/lib and make sure you have commons-logging.jar and log4j.jar in there too.
Copy some lines into your web.xml file and edit one of the lines.
Copy StripesResources.properties into /WEB-INF/classes. If you don't already have commons-logging.properties and log4j.properties you should copy them too.
Write your first ActionBean!
Sure it will take you maybe an hour to learn to operate it properly but the hour you spend learning it will pay for itself in increased productivity in the first few hours. [ November 21, 2008: Message edited by: Aaron Porter ]
Originally posted by Aaron Porter: You've learned how to use your hammer over the years. It took a while but now you can even hammer a screw in with it too.
Ha, I know how to dig iron ore out, smelt it down and pour it into a hammer shape. Then I can hammer stuff. Works great on nails, OK on screws, not so well on turkeys.
Joined: Feb 26, 2007
I used to make my own hammers too but when they started giving out free ones that not only looked better but also worked much better than mine ever did I decided it wasn't worth it to make my own anymore.
For what it's worth, Stripes is the first web app framework I've come across that I like since starting servlet programming in '97. [ November 21, 2008: Message edited by: Aaron Porter ]
IMO, why invent the wheel again? Something is already there which is stable, proven and tested & validated by a team of dedicated professionals on-behalf of others. Spending time in developing the same or similar kind of stuff, instead of focusing on the business logic part for your project, is worthless. Others view may differ sorry about that. If you are really really interested in building such a best framework which will give better facilities, features and compact when compare to other available frameworks including Stripes, please come up with your ideas. Let's build a team of self interested professional and let's start developing a new framework. Which will surely help others something like Struts, Stripes, .....etc... again.... which may be worth for your time.... however, someone else may ask the same question again... and the wheel will roll....
Originally posted by Mourouganandame Arunachalam: IMO, why invent the wheel again? Something is already there which is stable, proven and tested & validated by a team of dedicated professionals on-behalf of others.
You are coming in late, but you are missing a big part of this. There are lots of "wheels" that folks claim are Silver Bullets, And a lot of them are no better than my hand wrought hammers. And I know my hand wrought hammers.
I looked at Enterprise Java Beans and J2EE and hated it. There is a book describing why others hate it as well: Better, Faster, Lighter Java as mentioned upthread.
Originally posted by Pat Farrell: I looked at Enterprise Java Beans and J2EE and hated it. There is a book describing why others hate it as well: Better, Faster, Lighter Java as mentioned upthread.
You do realize that the EJBs and j2ee you hate everyone has already given up on. First, there is a new EJB spec that is actually not bad since it is more or less Hibernate with session beans. But you don't even need that. Everything is POJO based these days. In fact, I can't think of a single framework that requires EJBs to be used. Not even the new spec. Seam comes closest but you can use POJO based persistence with JPA/Hibernate if you want.
You've been scarred. We get it. Everyone else has moved on. You should too. We've been trying to help you with essay long posts and all you keep saying is that we aren't helping. How about a little gratitude for at least trying? [ November 21, 2008: Message edited by: Gregg Bolinger ]
I'm past the easy stuff. This has to scale, be professionally pretty, etc. Perhaps I'm asking for too much.
Originally posted by Gregg Bolinger: You do realize that the EJBs and j2ee you hate everyone has already given up on.
No, I did not know that, and the Ranch still have a J2EE section. I get calls from headhunters, at least one a month, offering me big jobs using J2Ee and EJBs and wanting experience. And I just run away.
We've been trying to help you with essay long posts and all you keep saying is that we aren't helping. How about a little gratitude for at least trying?
You, Greg, wrote a four or five sentences with real reasons, and I appreciate it. But no one answered my question on where the magic
comes from, or whether a framework handles the login/redirect stuff.
And @Will Hartung wrote some paragraphs. Nice stuff including
Struts failed at that point completely.
So I've seen other stuff fail completely.
I see from reading the Stripes book fragments that it uses DAO classes. Not enough is in the book to see if I have to use DAO classes. I've been writing what is now called ORM mapping layers for 20 years, and so far, I haven't found a DOA that saves any time. Hibernate looks close, as it aims low and is light.
The suggestion of "try implementing sample code in three or four frameworks" doesn't address what problems the designers of said frameworks are trying to solve. Let alone provide any guidance as to which ones to randomly start with in the investigation.
If you code to buzz then sure, but really, not everything has to be AJAX.
There are two options here.
No, I did not know that, and the Ranch still have a J2EE section.
True, but J2EE really means different things now. Generally it is about EJB3.0, JMS, etc. Some folks still ask questions about EJB1.x/2.x because they are supporting existing applications.
I get calls from headhunters, at least one a month, offering me big jobs using J2Ee and EJBs and wanting experience. And I just run away.
Me too. So do most people. Thats why those jobs are available.
But no one answered my question on where the magic....comes from
It was just an example. It wasn't meant to be relavent to the sample code I was showing. I was mearly demonstrating that a Login Service was being used to do the authentication versus having it directly in the controller, which is standard best practice these days.
or whether a framework handles the login/redirect stuff.
I don't know an MVC framework that handles this without some manual coding either within the framework itself via a plugin or configuring the container to handle it. This is generally something that needs to be fairly customized per project, in my experience. Different clients want different things to happen when it comes to logins and redirects.
I see from reading the Stripes book fragments that it uses DAO classes. Not enough is in the book to see if I have to use DAO classes
Why would you have to do anything? Stripes is MVC. It doesn't force you into any particular pattern when it comes to the data layer. The DAO pattern is a industry standard practice so Freddy took some time to show how to integrate a mock DAO layer with Stripes. You can do it the same way, completely different, or not at all. Stripes will let you put JDBC code directly in your Action Beans if you want, though I strongly discourage it.
I've been writing what is now called ORM mapping layers for 20 years, and so far, I haven't found a DOA that saves any time. Hibernate looks close, as it aims low and is light.
Woudn't it be nice to be able to stop writing ORM mapping layers? Well, you can. there are several. Hibernate (JPA), iBatis, JPersist, Warp-persist, and many others. Google is your friend here. Stripes doesn't force you into any particular choice. In fact, Grails is the only framework I am aware of the ties you directly to hibernate. Struts, Wicket, SpringMVC, etc....they don't care.
And a DAO isn't always about saving time. It's about using a pattern and keeping your data layer decoupled from your MVC layer.
Let alone provide any guidance as to which ones to randomly start with in the investigation.
Well, I'm a big fan of Stripes. I'd suggest you start there. Look, I'm going to say this again so take it for what it is worth. We've been trying our best to explain what issues frameworks try and solve. If you aren't having the issues we are saying are solved then this whole thread is pointless I suppose.
Maybe it would help if you gave us a point by point post on what problems you would like to see a framework solve and we can tell you if any particular frameworks solves any or all of those points.
If we say Stripes solves the problem with validating and converting request parameters for you and you say that isn't the problem your having then you are probably having problems that we just don't know about or that we don't consider problems. That's not to say they are valid issues for you. We just aren't getting it. And I don't think you are getting us.
Originally posted by Gregg Bolinger:If you code to buzz then sure, but really, not everything has to be AJAX.
My code has to buzz, scale, etc. I start dot.coms and we need buzz to get funding. Well, maybe "need" is too strong, but it sure helps, And as importantly, the whole Rich Internet Application thing is more than a buzzword. It reflects a much better, richer user experience that is accessible to the mass market.
The world of startups no longer can restrict itself to geeks and folks smart enough to hang around JavaRanch and DevShed.
The users, and the Product Managers, don't care at all about technology. They care about the experience. The web forms that you POST to back in 1996 don't cut it anymore. Doing validation server-side is just not good enough.
Working on IE and Netscape is not good enough, even though Netscape is now spelled FireFox. It has to work on crackberries and iPhone and what we call personal computers.
I also have questions on whether I should build in Java or use Ruby or Python or Scala or ... but those discussions too quickly become theological. I'm an engineer. An old, gray haired engineer. A small system that I build typically has 100,000 lines of code, uses 50 or 100 database tables, and must be designed for a million simultaneous users.
Like Bear said, the code I wrote nine months ago needs to be better. And it has to be 16 times better than the large scale Java code I wrote in 1996, since 2008-1995 == 12 years == 144 months, and 144/9 = 16
or whether a framework handles the login/redirect stuff.
Originally posted by Gregg Bolinger: I don't know an MVC framework that handles this without some manual coding either within the framework itself via a plugin or configuring the container to handle it. This is generally something that needs to be fairly customized per project, in my experience. Different clients want different things to happen when it comes to logins and redirects.
Well, This is one of the things that I've implemented zillions of times. At a high level, you have a FSM that starts at the "unloggedin" state, and has a small number of pages/jsp that you can visit without logging in. If you want to do something cool, you have to go to login.jsp, and all the cool pages validate that you have a legal session or dispatch back to login.jsp. There are a bunch of states, aka pages, that you can visit in the "logged in" state, and perhaps there are additional states in the FSM that control things like levels of privilege.
While nearly all web-applications let you specify the login page and some levels of privilege, they never seem to map to what the PHB wants, its a wheel that I'm tried of remaking with my hammer.
[ November 22, 2008: Message edited by: Pat Farrell ] [ November 22, 2008: Message edited by: Pat Farrell ]
I know one of the things i'm struggling with in terms of what framework to use when, where, etc is I cant seem to find where someone has done a comprehensive side-by-side comparison of any two or three like frameworks, and show strengths/weaknesses per each, depending on some criteria. Is there anything like this out there for Struts vs JSF vs etc?
Joined: Nov 19, 2008
Pat, it comes down to this.
If you've been writing code for ages, and you've ever said "There has to be a better way to do this", and you haven't made your own "better way", then you might want to look at a framework using your use case.
If you have been doing similar work using the core Servlets platform for any length of time, you have most likely managed to develop "your own framework". Perhaps it is better than the devils you don't know out there in the world of frameworks, in terms of elegance, etc. Perhaps it's worse, but it's "good enough", and the intimate knowledge you (and ideally your team) have of your internal library of utilities more than compensates for anything that a new framework may offer simply in terms of risk and speed of development for you and your team.
Simply put, the reason to not use a third party framework is 'You don't know it, don't have time to learn it, and can't risk falling in to a black hole of uncertainty because of it".
No framework can address that. If that's the concern, then you should sign off with "Thanks for the conversation" and go on your merry way. No harm, no foul.
All we can say is that in our experience, and some us have pretty good experience in this domain, for some time, we have found that the frameworks (in our case, Stripes) have been a Net Win overall. And I've been bitten by black holes, unknown surprises, etc. But none of them have convinced me that the choice was wrong. Rather, we simply fixed the issue and moved on.
As I've said before, I think anyone new to the Java Servlet platform should write a non-trivial application in pure JSP and Servlets. Pure JSP and Servlets can go quite far with even the most minor amount of tweaking (like pounding out a quick Front Controller so you don't have to use raw Servlets everytime -- hardly rocket surgery).
But it seems to me that after you've endured that experience, you should have enough experience to make a sound decision to use one of the several dominant frameworks available. The time spent on that research and adoption will be minor, long term, to carving that wheel out of stone again.
In your case, you may well have already solved the problem. You've already got util functions, idioms, and tooling to make writing an application easier than using raw servlets. I can't advocate that anyone switch out a mature, working infrastructure for "something new". That's crazy.
That said, tho, I think that it would still be worthwhile for you, if you have time, to explore some of these frameworks. If nothing else, you may learn something that you may well want to apply and incorporate in to your current code base.
JPA is a classic example of that. JPA/Hibernate/ORMs in general have swept the Java world by storm, and for good reason. They're really nice, and they really work. They have problems, they're imperfect, and they introduce a large layer of "dark matter" in to your system that only hands on experience can decipher. But, in the end, for us, JPA has been a net win, and it's hard to imagine doing persistence any other way unless absolutely necessary. In the end, it's another tool in the tool box, but it's also the first tool we reach for today.
We're constantly looking at the new things available and try to take advantage of opportunities to try them out in anger on a real project. We take advantage of our long experience in knowing what we already know, and being comfortable that as we move down the path trying something new, we always have a backup plan should something go awry. With reasonable modularity, layering and testing practices, yanking out a new technology to replace it when it "goes bad" with an old technology is rarely a big issue. If it was a big issue, we wouldn't have done it at all to begin with.
Sounds to me you're happy with your code and your practices. If you have time, look at some new stuff if for no other reason than to get an alternate point of view of the problem, otherwise, no big deal.
I use Stripes on my own projects, and at work. I use, probably, 20% of the platform. I'm a big fan of its binding model, that's the Silver Bullet for me as it eliminates so much boiler plate garbage from my code. The other Stripes guys use far far more of the framework than I do. I'm the luddite of the Stripes community.
That said, I find it invaluable. I can't really fathom writing a system that responds to HTTP requests using anything else. To anyone reading this thread, if you need to respond to an HTTP request (whether that response is a forward, redirect, or streaming PDF, XML, or JSON), there isn't anything better, faster or easier than Stripes for the 95% use case. It's painless to use, and painless to incorporate, and Solves The Problem elegantly and efficiently.
If you like the Servlet model of web development, Stripes is the best evolution of that model available.
I've grabbed assorted changes to the web.xml and index.jsp as described in the Stripes Quick Start Guide. But I guess I clobbered more than I should have and don't see any credible breadcrumbs to help find what is broken.
I've grabbed assorted changes to the web.xml and index.jsp as described in the Stripes Quick Start Guide. But I guess I clobbered more than I should have and don't see any credible breadcrumbs to help find what is broken.
Now would be a good time to take this conversation into its own thread or to the Stripes Mailing List since it is about a more specific problem and a bit off topic. Since you are trying out the quick start it would be a good idea to show us the web.xml and possibly your first ActionBean. I have a feeling I know what it is but please start a new thread with this topic.