The Apache Wicket team is proud to announce the availability of the fourth maintenance release: Apache Wicket 1.3.4. A lot of bugs have been squashed and several improvements implemented. Two noteworthy bugs have been squashed: - cross session leakage due to a dangling thread local in exceptional circumstances - memory leak in localizer (WICKET-1667) It is therefore recommended you update to Wicket 1.3.4 at your earliest convenience. Eager people click here to download the distribution, others can read further: http://www.apache.org/dyn/closer.cgi/wicket/1.3.4 We thank you for your patience and support. - The Wicket Team Apache Wicket Apache Wicket is a component oriented Java web application framework. With proper mark-up/logic separation, a POJO data model, and a refreshing lack of XML, Apache Wicket makes developing web-apps simple and enjoyable again. Swap the boilerplate, complex debugging and brittle code for powerful, reusable components written with plain Java and HTML. You can find out more about Apache Wicket on our website: http://wicket.apache.org This release This release is the fourth maintenance release for the Wicket 1.3 product. This release fixes several bugs and adds some minor improvements. Migrating from 1.2 If you are coming from Wicket 1.2, you really want to read our migration guide, found on the wiki: http://cwiki.apache.org/WICKET/migrate-13.html Downloading the release You can download the release from the official Apache mirror system, and you can find it through the following link: http://www.apache.org/dyn/closer.cgi/wicket/1.3.4/ For the Maven and Ivy fans out there: update your pom's to the following, and everything will be downloaded automatically: org.apache.wicket wicket 1.3.4 Substitute the artifact ID with the projects of your liking to get the other projects. Please note that we don't prescribe a Logging implementation for SLF4J. You need to specify yourself which one you prefer. Read more about SLF4J here: http://slf4j.org Validating the release The release has been signed by Martijn Dashorst, your release manager for today. The public key can be found in the KEYS file in the download area. Download the KEYS file only from the Apache website. http://www.apache.org/dist/wicket/1.3.4/KEYS Instructions on how to validate the release can be found here: http://www.apache.org/dev/release-signing.html#check-integrity

Nice work guys. Thanks to the Wicket team for a great framework. Looking forward to what's in store for version 1.4!

Congratulations guys, I am glad after so many years there is a framework in Java community that really compete with ASP.net WebForms. I don't have any doubt Wicket would be a grate hit; I would recommend JSF guys to learn some thing from Wicket and understand a GUI framework is not supposed to be rocket science. Great work "Wicket" guys.

I would recommend JSF guys to learn some thing from Wicket and understand a GUI framework is not supposed to be rocket science.

I already wondered what took you 'you wicket guys' so long to post a remark like this ;)

I would recommend JSF guys to learn some thing from Wicket and understand a GUI framework is not supposed to be rocket science.

I already wondered what took you 'you wicket guys' so long to post a remark like this ;)

I am not a Wicket guy, but a mere user who is sick and tired of Java Web frameworks including tedious and not very well documented "Tapestry". I have been trying to convince JSF guys since very beginning (see past post on serverside.com) that GUI framework supposed to be intuitive and easy to learn, and if nothing learn from ASP.net WebForms which turned majority of regular VB programmers into ASP.net programmers with out a sweat, versus a framework like JSF which even the most experienced J2EE developers are hesitant to adopt. Look what happen to JSF, even after all the marketing power for years, and official support by all big Java vendors, JSF is no where.

Look what happen to JSF, even after all the marketing power for years, and official support by all big Java vendors, JSF is no where.

This is my biggest disappointment with JSF. It has all that behind it and it's badly designed, overly complex, unproductive and not practical. Meanwhile, several other frameworks, including Wicket, are wayyyyy better and don't even benefit from the backing that JSF has. The other thing that's too bad is that "JSF The Complete Reference" by Shalk and Burns is one of the best computer books I've read. (I learned JSF for work.) What's too bad about it is to have such an excellent book wasted on such a poorly designed framework. Meanwhile, at work we dumped JSF for another framework and have been much happier and more productive since. PS: there is no need to flame me. If you're warm and happy in your pile of JSF + Facelets + Seam + Shale + Shucks + GodKnowsWhatElseYouNeedToMakeJSFHalfUsable, more power to you. To each their own. I don't think I'm alone or even marginal in being disappointed with JSF, though.

