As a java web applications developer I have used this last year JSF (SUN) for a framework to my web applications. I have to say I quite liked using it, it makes the developing easier.
Recently, I have read a lot of good things about JBoss Seam, but I still haven't encountered a person that has used it. From what I have read it seems that SEAM is the next step of JSF.
My question is therefore, for you that have used SEAM: while you where working with this technology did you encounter any disadvantages? Would you say it felt natural for you working with it?
The advantage of any framework like SEAM or Grails is that it's a higher level of abstraction. It takes care of underlying details for you and, if it's designed and written well, makes things easier.
The disadvantage of any framework like SEAM or Grails is that it hides a lot of details from you. If you don't ever learn what's going on underneath you can find yourself in a world of trouble if you get stuck and don't know anything about the code that's generated for you.
Another disadvantage is that the assumptions they build into the model might not always be what you want. But changing them means breaking the path that they've laid down for you, which isn't easy.
My advice would be to use the framework and appreciate the advantages it brings, but don't use them as an excuse to stop learning what's happening underneath. Be the person who could write the whole thing by hand, without the framework, but chooses to use it for the leverage it provides.
I have used Seam in an ongoing largish project with IceFaces. Seam certainly is far better than using plain JSF (refer the link posted by Damo a couple of answers above).
However, some of the issues I remember:
unit testing: getting SeamTest to work properly especially in a continuous integration build was hard, search the web for "SeamTest issues". Also see this: Has anyone successfully run integration tests with Jboss embedded, Seam and Maven?
Multiple ways for developers to do things and not too many best practices documented. So you have to spend time and figure out what is best for your project team. For example, when implementing forms, here are the potential tags (note that some of them overlap):
Facelets <ui:repeat>
JSTL <c:forEach>
JSF <h:form>
ICEFaces <ice:selectOneMenu>
JSF <f:selectitems>
Seam <s:button>
performance is suspect, especially with IceFaces, here is a related article Also, you need "guru level" knowledge of Seam in order to do the Right Thing, the default way lands you in trouble. See this article for details: Speed up your Data-Driven JSF/Seam Application by Two Orders of Magnitude - Part 1
since Seam 3 is imminent, and supposed to make use of 2 new specs (JSF 2 and WebBeans) that leaves questions on what happens to projects on Seam 2 and how long it will take for things to get stable
learning curve. IMHO seam tries to do too much, give you wrappers over things like iText, Quartz, JExcel, jBPM, etc. And the Seam integration with third party frameworks is expectedly a step behind the latest versions. For example we had to integrate jBPM directly because we needed some of the latest features.
maybe because of the lack of criteria queries in JPA 1.X, the way you implement dynamic search screens (where user fills in a lot of filter options and you have to generate dynamic HQL) felt very in-elegant, and this is when using the recommended "Seam Application Framework" EntityQuery class, see the link below for a simple example, but you can get an idea of what to expect for complex filter criteria, handling nulls, order-by and all: How can I to order an EntityQuery query in a seam app?
It's not correct to say the "Seam is the next step of JSF." Seam doesn't have to use JSF as the view layer. It can also use Wicket or GWT.
However when used with JSF it does a great job of simplifying it. You have less XML config than standard JSF and I often forget that JSF doesn't have things like a conversation context or parameterized method calls in EL. eg:
<h:commandButton action="#{myBean.sayHello('damo')}" value="hello"/>
It's easy to work with and the ability to use POJOs everywhere is very liberating. It's biggest disadvantages are those related to JSF:
Too much reliance on HTTP POST (which
s:button/link doesn't always solve)
Lots of javascript
Excessive calls to Getters/Setters
Nasty looking HTML; etc
There are more than enough pages detailing the shortcomings of JSF elsewhere (note that these aren't criticisms of Seam - rather of JSF1.x and many are resolved in JSF2.0)
I don't believe that Seam is the "next step" for JSF but it and Facelets are crucial if you're planning to use JSF1.x right now.
I think that JSF2.0 and WebBeans are the next step.
If you put logger on your Seam component (Eg. resultList) you will see that Seam calls the same method many times.
This is the only annoying thins about Seam. But Seam definitely "fixed" JSF which is pretty messed up by itself.
Lets see JSF2.
Regardless those problems, I am very happy to use Seam.
Seam, as a integration framework, really will show its usefulness when paired with other frameworks that you want to use.
If you're going to be using EJB and JSF already, SEAM is killer.
If you're going to be using JSF (plus any of its related tools, like IceFaces or RichFaces) SEAM POJOs can simplify your setup a lot as well as give you access to the life-cycle states that seam provides (conversation, etc.)
If you're using EJB with Wicket or GWT, Seam might be able to save you some configuration as well, though, I've not personally used it in this configuration.
As has been said, Seam's disadvantages are inherent in any abstraction framework: It's hiding the details from you. If it starts to leak, you're in trouble. I've not had it leak on me yet but I also spent the time to give myself a good, basic understanding of how it works. How the EL works with the Seam Annotations and such.
Whether or not you're going to find seam useful depends on the frameworks you're going to use it with. Seam definitely has its sweet spot but that spot is growing. Seam definitely isn't a dead project. :)
It feels natural to me and using annotations make life easier. I can't even imagine working with getAttribute/getParameter framework. One disadvantage is that seam-gen doesn't work with Maven yet (but Seam3 will be Maven based). I think Seam makes you focus on what you want to achieve and with other frameworks you have to think how to do it. Have you ever tried to do Ajax with javascript/prototype/jquery? It's really painful compared to seam Ajax button with method call and what to reRender. Javascript is really not needed at all with seam and Rich Faces. for me it's the best framework I've used.
I like JSF and I evaluated Seam not long ago. JSF is a web UI framework, whereas Seam is a more general web application framework, that integrates not just JSF but conversational contexts, workflow (jBPM) and object persistance (preferably EJB3). I was first attracted to Seam by the advertised auto-generated scaffolding, but I never did get it to work with my enterprise data model. Since then I've grown more interested in Spring Framework and Spring JSF. It appeals to me as being more modular and if you use iBATIS it needs only a servlet container like Tomcat, not a Java EE container like JBoss. Spring has been around longer and has greater mindshare.
Also ICEfaces is great with JSF and facelets, it works perfectly well with or without an application framework like Seam or Spring.
You can always use the Factory annotation to avoid calls to the same method over and over. Factory allows the component to be updated.
Related
I want to make discussion form kind of website using java, should i just make it using JSP- Servlet - Java code or should i use some framework like struts ...
I am new to Java, but i have sufficient exposure of programming
Depends what you're trying to achieve.
As far as frameworks go I would recommend checking out Spring over Struts (Although they can be used together, Spring has an equivalent Spring-MVC).
But Spring might be a bit involved for a Java newbie, even if you do have other language experience. Maybe experiment with JSPs/servlet first and check out Spring once you're comfortable with them (I recommend Spring in Action for reading material)
... Also, if we're talking a bit more outside the box (I see someone else mentioned Scala/Lift), another alternative would be Groovy on Grails. This is based on Spring, and owned by SpringSource, but is much more fun/quick to develop with. Plus if your previous experience happens to be with dynamic langs such as Python/Ruby, Groovy would be worth checking out.
You can try Play framework too. I have watched their demo and it's programming model looks promising to me.
If you're going to use Struts then make sure to use Struts 2. I would not recommend anyone write a new app in Struts 1 as it is very verbose and requires lots of configuration. However, Struts 2 is pretty awesome. I wrote a tutorial on it if that's the route you'd like to go.
You should have a basic understanding of servlet API, but you will most probably prefer to use some web framework built upon it. Struts is just one of them, popular and simple though a little old; there are many others
To name some: Struts, Spring-MVC, Stripes, Struts2, Wicket, JSF, Tapestry, GWT... an many others.
(Struts2 is not a new version of Struts, it's rather a new version of Webworks).
Unfortunately none of them is a clear winner.
You might consider Scala with Lift. I am building my next site in this and it is a very promising, light weight, less verbose, Java language.
You WILL need to understand servlets and what you can do with them regardless what, as all modern Java-based web platforms build on top of that.
The Sun tutorial for servlets is at http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/Servlets.html
If you're asking whether to use a framework at all or just use plain JSP-Servlet-Java I'd say that as long as you have a grasp of the language and Servlet API as other have said, the extra effort to learn a framework on top of that is well worth it in the long run. If you don't use a framework you eventually find that either a lot of your code becomes tedious, repetitive 'plumbing' or that you've essentially created your own framework anyway. Creating frameworks can be fun but if you have a job to do with a deadline, using an existing one saves a huge amount of time and effort.
I am investigating the use of web frameworks with my Java web-app. My basic requirements are pretty much easy maintainability, testability and no repetition.
I have explored writing my own MVC-type app using some sort of front controller pattern and JSP's for the views. The benefit of this is that I have complete control of all aspects of my web-app and if I design it properly it should not be hard to move it over to a more tested framework in the future if I so choose. However, the con is that I have to reinvent the wheel so to speak.
I hear good things about the currently available web frameworks. Some technologies that I have been looking at are Spring, Wicket, Struts, Guice, Hibernate and Tapestry.
I am a bit wary of Tapestry and Wicket. I dont know TOO much about them but they seem to deviate from the servlet->model jsp->view formula. I am not sure if I am comfortable with that. Although, I hear that Wicket is actually the best fit with Guice and is extremely testable.
Spring seems like it could be a nice fit, but I am very wary of frameworks which attempt to do everything. I would love to use spring-MVC, but can I swap in other components? Can I for example use Guice as my DI engine while using Spring-MVC as my framework?
I have briefly looked at Struts but it seems overly complex for my needs and again seems to be a complete package.
I've never used Hibernate, but it seems to be the standard for ORM and if it's anything like ActiveRecord (which I have only been exposed to a little bit) I am sure it fits my needs.
I also have never really used Guice but people really seem to like it, and I am a fan of DI in general even though I am not sure how it is used in an actual application.
Basically, I am only really confident with writing Servlets / JSP's. I am not opposed to learning alternate technologies but I am looking for advice as to which ones would REALLY benefit me.
If I can make an MVC app using Servlets and JSP's is it worth it to incorporate Spring? Or should I just use Servlets / JSP's and incorporate a DI engine like Guice?
I am pretty sure I would like to use Hibernate for ORM, but I hear it can be pretty complex. All I am really looking for is a way to map my POJO's to a database, so if there is something better/easier to use I am willing to look it up.
I am feeling lost and am looking for a bit of direction from people knowledgable in the area, any opinions on any of these issues would be hugely appreciated. Thanks!
"Spring seems like it could be a nice fit, but I am very wary of frameworks which attempt to do everything. I would love to use spring-MVC, but can I swap in other components? Can I for example use Guice as my DI engine while using Spring-MVC as my framework?"
Agreed Spring provides a lot of stuff, but it's totally modular. You can use DI with or without AOP and so forth. And yes you can use Spring MVC and Guice for DI together.
"I have briefly looked at Struts but it seems overly complex for my needs and again seems to be a complete package."
I have used Struts for quite some time now, but even when I started using it, I found it easy as a breeze. The controller might seem overwhelming at first, but you will have real fun when you get the hang of it. The best way would be taking a look at some real world examples using Struts.
"I've never used Hibernate, but it seems to be the standard for ORM and if it's anything like ActiveRecord (which I have only been exposed to a little bit) I am sure it fits my needs."
Oh then if you found Struts to tough, Hibernate is huge. It requires a big learning curve. It pays at the end, but if you know ActiveRecord, I will suggest you to stick to it before you get a good amount of knowledge of Hibernate.
"I am pretty sure I would like to use Hibernate for ORM, but I hear it can be pretty complex."
IMHO, very true...at least for beginners. (Anyone suggesting a change here?)
"If I can make an MVC app using Servlets and JSP's is it worth it to incorporate Spring?"
You mean without Struts or any other framework? How?
Seems like you are trying to take on too much too fast. Try considering one thing at a time. DI itself is a tricky thing to implement in real world. Oh yes conceptually it's great, but what I mean is you need to first get a hang of things one by one.
Very simply, if you are comfortable with JSPs and Servlets, then if you want to save some of the drudgery of web programming, I would look at Stripes or Struts 2.
I am very familiar with Stripes, and only am aware that Struts 2 is similar, so I will focus this entry on Stripes.
As an aside, Struts 1 is worthless. It offers no value (frankly).
Stripes has several features, but I will focus on only a few.
The primary value of Stripes, and if this were it's only feature it would still be very valuable, is its binding framework.
Binding is the process of converting the requests string values in to the actions values. Stripes does this amazingly well. Specifically, Stripes binding does very well on nested and indexed parameters, as well as type conversions. You can easily have a form field named "currentDate" and then have a "Date currentDate" in your Action, and Stripes will "do the right thing".
If you have a form field named "mainMap['bob'].listOfThings[3].customer.birthDate", Stripes will make the map, create the list, create the customer, convert the string to a date, populate the birthDate, put the customer in the 3 slot of the list, and put that list in the 'bob' spot of the map. (I do stuff like this all the time.)
The binding of requests to Action variables is just wonderful.
On top of that you get, if you use their form tags, you get nice behaviors when, for example, they put "Fred" in your date field. You easily get the form back, with Fred in the field, and a nice error message.
Finally, I really like their Resolutions as a result from their Actions. For example, a ForwardResolution to forward to a page, RedirectResolution to redirect to a page, StreamingResolution if you want to pump data down the socket, etc. It's a very elegant feature.
Stripes has all sorts of power and does all sorts of things, but those 3 pieces are what make it best for me, and what I use 99% of the time.
Simply, it really stays out of the way and readily handles the "plumbing" without completely obscuring the HTTP request nature of the system.
For someone who is content with JSP/Servlets, Stripes I think is an excellent step up as it adds good, solid value with very little cost (it's simple to set up) and without having to toss out everything you already know, since it works just great with JSPs and JSTL. Learn the simple mechanism it uses to map Actions to URLs, and how simple it is to map requests to your actions, and you'll be flying in no time.
Works great with Ajax and the like as well.
The question illustrates some confusion. I think the definitive answer is "no, it is not possible to use a web framework but not be dependent on it".
But your instinct is good. You want to maximize the general benefit a framework provides by helping to properly layer and modularize your code and minimize its invasiveness.
With that said, I think Spring is the winner on both counts.
If you follow the Spring idiom, the structure of your code will be better by the use of interfaces, layering, and aspects. Some of the attention they pay to design is bound to rub off on you. That's as helpful as the good plumbing code they provide.
Your code base does not have to be 100% Spring. I've seen Spring used in enhancements to legacy Java apps that weren't rewritten from front to back.
Struts tends to not be a good choice because it is JUST a web framework. It encourages you to put all your processing in Action subclasses, never to come out. Spring injects the idea of a service interface that decouples the web tier from the back end. It's easier to swap out web tiers and expose the service as SOAP, RMI, EJB, or remote HTTP call.
Hibernate is far more complex than Struts. If you choose Spring, use persistence interfaces and start with Spring JDBC. When you're ready for Hibernate, you can always write a new implementation and simply inject it into the place where your JDBC version used to be.
I'm currently working on a web app that makes heavy use of JSF and IceFaces. We've had some discussions of moving to another presentation layer, and I thought I'd take the discussion out into SO and see what the experts think.
I'm curious if anyone could weigh in on the pros and cons of the various Java presentation layer technologies. If you've only worked with one, say why you love it or hate it. If you've worked with several, give your impressions of how they stack up against each other.
Our technologies under consideration are:
IceFaces
JSF (without IceFaces)
GWT (Google Web Toolkit)
Wicket
Tapestry
And if I'm missing anything from my list, let me know.
Thanks!
My opinions are quite heavily biased towards Wicket because I've been using it for a while after tripping over JSP mines far too many times.
Wicket PROs:
True separation of layout and code.
Component based which means high reusability of site elements; For example you can create prettified form with automatic labeling and CSS styles and everything and just by changing it's DAO object in the component's constructor it's completely reusable in another project.
Excellent support for things like Ajax, Portlets and various frameworks in general directly out-of-the-box AND more importantly it doesn't rely on anything else than slf4j/log4j to work, everything's optional!
Wicket CONs:
Development has some confusion about things in general and Wicket generics are a bit of a mess right now although they've been cleaned a lot in 1.4
Some components (like Form.onSubmit()) require extensive subclassing or anonymous method overriding for injecting behaviour easily. This is partly due to Wicket's powerful event-based design but unfortunately it also means it's easy to make a code mess with Wicket.
Random CONs: (that is, I haven't used but these are my opionions and/or things I've heard)
GWT is JavaScript based which sounds stupid to me. Main issue is that it reminds me too much of JSP:s and its autogenerated classes which are horrible.
Tapestry doesn't separate markup and code properly in a manner which could be easily validated between the two which will cause problems in the future.
I've used GWT for a couple small projects. Here are some things I like about it:
It's ajax by default, so I didn't have to make it do ajax, it just came along with using GWT.
It's got good separation of client versus server-side code.
I can unit-test my client code using junit
It lets you built crisp, snappy apps, largely because it's ajax.
Things I don't like:
Some things don't work as expected. For example, I've seen cases where click events didn't fire as expected, so I had to do a workaround.
Auto-deploy to tomcat running in eclipse sometimes just stops working, and I could never figure out why.
The biggest question I'd ask is why are you changing presentation layer? That's a very expensive cost and I can see the benefits of one technology outweighing the others by as much as the cost to change...
In short:
= JSF =
PROS:
component architecture;
many libraries & tools;
somewhat good IDE support
CONS:
heavy weight, both in CPU/memory and learning curve;
when something doesn't work as expected, it's difficult to debug
= WICKET =
PROS:
lightweight;
sensible templating system;
good tutorials;
CONS:
reference documentation is not so well organized and deep as are the tutorials;
development team had some serious difficulties, especially when becoming and incubated project. This lead to confusion on important aspects of the framework, at that time I had to switch to another framework because of this...
What about Stripes?
My pick would be Wicket. Have used it and is gives excellent re-usability. It has one of the most vibrant forum/mailing list. As a question and its gonna be answered in minutes. It has excellent support for AJAX. One of the usual cons attributed to Wicket is the steep learning curve. Well those were one of the old age cons which hold no value anymore now.
JSF: Better stay away from it. Another team which developed a project on JSF is now thinking to shift to Wicket after our success with it.
#Megadix: Like you said the documentation was poor in the beginning, but not any more. There is an excellent book called Wicket in Action written by the developers of Wicket. The sample code provided on the site is also a good place to start and learn
I'd wonder if you a have a service layer that's distinct from the web client, something that the web controllers simply invoke to get their work done.
If you do, the choice of web UI technology can be decoupled from the back end. If it's exposed as a contract first web service, you can have different apps share it. As long as your clients can send and receive XML they can interact with your services. Want to switch to Flex? No worries - point it at the service and render the XML response.
See my comparison of Wicket and Tapestry 5: Difference between Apache Tapestry and Apache Wicket.
I am coming from an Enterprise Java background which involves a fairly heavyweight software stack, and have recently discovered the
Stripes framework; my initial impression is that this seems to do a good job of minimising the unpleasant parts of building a web application in Java.
Has anyone used Stripes for a project that has gone live? And can you share your experiences from the project? Also, did you consider any other technologies and (if so) why did you chose Stripes?
We've been using Stripes for about 4 years now. Our stack is Stripes/EJB3/JPA.
Many use Stripes plus Stripernate as a single, full stack solution. We don't because we want our business logic within the EJB tier, so we simply rely on JPA Entities as combined Model and DTO.
Stripes does the binding to our Entities/DTO and we shove them back in to the EJB tier for work. For most of our CRUD stuff this is very thing and straightforward, making our 80% use case trivial to work with. Yet we have the flexibility to do whatever we want for the edge cases that always come up with complicate applications.
We have a very large base Action Bean which encapsulates the bulk of our CRUD operations that makes call backs in to the individual subclasses specific to the entities and forms.
We also have a large internal tag file library to manage our pages, security, navigation, tasks, etc. A simple CRUD edit form is little more than a list of field names, and we get all of the chrome and menus and access controls "for free".
The beauty of this is that we get to keep the HTTP request based metaphor that we like and we get to choose the individual parts of the system rather than use one fat stack. The Stripes layer is lean and mean, and never gets in our way.
We have a bunch of Ajax integrating YUI and JQuery, all working against our Stripes and EJB stack painlessly.
I also ported a lighter version of the stack to GAE for a sample project, basically having to do minor work to our EJB tier. So, the entire stack is very nimble and amicable to change. Stripes is a big factor of that since we let it do the few things that it does, and does very well. Then delegate the rest to other parts of the stack.
As always there are parts folks would rather have different at times, but Stripes would be the last part to go in our stack, frankly. It could be better at supporting the full HTTP verb set, but I'd rather fix Stripes to do that better than switch over to something else.
We use stripes now on all our production sites, and have been for about a year now. It is an awesome product compared to struts, which we used to use before that. Just the fact that there are literally no XML config files and that you can set it all up with a minimal amount of classes and annotations is awesome.
In terms of scaling & speed it actually seems to be better than struts, and my guess would be because there are less layers involved. The code you end up with is a lot cleaner as well, because you don't have to go off to seperate XML files to find out where redirects are going.
We use it with an EJB3 backend, and the two seem to work really well together, because you can use your EJB POJO inside your actionBean object, without needing a form object like in struts.
In our evaluation we considered an alpha version of struts (that supported annotations) and a lot of other frameworks, but stripes won because of it's superior documentation, stability and clean-ness.
Couldn't figure out how to leave a comment: so to answer your second question we haven't encountered a single bug in Stripes that I know of. This is quite impressive for an open source framework. I haven't tried the latest version (1.5) yet, but 1.4.x is very stable.
We converted a home-grown web framework to stripes in about a week. We're using it in production at this time and it's a great framework. The community is extremely helpful, and the framework doesn't get in your way. It can be extended in many places to change the behavior as you see fit. The url binding feature is awesome as well. We implemented a robust security framework using annotations and interceptors. We're using spring for dependency injection and stripes has excellent support for that.
I'd definitely use the new 1.5 release if you're going to use it.
I'm a huge fan of the framework. I came from a struts background and it's the exact framework I was looking for. The other developers on our team really enjoy using the stripes framework.
I just bought the stripes beta book from the pragmatic programmer's site. It's a great resource on Stripes 1.5.
We have now used Stripes in multiple production projects and so far the experience has been great. Setup time is low and the configuration management issues seem to be fewer. We have webapps running with Stripes/Dojo/Hibernate and others with a mix of Stripes/Spring/JSP/Jquery etc. Adding Stripes to our existing projects was fairly simple thanks to their support for integrating existing Spring configurations. Using Stripes with JSP is fun although sometimes you do feel the need to code in Java and not have to use the JSTL so much.
Note:
This is an old question, but given that it pops up pretty fast when you search for Stripes usage, I am adding a response to it.
I also came from a Struts and JSF background into Stripes. I went from a large enterprise environment that used mostly struts and JSF on newer projects, to a smaller environment that did all their J2EE in Stripes.
Seems like Stripes gives you what you want in a Web Framework without getting in the way too much. Not much configuration is necessary, as others have already mentioned. Very quick development and allows you to focus on presentation etc. instead of hassling with the framework.
If I had to start a fresh new project and I had my say, I would choose either Stripes or JSF. I might have been scared away from Stripes if I had to make the decision to switch to it, because it kind of looks/feels like a sourceforge basement project instead of a enterprise-grade framework, but it seems to be fairly solid. We use Stripernate for easy ORM.
However, it reminds me of Fruit Stripe gum, which lost its flavor WAY TOO FAST.
Stripes is yesterdays technology, if you can pick something a little more modern like GWT.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I am considering creating my own website using Java and am trying to decide what framework to use. However, doing a quick search for Java frameworks returns more than 50 to choose from!
My website is just going to be for my own enjoyment of building it in the beginning, but if it becomes popular, it would be good for it to have some scalability, or to at least be able to redesign for that.
What are the main differences between the more popular frameworks? Are there instances where one significantly outperforms the others? For example, high-traffic enterprise applications versus low-traffic small applications. I'm also wondering if some are much easier to learn and use than others.
Is there anyone who has experience with some of these frameworks and can make a recommendation? Does the sheer number of choices just serve as an early warning to avoid Java-based web development where possible?
I've used Tapestry 3, Wicket, Echo, and JSF fairly extensively. I'd really recommend you look those over and pick the one that appears the easiest for you, and to most closely fit the way you prefer to work.
Of them, the most comfortable for me to work with was Wicket, due to the lightweight nature of component building and simplicity of page templating. That goes doubly so if you are using your own db code instead of Hibernate or some other framework (I was never completely happy with Wicket Hibernate or Spring Integration).
Echo is great if you don't mind writing all of your layout in Java. I know that is different now, but I still think that product serves a fairly narrow niche. They change the development model with every major release as well it seems.
Tapestry is a great product, but it is obviously very different from the others in terms of development model as it is led mainly by one dude. Howard Lewis Ship is no doubt quite smart, but I am disappointed with their decision to basically forget backwards compatibility with each release. Again, though, for your needs this may not matter, and I've always found the Tapestry products pleasurable to work against.
JSF has been out for years, and still feels like something that a Struts guy built to fix all of the problems of Struts. Without really understanding all of the problems with Struts. It still has an unfinished feel to it, although the product is obviously very flexible. I use it and have some fondness for it, with great hopes for its future. I think the next release (2.0) to be delivered in JEE6 will really bring it into its own, with a new template syntax (similar to Facelets) and a simplified component model (custom components in only 1 file... finally).
And, of course, there are a million smaller frameworks and tools that get their own following (Velocity for basic needs, raw JSPs, Struts, etc). I generally prefer component oriented frameworks myself, though.
In the end, I'd recommend just taking a look at Tapestry, Wicket, and JSF and just picking the one that feels the best to you. You'll probably find one that just fits the way you like to work very quickly.
My favorite is the Spring Framework. With 2.5 Spring MVC is soooo kick ass, with new annotations, convention over configuration features, etc.
If you're just doing something super simple you could also just try using the regular Servlet API and not bother with a framework.
I recommend the component oriented Wicket framework. It allows you to write your web application in plain old Java code, you can use POJOs as the model for all components and don't need to mess around with huge XML configuration files.
I had successfully developed an online banking application with Struts when I discovered Wicket and saw how easy web application development can be!
I've recently started using the Stripes Framework. If you're looking for a request based framework that's really easy to use, but doesn't impose any limits on what you are doing I'd highly recommend it.
It's similar to struts, but it goes way beyond it. There are even some plugin projects that enable you to do use hibernate or jpa with very little configuration.
There are a lot of good frameworks out there though I've heard wicket is a good one as well, but I haven't used it.
Haven't tried it myself, but I think
http://www.playframework.org/
has a lot of potential...
coming from php and classic asp, it's the first java web framework that sound promising to me....
UPDATE: Tapestry 5.2 is out, so it's not abandoned, as it previously appeared to be. My experience is with Tapestry 4, not 5, so your mileage may vary. My opinion of Tapestry has changed over the years; I have modified this post to reflect it.
I can no longer recommend Tapestry as I did previously. Tapestry 5 appears to be a significant improvement, but my main issue with Tapestry is not with platform itself; it's with the people behind it.
Historically, every major version update of Tapestry has broken backwards compatibility with extreme prejudice, far more than one might expect. This seems to be due to the incorporation of new coding techniques or technologies that require significant rewrites.
Howard Lewis Ship (the principal author of Tapestry) is certainly a brilliant developer, but I can't say I care for his management of the Tapestry project. Development of Tapestry 5 began almost immediately after Tapestry 4 shipped. From what I can tell, Ship pretty much devoted himself to that, leaving Tapestry 4 in the hands of other contributors, who I feel are not nearly as capable as Ship. After having made the painful switch from Tapestry 3 to Tapestry 4, I felt that I had been abandoned almost immediately.
Of course, with the release of Tapestry 5, Tapestry 4 became a legacy product. I wouldn't have a problem with this if the upgrade path wasn't so brutal again. So now our development team is in the rather unenviable position: We could continue to use an essentially abandoned web platform (Tapestry 4), make the heinous upgrade to Tapestry 5, or give up on Tapestry entirely and rewrite our application using another platform. None of these options is very attractive.
Tapestry 5 is supposedly written so as to reduce the likelihood of update breakage from this point forward. A good example is in the page classes: in previous incarnations, page classes descended from a base class provided by Tapestry; incompatible API changes in this class were the cause of a large number of backward compatibility problems. In Tapestry 5, pages are POJOs which are enhanced at runtime with the "magic Tapestry fairy dust" via annotations. So as long as the contract for the annotations is maintained, changes to Tapestry won't affect your page classes.
If this is right, then writing a new application using Tapestry 5 could turn out well. But personally, I don't feel like putting my hand on the burner again.
Disclamer: I work at Vaadin (previously IT Mill)
If you are doing something RIAish, you might want to take look at Vaadin. It's an open source UI-oriented AJAX framework that, to me, is nice to use (I come from a PHP background myself).
There's a case study that compares doing the same application (i.e. two applications with the same set of features) in Icefaces and Vaadin. In a nutshell, it states that the UI development was considerably faster.
Even though the study is hosted at the company's wiki, I can assure that it's objective, genuine and truthful, although I can't force you in believing me.
After a long while of testing various solutions, for me it turned out to be:
Spring MVC for the presentation and
controller layer (NO Spring Webflow though,
because my flows are based on ajax)
jQuery for all the client side stuff
Spring Security for the, well, security aspect
Hibernate / JPA2
Jetty for the sake of continuations (comet)
One month of an extraordinarily steep learning curve, but now I am happy.
I would also like to mention that I was just a little step away from skipping all that Java stuff and learing Scala/LIFT instead. As far as I am concerned, everything in Java that is related with cutting edge web development (comet, async communication, security (yes, even with Spring Security!)) still is a bit of a hack (proove me wrong by evidence, pleeease!). To me, Scala/LIFT seems to be a more out-of-the-box and all-in-one solution.
The reason why I finally decided not to go with Scala is
as a project leader I must consider human resources and Java developers are much easier to find than Scala developers
for most developers in my team, Scala's funcional concept, as excellent as it is, is hard to understand
Cheers
Er
I've heard good things about the Spring Framework too. In general, though, I've been underwhelmed by most Java web frameworks I've looked at (esp Struts).
For a simple app I'd definitely consider using "raw" servlets and JSPs and not worry about adopting a framework. If the servlets are well written, it should be straightforward in the future to port to a framework if necessary when the app grows in complexity.
My pick is Wicket!!
All of them - that's the problem ;-)
I think for your modest requirements, you just need to code up servlets or simple jsp pages that you can serve from Tomcat server. I dont think you need any kind of web-framework (like struts) for personal web-site data
Saying "use JSF" is a little to simple. When you decide to use JSF, you have to choose a component library on top of it. Will you use MyFaces Tomahawk, Trinidad, Tobago (http://myfaces.apache.org/)? Or maybe ICEfaces (http://www.icefaces.org/)? Oh, and if you use ICEfaces, will you use JSPs or Facelets for your views?
In my opinion it is to hard to tell. Nobody has the time to evaluate all the promising alternatives, at least in the projects I work on, because they are not big enough to do three month evaluation phases. However, you should look around for some that has a big and active community and isn't gone in a year. JSF is around for some time, and since it gets pushed by sun, it will be around for some more. I can't say if it's the best choice, but it will be a good one.
http://zkoss.org - the good one
For high traffic sites I'd use a framework that doesn't manage client state on the server - Wicket, JSF and Tapestry are managing client state on the server. I'd only use those frameworks (Wicket is my favourite) if the application should be more like a desktop application. But I'd try to use a more scalable and simple REST+AJAX approach though.
Spring MVC would be a candidate, but since Spring MVC 3 it has a strange annotation overloaded programming model which doesn't use the benefits of static typing. There ore other ugly things like output parameters in methods combined with a usual return, so there are two output channels of one method. Spring MVC also tends to reeinvent the wheel and you'll have more to configure compared to other frameworks. I cannot really recommend Spring MVC though it has some nice ideas.
Grails is a convenient way to use Spring MVC and other established frameworks like Hibernate. Coding is fun and you'll quickly see results.
And don't forget that the Servlet API with a few little helpers like FreeMarker for templating is very powerful.
I have evaluated quite a few frameworks and Vaadin (http://vaadin.com/home) has percolated all the way to the top.
You should at least give it a short evaluation.
Cheers!
My pick would be Wicket (for large projects and a predictable user base), GWT (for large projects that are mostly public facing) or just a service framework (like Jersey/ JAXRS) together with a JavaScript toolkit (for small to medium projects).
I recommend Seam, especially if you need persistence.
See a few comments on some Java application Frameworks (second paragraph):
http://swiss-knife.blogspot.com/2009/11/some-java-application-servers.html
For quick and fancy GUI you can use JSF with Richfaces library.
Richfaces UI components are easy to use and handy references available with code demonstration in the demo site. Probably later when your site has more data to handle and lot of information has to be transacted in database you can plug any database access framework (ORM) with it.
Can't believe no one has mentioned GWT
My favorite way to go for really simple apps is Apache VelocityTools (VelocityLayoutServlet) with Velosurf (http://velosurf.sourceforge.net).
For more complex apps, Spring MVC or Struts 2.
Try HybridJava - that is much simpler than anything else.
I would say vaadin or wicket