Chandrasekhar questions whether Component Based Development is worth it. My answer to his question is:

YES! Component Based Development Is Worth It!

Let me explain. Even though I'm a committer on a component based web application framework, I support the whole idea of CBD for web gui's, not just my pet project (though I'd prefer if one chooses Wicket :-P). There is no way you can create complex applications just as easily with the model2 frameworks as you can with CB frameworks.

In Component Based frameworks you let go of the idea of a Request, instead you work with your components and their events. There is not 'one action to rule them all', but each component can have (has) one or more events associated with them. For instance, a Form has an onSubmit event, and (in Wicket) many Forms may be present on one page. So yes you are partly right: the frameworks you mention (Struts and Spring MVC) ARE request driven, but the component based frameworks (JSF, Tapestry and Wicket) are Event driven.

Wicket allows you to create multiple sortable, pageable tables, which can sort and navigate independently. Of course this can be done with model2 frameworks, but how much effort will it take? In this case the necessary code size is very small and understandable.

I know that Tapestry and JSF also cater for this kind of complex GUI constructs, but differently, and if I might say: more complex and less elegant. But you should try it yourself, as I'm rather biased.

As for the other concern, the number of XML configuration files, this is just a matter of taste and framework. Wicket allows you to use ZERO (0) extra configuration files. The only required XML file is the web.xml file, which is mandated by the servlet specification. I'll repeat: NO XML CONFIGURATION files necessary when using Wicket.

Considering performance, whether you choose to use a component library, or a tag library from a vendor, you should have those concerns either way. That is always a concern with vendor supplied software. When you develop your own components, you have all the power to tune the performance yourself. You are in a better position to do so, because you can test the component independently.

Furthermore, when using Wicket, you get clustering support out of the box (no sticky sessions required), when the clustering becomes problematic, Wicket allows you to exchange session size for computation. Thus allowing you to make a trade.

When you have such concerns about using component based frameworks, I'd suggest you try out one or the other. It is always a good thing to learn new stuff. And given your concerns, I'd definetely suggest you give Wicket a decent test drive. It may just make your day a little better.