If you're warm and happy in your pile of JSF + Facelets + Seam + Shale + Shucks + GodKnowsWhatElseYouNeedToMakeJSFHalfUsable, more power to you. To each their own. I don't think I'm alone or even marginal in being disappointed with JSF, though.

This is a lie. The pile is Hibernate + Seam + some component library (for example RichFaces). Maybe Wicket developers don't use Hibernate and or Spring under their web framework? And maybe Wicket doens't magically need some components developed from third party libraries? This is strange because it's a component framework... And Seam is not thought to complete JSF in its field because it helps on persistence, security, etc.

This is a lie. The pile is Hibernate + Seam + some component library (for example RichFaces).

And Seam is not thought to complete JSF in its field because it helps on persistence, security, etc.

Like I said, if you're happy with it, I'm happy for you :-)

This is a lie. The pile is Hibernate + Seam + some component library (for example RichFaces).

And Seam is not thought to complete JSF in its field because it helps on persistence, security, etc.

Like I said, if you're happy with it, I'm happy for you :-)

Sentences like "if you are happy with X (that is ), I am happy for you" doesn't mean that I can't discuss your .

Sentences like "if you are happy with X (that is ), I am happy for you" doesn't mean that I can't discuss your .

Fair enough.

And maybe Wicket doens't magically need some components developed from third party libraries? This is strange because it's a component framework...And Seam is not thought to complete JSF in its field because it helps on persistence, security, etc.

These questions suggest to me that you haven't tried or researched Wicket. I'm definitely more likely to trust the opinion of someone who has used JSF and Wicket with regard to their relative merits. I haven't used JSF so I have nothing to offer to the comparison. I will say, though, that I've never seen anyone say that they've used Wicket and it sucked but I've seen a lot of people say that about JSF. What I like about Wicket is that it's confined to the View and Controller portions of my implementation. The model is whatever you want it to be. It doesn't force you to build your model in any particular way. This is a flaw I see in many MVC frameworks: they define the structure of the model when they should be worried about the view. So to answer your question, you don't need to use Hibernate or Spring but you can if you like and people have built add-ons that make this easier. But I can use my rich domain model without any modification and that makes me a happy developer.

These questions suggest to me that you haven't tried or researched Wicket. Your answer suggest to me that you haven't red my post.

So to answer your question, you don't need to use Hibernate or Spring but you can if you like and people have built add-ons that make this easier. But I can use my rich domain model without any modification and that makes me a happy developer.

First, that were sarcastic questions. Second, saying the obvious (that you can use or not Spring and/or Hibernate with Wicket: and Wicket would really really suck otherwise!!) you are confirming what I was asserting with my sarcastic questions.

These questions suggest to me that you haven't tried or researched Wicket.

Your answer suggest to me that you haven't red my post.

I read your post.

Second, saying the obvious (that you can use or not Spring and/or Hibernate with Wicket: and Wicket would really really suck otherwise!!) you are confirming what I was asserting with my sarcastic questions.

You are missing the point. You don't need Spring or Hibernate to make Wicket work really well. I think the point above which you responded to with that crazy thing you call 'sarcasm' (which I've never heard of and can't recognize in even it's most facile form) is that in order to be effective with JSF, you need a bunch of other stuff. I don't know that that is the case so I don't make that claim. Saying you 'can' use something and you 'need' something are two very different things.

You are missing the point. You don't need Spring or Hibernate to make Wicket work really well.

Tell me, maybe Wicket regards to persistence and/or transactions and/or messaging or and/security and/or webservices (...) in some way? You, are completely missing the point. Wicket is not different from JSF here. It's not a full stack framework. If you are happy with plain JDBC etc, I am happy for you. Ah, but JSF anyway doesn't force you to use Spring and Hibernate. So what are you speaking about? And Seam offers more then pure Wicket, much more. So your comparison has not much sense.

You are missing the point. You don't need Spring or Hibernate to make Wicket work really well.

Tell me, maybe Wicket regards to persistence and/or transactions and/or messaging or and/security and/or webservices (...) in some way?

No. That's the point. You can do whatever you like Wicket. If you can code it in Java, you can use it with easily with Wicket.

You, are completely missing the point. Wicket is not different from JSF here. It's not a full stack framework.

I didn't say it was a full stack. I said you don't need a huge stack to use it.

If you are happy with plain JDBC etc, I am happy for you.

I didn't say anything about JDBC.

Ah, but JSF anyway doesn't force you to use Spring and Hibernate. So what are you speaking about?

If you took a little time to understand what other people are saying, you would know. The implied argument was that JSF isn't usable without a large stack of other frameworks. You responded that people might be using other frameworks with Wicket. That's not a logical rebuttal to the argument that was made. If you want to argue that JSF works fine without a stack of other frameworks to support it, then do so. It would be nice if we could try have a rational discussion for once.

Wicket is not different from JSF here. It's not a full stack framework.

OK then. Let's compare apples to apples and oranges to oranges. Here's what I'm saying. I'm quite sure that I could get a lot more done, faster, with less code, and less headaches, with Wicket and nothing else, than with JSF and nothing else.

Seam offers more then pure Wicket, much more. So your comparison has not much sense.

Hi Alberto. The approach of Seam is getting rid of the life cycle of your POJOS. This approach works well with highly predictable behavior typical of web applications with "classic" navigation. But with AJAX most of the Seam benefits are lost, if Seam has nothing to do with a Swing application neither with an AJAX application when the behavior of any event goes beyond the typical form submitting. In this scenario solutions like Wicket (or my own ItsNat) are more flexible to build desktop-like applications in the AJAX era. Jose M. Arranz ItsNat, Natural AJAX

Sorry "The approach of Seam is getting rid of the life cycle of your POJOS" I mean the opposite: "to control the life cycle of your POJOS".

This approach works well with highly predictable behavior typical of web applications with "classic" navigation.

But with AJAX most of the Seam benefits are lost, if Seam has nothing to do with a Swing application neither with an AJAX application when the behavior of any event goes beyond the typical form submitting.

Can you post an example of this scenario? I can't image anything where Seam looses its benefit here. But I could be wrong. I didn't understand very well your explanation, probabily because my english is bad ;)

Can you post an example of this scenario? I can't image anything where Seam looses its benefit here. But I could be wrong. I didn't understand very well your explanation, probabily because my english is bad ;)

E 'ironico? ;) For instance, I can't see how Seam scopes can help to an AJAX application based on a single page (no navigation between pages).

E 'ironico? ;)

Nope!

For instance, I can't see how Seam scopes can help to an AJAX application based on a single page (no navigation between pages).

I can't see why not! Can you provide a very simple use case where, thought still implementable with Seam, remark its bad attitude to the job?

For instance, I can't see how Seam scopes can help to an AJAX application based on a single page (no navigation between pages).

I can't see why not! Can you provide a very simple use case where, thought still implementable with Seam, remark its bad attitude to the job?

Because in a pure AJAX application SESSION scope is irrelevant, because the user usually uses one only page (supposed no page navigation), PAGE may be meaningful in AJAX but this state is used to keep data between same page to same page navigation, and finally EVENT scope is used for classic navigation, is not an "AJAX event scope". Am I wrong?

Because in a pure AJAX application SESSION scope is irrelevant, because the user usually uses one only page (supposed no page navigation), PAGE may be meaningful in AJAX but this state is used to keep data between same page to same page navigation, and finally EVENT scope is used for classic navigation, is not an "AJAX event scope".

Am I wrong?

I think so. The conversation scope is long as you want. The developer decides the bounds. Also if you stay in the same page. Anyway Seam is not only about scopes and it has a sophisticated AJAX support. There is an example in the Seam distribution where they implement an AJAX chat.

And Seam offers more then pure Wicket, much more. So your comparison has not much sense.

You can use Wicket with Seam, see for instance http://www.seamframework.org/service/File/3102 (and http://chillenious.wordpress.com/2007/07/16/added-initial-seam-support-for-wicket/ for my initial test project).

You can use Wicket with Seam, see for instance http://www.seamframework.org/service/File/3102 ...

Is there a way to start using Wicket inside a big Struts application? Wrap wicket pages inside Struts pages like components?

You can use Wicket with Seam, see for instance http://www.seamframework.org/service/File/3102 ...

Is there a way to start using Wicket inside a big Struts application?

Wrap wicket pages inside Struts pages like components?

Might be possible, and in the list archives you can find various messages of people who have been using JSP & Wicket together. I don't expect it to be neat and easy though.

You can use Wicket with Seam, see for instance http://www.seamframework.org/service/File/3102 ...

Is there a way to start using Wicket inside a big Struts application?

Wrap wicket pages inside Struts pages like components?

Might be possible, and in the list archives you can find various messages of people who have been using JSP & Wicket together. I don't expect it to be neat and easy though.

Neat? No, but, "unfortunately" there are a lot of legacy apps out there, and doing big bang replacements is unfeasible both from a risk and management perspective, so migrating piece by piece may be the only way for some people. And getting rid of Struts monstrosities in an unneat way may be better than not at all. I believe Al Maw wrote about jsp to wicket and wicket to jsp integration here: http://herebebeasties.com/2007-03-01/jsp-and-wicket-sitting-in-a-tree/

JSF which even the most experienced J2EE developers are hesitant to adopt.

This is ridicolous. A lot of J2Ee experienced and not experience developers are adopting JSF with full satisfaction.

Look what happen to JSF, even after all the marketing power for years, and official support by all big Java vendors, JSF is no where.

I am sure you are jokig now..

Another web "framework". Java actually has more web frameworks than actual websites running on it.

Another web "framework".

Java actually has more web frameworks than actual websites running on it.

That's a good one-liner but not a rational argument for dismissing Wicket.

Another web "framework".

Java actually has more web frameworks than actual websites running on it.

Very funny. Wicket has been around for 4 years, so you're a bit late with that joke. Java is one of most widely used programming languages, and guess what kind of applications people are typically building with it? Indeed, web applications (which do not have to be public facing). Even if framework X just has a couple of users, they might very well be happy it's existence, whether you care about it or not. Competition often leads to innovation. Frameworks like Wicket, Tapestry, GWT etc have had their impact on how the new version of JSF will work, and will continue to influence each other. The same goes for ORM frameworks, web service frameworks, JEE containers, etc. And the end users win. Whether it comes to telephones, guitar effects, breakfast cereal, wine, cheese or software frameworks, I am glad to have choice. If you have a problem with choice, than just go for the standard (JSF) and quit whining.

I agree completely! Choice and competition leads to innovation! Java is all about choice! If Spring and other frameworks didn't innovate I bet we would be using (not me!) EJB's 1.0 and Entity Beans! I myself after using Struts for years got really impressed with Click Framework (http://click.sourceforge.net/) !! Tried JSF several times... and... nahhhh, no way!!! Pedro Costa

First up, congrats to the Wicket team. I have to say, no web framework has made me as happy as Wicket has, and I recommend it at every opportunity. I don't get chance to use it as much as I'd like, but given the choice it is the one I reach for every time. Now, onto the JSF tangent... JSF has only a single purpose - to provide a standard approach to web development for Java. This has all kind of potential benefits, some of them technical, but perhaps the most important is portability of skills. Java web development is a confusing area for business, and the diversity and complexity have made repeatable successes extremely hard to acheive. The wide range of libraries on Java Developer CVs just isn't something that ASP developers (or their hiring managers) have to worry about. It would bring an awful lot of unity and cohesion to Java if you could just put "4 years JSF experience" on your CV and leave it at that - and the existence of a standard ensures that your skills are likely to be applicable elsewhere without having to learn a new framework. Unfortunately, the same thing comes up with JSF time and again. Do you mean JSF, or Seam? ICEFaces? MyFaces? JSF with some other web framework in a desparate attempt to make it palatable to work with? Where are the transferable skills when JSF is so seemingly dependent on a wide range of other baggage (some complementary, some competing)? Not only is it the Marmite of web frameworks, but even within those that love it there are factions, splits, divisions, fragmentation. The technical limitations of JSF have failed utterly to unify Java web development under a single banner, but worse it has even created ghettoisation within its own skillbase.

Very well said Dave. I think you are spot on.

Unfortunately, the same thing comes up with JSF time and again. Do you mean JSF, or Seam? ICEFaces? MyFaces? JSF with some other web framework in a desparate attempt to make it palatable to work with? Where are the transferable skills when JSF is so seemingly dependent on a wide range of other baggage (some complementary, some competing)?

JSF is not dependent on Seam, MyFaces, ICEFaces.

JSF is not dependent on Seam, MyFaces, ICEFaces.

No, but everyone who wants to work with bare bones JSF, raise your hand?

Great news, congrats! I recently started my first project using Wicket and I can only say that I enjoy building webapps again! As Spring MVC is a MAJOR improvement over Struts, Wicket is to me a MAJOR improvement over JSF. Keep up the great work!