In a typical web framework, you write a template that's more-or-less HTML, but with special code to make it dynamic. For example, here's how to print "Hello World" in php:
NOTE: I am NOT saying that PHP is better than Wicket. I'm just EXPLAINING how Wicket works compared to other frameworks and using PHP as an example of another framework.
<html>
<head>
<title>PHP Test</title>
</head>
<body>
<?php echo '<p>Hello World</p>'; ?>
</body>
</html>
In the <?php ?> tag, you specify what HTML will be generated. Wicket works in a different way. You mark the dynamic parts of your HTML with a special attribute and specify what it does in Java code. Here's the same example in Wicket:
<html>
<head>
<title>Wicket Test</title>
</head>
<body>
<p wicket:id="message">This is replaced</p>
</body>
</html>
And then in a Java class:
public class HelloWorldPage extends WebPage {
public HelloWorldPage() {
Label component = new Label("message", "Hello World!");
add(component);
}
}
By comparison the html template is simplified: You define the parts that are dynamic but you don't say what the dynamic parts will do. That's done entirely in the Java code. If you learn more about Wicket, you'll see that your Java code ends up looking similar to Swing code (Swing is Java's GUI API).
Before I go on to explain the top 8 reasons to NOT use Wicket, I want to say that there is one situation where I would still use it: If a large part of my webapp functioned like a wizard. Wicket makes it easy to keep track of state from page to page without persisting at each step. With a traditional framework, you have to manipulate the session or use hidden fields to accomplish this.
1. Documentation, documentation... documentation?
By far my biggest complaint about Wicket stems from problems with its documentation. Imagine this: You get stuck on an issue and have no idea why. First you search the official wiki. You try your hardest to find a section to answer your question but it doesn't seem to be there. On the other hand, it's so badly organized you may have just missed it. You guess it's not there and move on to the examples.
The examples can be useful, but there's a lot to be desired. Exercise: Visit http://www.wicketstuff.org/wicket13/ and try to find an example that shows you how to redirect to a different page after you submit a form. I had to ask in the IRC channel to figure out how to do that. It also doesn't help that there are two example pages. One is on the main site, and another (much more useful, I might add) that's on wicketstuff.org (but good luck finding these examples on the wicketstuff.org home page).
Lets say the examples didn't help so you move on to the Javadocs. No help there: The class in question and its methods are barely documented. Take a look at this gem: http://wicket.apache.org/docs/wicket-1.3.2/wicket/apidocs/org/apache/wicket/SharedResources.html At least this time it's obvious the answer isn't there.
Time to move on to the mailing list archives. You discover that Wicket's mailing list is extremely active and is often the only source for answers. Here's the downside to that: 1) A mailing list is not the right environment to learn a framework. A mailing list is for situations where you more-or-less "get" the technology, but are unsure of a few things. 2) It's hard to find mailing list answers by Googling. Think about it, how often do people link to a mailing list threads? Almost never. That leads to poor page ranking and that means the answer to your question, even if it's there, is hard to find.
2. High learning curve
Even if the documentation was well written and complete, Wicket would still be harder to learn than most frameworks. Lets look at how to solve some basic problems using the example above:
How do hide a dynamic tag? component.setVisible(false). How do I dynamically add a class attribute to the tag? component.add(new SimpleAttributeModifier(“class”, “classValue”)); How do I dynamically add a CSS file to my template? webpage.add(HeaderContributor.forCss("/path/to/my.css"); Do you see the problem? It's subtle.
Knowing the answer to one of these does not help you in answering the others and each one of these questions requires you to deal with part 1. On the other hand, as soon as you learn how to write a conditional in PHP/JSP/ROR, you immediately know the answer to all of these questions and many more in the future.
Let's try an example together: How would you make a page's title dynamic in Wicket? Is it webPage.setTitle(String)? Nope, that doesn't exist. In fact, the word title isn't even mentioned in the javadoc. Ok, dead end #1. Perhaps it's webPage.add(new Title(...)); or something like that. Nope, there's no such thing as a Title class. In fact, the word Title isn't even part of any class in the javadoc. Dead end #2. That also rules out something like webPage.add(TitleContributor...); Dead end #3.
So, how the heck do you actually do this in wicket? The only answer I can find is webPage.add(new Label("wicketId", "dynamicTitle");. You add a Label to your page that attaches to your <title> tag and overwrites the text. Duh!
3. Different... not better, but different
In my 5 months with wicket, there was no indication that it was a time saver. Wicket seems more about making a webapp in a different way than in a productive way. Compared to a framework like Struts or Ruby on Rails, Wicket probably decreased my template code by 4x but increased my Java code by 4x. I ended up doing the same amount of work, just in a different place.
If you consider writing template code to be traumatic experience, perhaps you'll see this as a huge improvement. But, if you're like me, you'll think that a webframework should help you write less code. Writing less code has a lot of benefits. There's less to understand, less to maintain, less work to add a feature, etc.
Perhaps these time saving features exist and I overlooked them. Unfortunately, Wicket doesn't have an official list of, "Cool features that will save you tons of time" anywhere, so you'll likely have the same experience as me. But, I did read most of "Wicket In Action" (great book for learning Wicket, BTW), and it didn't change my impression.
4. Lacking 3rd party library support
Getting 3rd party libraries to work in Wicket is more annoying than other frameworks. By 3rd party libraries, I mean external tools that add content to your website that may or may not care about the programming language you use. Things like ReCaptcha to add a captcha to your site, the Facebook API for making a Facebook app, or Rome to add a RSS feed to your site. Fortunately, there are Wicket extensions for these examples (I made the first two), but unless you make your entire webapp from scratch, you're bound to run into others that aren't. With Wicket, getting these libs to work can be painful and confusing.
Lets look at ReCaptcha to see why. With ReCaptcha, you add a <script> tag to your webpage that refers to an external javascript file. When it loads, the script generates a captcha and an input field for you. When the user submits the page, you take the input and ask the ReCaptcha server, "User typed this, is that what was displayed?".
With most frameworks, this is an easy way to add a captcha to a website. With Wicket, it's a challenge. Since you didn't include this input in your template (remember, Wicket needs a wicket:id attribute on input fields too) and you didn't put add(new TextField("recaptchInput")); in your Java code, Wicket is unaware of the input. As a consequence, you can't leverage any framework features. This includes essentials like retrieving the value so you can pass it to the ReCaptcha server.
For those wondering "Why doesn't he just put it in his template and add the Java code?", that won't work: The ReCaptcha script would just generate another input field for you and cause the same problem.
What's the solution? You need to reach into the HttpServletRequest and extract the value by hand. Most frameworks, including Wicket, consider this a primitive way to get data from a user response. Yet, as far as I can tell, it's what you have to resort to.
5. Generate HTML or generate pain
Sometimes you want the server to generate something other than HTML. For example, you may want to generate Javascript or CSS. EG: var message = "dynamicString"; To make the string dynamic, the template would have to say var message = <span wicket:id="dynamicString">localized alert</span>; You have to do similar things in your CSS files to make them dynamic: .highlight { <span wicket:id="highlight">highlight style</span> }
Unless your editor speaks Wicket, this will drive it nuts. Not only will the dynamic bits be more verbose than a typical framework, they'll look more out of place. "Why is this HTML embedded in this CSS file?".
6. Easier to maintain?
One of Wicket's selling points is that it's far easier to maintain than other frameworks because you write most of your code in Java. I think that's debatable. Is 4x more Java code more maintainable (see part 3)? The code you write ends up looking like Swing code so unless you're very disciplined, you end up writing anonymous and inner classes all over the place that share instance variables with the parent class. Once that happens, it's a real chore to refactor them to outer classes.
If you put in the effort to avoid these pitfalls, your code may be more maintainable. But a framework is supposed to facilitate discipline, not put the burden on the developer. With Wicket I found myself thinking, "OK, how can I add that feature without it turning into a mess later?". I'd prefer to just focus on the feature itself. If I wanted to focus on proper discipline, I would've stuck with JSPs and Servlets in the first place. This goes back to the question, "What is this framework doing to make my life easier?"
7. The "Great for web designers" myth
Wicket is supposed to be nice for web designers because it doesn't use template code. You just put a wicket:id="something" on the HTML you want to be dynamic and replace it in your Java code. The end result is your HTML is perfectly understandable by a web designer who doesn't know the first thing about Java. While Wicket may be better than other frameworks in this respect, it still has problems.
For instance, Wicket has non-HTML tags for special functionality with names like <wicket:panel>, <wicket:child> and <wicket:extend>. These won't render correctly in a browser. If you research the last one, you'll see you must violate the "Don't Repeat Yourself" principle to get your pages to render outside the browser in a way that looks similar to its production code.
In general, Wicket is better than most frameworks in this respect. But, when you consider part 5, it can sometimes be worse than most.
8. Search Engine De-optimization
By default, the URLs Wicket uses look like this: http://www.startfound.com/?wicket:interface=:3:::: For a search engine, this is a problem for two reasons:
- This URL provides no semantic information
- This URL is only valid for that user's session.
There are Wicket classes that won't work with bookmarkable URLs. For example, if you want to use the Wicket "paginator" (think the bottom of Google search results), your URLs have to look ugly. So if you want pagination on your site with pretty URLs, you're going to have to write it yourself. And that goes for a lot of its other APIs.
Conclusion
There was a point while working on my hobby website that I was pulling my hair out dealing with these issues on a daily basis. Finally, I had enough and came to the conclusion that it was smarter to rewrite the whole thing from scratch in another framework.
I chose what I'd consider to be the exact opposite of Wicket: The Stripes Framework. During and since the rewrite, I couldn't be happier with my choice. When it comes to ease of use, quality documentation, simplicity and productivity, I've never worked with a better web framework. Let me state that I'm not affiliated with the Stripes framework, I'm just a huge fan. I have experience with Struts, Ruby on Rails, plain old JSPs and Servlets and, of course, Wicket, and the Stripes framework is by far the best web framework I've ever worked with.
One last note on Wicket: Of all those projects I created while learning it, there was one where I feel Wicket was the right choice (the whole thing was basically a Wizard). So in the end, I consider Wicket to be a hammer in my tool belt. Unfortunately, most jobs I come across require a screwdriver.
You can see my follow up blog post that compares Wicket and Stripes in depth here: http://www.assertinteresting.com/2009/03/why-i-prefer-stripes-over-wicket/
33 comments:
Too bad Wicket doesn't work for you. When it comes to documentation though, there are several books on Wicket (I wrote one of them), plenty of Java docs, examples, the IRC channel and one of the busiest mailing lists in open source land. I mean, how much more do you need to figure out your stuff? And for the record, there is an example that shows how to redirect to another page when in a form submit, and one single google would have given you the answer as well: setPage (how much more predictable can that be?).
Re maintainability. I agree you have to be careful for pitfalls, though even if you step into them, they are typically not huge problems. But Wicket does beat the crap out most other frameworks when it comes to maintainability simply because you can let loose all your Java tools on them for refactoring and code navigation. If you just want to get something up and running quickly, or if your site isn't terribly complicated, by all means consider other frameworks. But when you're building something complicated over a long time span where you can expect plenty of changes over time, Wicket is worth it's weight.
Open your non-wicket template file in an editor such as Dreamweaver and tell me how it looks :)
Wicket is, in my opinion, the only sane way to develop in a shop where there is a clear distinction between developer and designer. A designer can completely redesign a page if they want without "disturbing the code", that's a huge win.
You're not really comparing like with like when you're comparing it against PHP. That's not exactly fair.
Try comparing it with Spring. That has masses of documentation and yet has a much greater barrier to entry.
I haven't found a better framework for Java web applications.
Unlike the previous comments, I agree w/the author. Wicket in Action is one of few current books and it was very recently published.
And while I do like it, I just regard it as different not necessarily a framework to make me more productive.
Tapestry 5 is in the same boat when it comes to documentation (and it might just be the best framework out there), but that's another topic.
->craiger, that is not completly true. If the designer change the hierarchy of the wicket:id, I think the developer will be in trouble if no code change is done.
"->craiger, that is not completly true. If the designer change the hierarchy of the wicket:id, I think the developer will be in trouble if no code change is done."
True. But the page or component will simply fail hard. Unlike the many situations I've seen with apps where scripting is used, and where the designer decides to do little tweaks without understanding it fully, and messes up functionality in a subtle way. I'm not making this up... I've actually seen this happen with loops and conditionals and stuff that for me way back when it was one of the reasons to try to get rid of scripting.
Excelent post.
I agree with you about those reasons. Try the ZK framework (http://www.zkoss.org) and you´ll get surprised with it.
If you have any questions please feel free to contact me: gyowanny@gmail.com
Cheers
Gyo
Please don't flame this:
While wicket does a great job at component-izing your web app, I found the Apache Click framework to be the best answer for all my web app needs. Give it a try. It is component based also yet uses velocity, jsp or freemarker to hook up the java code to the page.
$form will render the entire form on the page.
$form.fields.firstName will allow you to layout the form manually.
form.setAction(..) will pick up the submit event from the page and hook it up to the onSubmit() method declared on the backing java code.
This is all you need to know to get started in one day.
rich,
Although it may not have been as explicit, I was comparing Wicket to Struts, Stripes and Ruby on Rails, too.
Wow. Very different than my own experiences, at least with Wicket you are not required (as with JSF/Facelets) to mess with various type-unsafe tag libraries and tie it all together with even less type-safe EL.
Each man has his own opinion I guess!
Casper Bang: aren't tag libs type safe? Search for the word "type" on this page: http://www.oracle.com/technology/pub/articles/cioroianu_tagfiles.html
tieTYT: Well that depends on your definition I guess. What I mean is, even if you have schema support, you will still not know what values are allowed in various attributes and it is still painfully easy to nest tags that, may be valid syntactically, but not semantically.
I suppose I have a problem with "let's put a programming language into XML". I have a similar problem with "let's put a query language into annotations".
Blogger wrote: "Compared to a framework like Struts or Ruby on Rails, Wicket probably decreased my template code by 4x but increased my Java code by 4x."
Ah, but now you have the _opportunity_ to reduce your Java code through the abstraction power of object orientation (e.g. the trivially easy construction of application-specific custom components)! Template syntax, in contrast, is simply not object-oriented and doesn't offer powerful tools for code re-use.
Of course, if you don't really understand how to use inheritance and polymorphism to avoid repeating similar logic all over the place, then keeping the program logic out of the template isn't going to help you so much.
Wanted to edit the above:
"but now you have the _opportunity_ to reduce your Java code through the abstraction power of object orientation"
But, that opportunity already exists in the other frameworks. I'm not putting business logic in my jsp's, it resides in pojos where I can take advantage of abstraction and OO. IMO, that's where the majority of your app resides, anyway.
Now, on the other hand, if you look at part 4 of my article, you'll see an example of how difficult Wicket made it for me to reuse a 3rd party app. When you talk about these _opportunities_, I think reuse is just as important.
"But, that opportunity already exists in the other frameworks. I'm not putting business logic in my jsp's, it resides in pojos where I can take advantage of abstraction and OO."
Yeah right :-) Well, most apps that I've seen, including ones describes in books use procedural service/ dao layers and flat domain object models. If there's any application where OO shines, it's the UI. A framework like Wicket lets you create - say - a tree with all it's behavior and looks and even resources embedded, that can be extended/ modified by e.g. overriding a method. This is also possible with frameworks like YUI when you go JS/ Ajax all the way. Using Struts and similar frameworks? No way you'll code anything remotely resembling neat OO code.
WRT 4... well some things require a bit more attention to integrate. In return you get reusable components, so when you implement that captcha thingy as a reusable component, you can put it in any page/ panel/ form you like without further adjustements. See for instance http://code.google.com/p/wicketinaction/source/browse/trunk/book-wicket-in-action/src/java/wicket/in/action/chapter09/jcaptcha/JCaptcha.java?r=110
"For those wondering "Why doesn't he just put it in his template and add the Java code?", that won't work: The ReCaptcha script would just generate another input field for you and cause the same problem."
And you blame Wicket for that? That's just ReCaptcha being a pita.
"And you blame Wicket for that? That's just ReCaptcha being a pita"
pretty easy with Stripes
"Using Struts and similar frameworks? No way you'll code anything remotely resembling neat OO code."
I agree... if you put all the code in the actions.
"some things require a bit more attention to integrate. In return you get reusable components"
Here's how to add ReCaptcha to a stripes webapp: http://www.stripesframework.org/display/stripes/Adding+a+captcha+(with+reCAPTCHA)
That's pretty reuseable. Just create a ReCaptcha wrapper class and delegate to it whenever you need it.
Yep, that looks fine.
wrt 2:
"You add a Label to your page that attaches to your <title> tag and overwrites the text. Duh!"
Isn't that a logical and generic solution? You put your header section in your page, and if you want that - or anything else on that page - to be dynamic, you attach a component to it. Completely intuitive if you ask me. And if you want to get fancy - say an arbitrary component overriding the page title, that's easy to... just use a header contributor. For both cases are examples in Wicket examples btw.
"Isn't that a logical and generic solution?" Generic, yes. Logical, not to me. Maybe to others and I'm just weird. I walked through my thought process on how I expected to do this.
1) there are three books available. the mailing lists are indexed by sites like nabble and markmail which make it trivial to search them. google indexes the lists also.
the wiki is a wiki - it is user-contributed thus the quality varies - i think everyone understands this and takes it for granted.
2) if you have no OO skills, which from reading this post i can clearly see you do not, wicket indeed has a high learning curve because it makes heavy use of OO principles.
you want to override a tag attribute: override the function that generates it Component#onCompoentTag(Tag tag) and use the provided tag object to modify attributes. Or use a provided convenience AttributeModifier to make this easier and shared behavior across component instances.
you want to append something to the head element: override the method that generates it IHeaderContributor#renderHeader(IHeaderResponse response) and use the provided response object to write something into the head. or use the provided convenience HeaderContributors to make this easier and shared behavior across component instances.
you want to make a component's visibility dynamic? override the method that controls it: Component#isVisible() and return true or false based on your needs.
you want to output dynamic value between some tag's you attached a component to? override the method that generates that value: Component#onComponentTagBody(..) and use the provided arguments to write out the body. Or use the convenience Label component that makes this easier.
see the pattern now?
you think php is easier? lets say i have a great include file i wrote that writes out tinymce tags for you. how do i make that include file, which is included inside a form tag write something out into the head element. you cant. i would have to provide two includes: one you have to put inside your head tags and one wherever you want the editor. sucks. so unless you can switch your mindset from top-down rendering to recursive rendering you will not grok wicket.
3) java code is more structured and thus is easier to maintain, refactor, improve, evolve, and change. the compiler for java is a hell of a lot better at catching errors early then a compiler for
markup..oh, wait, there isnt one.
> Wicket doesn't have an official list of, "Cool features that will save you tons of time" anywhere, so you'll likely have the same experience as me.
Wicket's cool feature is that all the dynamic behavior is in java code. but obviously you didnt get that.
4) apparently tons of people who have created components that integrate from yui to gmaps do not share your opinion. you can see them all in wicketstuff.org.
i bet i can create a component that elegantly integrates this javascript captcha into wicket and makes it transparent. just because you couldnt doesnt mean it is impossible. the awesome thing about wicket is that once i do it i can jar it up and anyone else using wicket can reuse it in their project with little or no effort. let me know if you want to put your money where your mouth is :)
5) why would you use wicket to generate javascript or css? wicket generates xml markup, thats it. if you do want to do this we do provide a texttemplate helper that can be used to generate dynamic text tidbits. there is also velocity panel if you prefer to use velocity for this.
6) once again, this goes back to you not having the OO skillset. there is nothing wrong with anonymous classes. the cool thing is that if you find yourself in a situation of writing the same kind of anonymous class over and over you can simply refactor an anonymous class into a top-level class and reuse it. the ide will do all the work for you.
7) i am using wicket on a project now where a designer goes into our source tree and modifies the look and feel of the website. he had to work on jsps before and now swears by wicket. this happened on a project i worked previous to this one in a different company. and the same before that. maybe you are a one-man team so you dont see the benefit.
8) agreed. stateless/bookmarkable stuff IS harder then stateful code in wicket. if you have an app that is totally stateless you should probably not use wicket. however, most apps i worked on, have only a small portion of functionality exposed as public pages, the bulk of the functionality - usually the one with a complex ui - is behind a login page where google cant index it and bookmarkability is not important. you have to choose the right tool for the job.
as a conclusion i would just like to say that: if you have no OO skills wicket will be very hard to learn and use unless you take it as an opportunity to improve your OO skills, which will make you a much more powerful developer.
I have used Wicket for more than 2 years and even blogged a few comparisons with Spring MVC, JSF, GWT and Seam. I'm genuinely interested in finding the *perfect* web-framework (if such a thing exists) but so far Wicket seems to be it. I keep looking out though - and I promise that if I find something better, I'll switch. Honest!
So I read this article with an open mind, and with great interest actually - because this is the first article critical of Wicket that I remember. Now, that's saying something for a Java web-framework ;)
IMHO the points appear contrived to me and I don't agree at all. Maybe I'll blog a detailed response later.
One question I have is did you have to use Ajax much? As far as I know Ajax support in Stripes is of the "do-it-yourself-with javascript" variety and I haven't seen any Java web-framework that beats how you do Ajax in Wicket.
For me personally, the difference between action-based (Stripes) and component-based (Wicket) frameworks is a big deal and you can find some of my thoughts here:
http://ptrthomas.wordpress.com/2008/05/26/migrating-to-apache-wicket-presentation-slides/
I'm also curious as to why you used PHP for your opening example instead of Stripes - your framework of choice. It does look a little FUD-like to me :)
You can find examples of how to use AJAX in Stripes here and here. Basically, this is how it works:
1) You use some 3rd party lib to make an asynchronous call to an action
2) That action returns/renders a normal JSP
3) You use your third party lib to place the response somewhere on the page.
Sorry, this is a simplification. I haven't done it for a while.
About PHP... To tell you the truth, I don't know anything about PHP. I just picked a random web framework to show how HTML templating usually works. Apparently everyone interpreted this as me saying, "Use PHP instead of Wicket. It's better, I swear". I was just trying to give a quick introduction to the differences of Wicket and your typical, generic Web Framework.
Igor: It's going to take me a while to reply to your response. I'm working on it. Thanks.
I didn't read the whole article, but I would like to comment on one point nonetheless: the comment about writing less code v. writing less template markup.
All else being equal, I would rather write code than markup, or XML, or whatever else. Most programming languages have IDEs that check your syntax as you type it in, many have type checking for arguments, and most have debuggers.
I understand my language of choice (Java) a lot better than I understand most web frameworks. I am more productive in a programming language than a markup language or web framework.
My choice is GWT. It isn't perfect for everything, but for simple stuff (templated dynamic content) I can use JSP with Spring MVC and GWT for those times where I want a web app, not just dynamic content.
Igor: I wrote a detailed response to your comment and posted it here: http://www.assertinteresting.com/2009/03/why-i-prefer-stripes-over-wicket/
Thanks for your reply.
It doesn't make any sense to compare a component based framework to an action/document based framework.
Choose action, flow or document frameworks based on your needs. They are really differnt things.
Cheers
Stephan
http://twitter.com/codemonkeyism
Great Post - vaannila
Well, i don't totally agree with your reasons you don't use wicket. I think wicket is one of the most great java web framework in the concept. After a lot of search, IMO there not a lot of frameworks that make a real separation between java and html .. i only found wicket and tapestry ... and the tapestry 5.1 doesn't generate valid xhtml content. In comparaison with tapestry, wicket have a lot of doc.
The only problem i found with it is to use it with DI. Wicket does not have support for @EJB annotation. I know there is the wicket-contrib-javaee in the wicketstuff repository but i seems that there is a hug bug with it or with the wicket-ioc jar: when you use ajaxified forms, it works really great ... but try to use the back button in your browser and submit again any data ... you'll see a very beautiful java exception that told about a problem with deserialization :(
That make this framework really unusable in production :s
Then build in support for those EJB annotations. I never needed it (using Spring or Guice with my Wicket apps), so I've never looked at it, but it can't be more than a few classes to implement it. Including making sure serialization exceptions don't happen, which when gone should allow you to have regular back-button behavior.
well ... as you suggested, i have converted my ejb object with a spring one.
i got exactly the same exception using a form with an ajaxbutton when i submit after click on th back button of my navigator:
Unexpected RuntimeException
java.io.InvalidClassException: net.lebonchoix.service.IAppDao; could not resolve class [net.lebonchoix.service.IAppDao] when deserializing proxy
at org.apache.wicket.proxy.LazyInitProxyFactory$ProxyReplacement.readResolve(LazyInitProxyFactory.java:236)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.lang.reflect.Method.invoke(Method.java:597)
etc ...
Hard to determine why that is without knowing more about your source code and setup. Looks to me like it is a classpath problem, maybe a container issue. Also, the fact that Wicket is trying to serialize a DAO is smelly... you should probably use a proxy there (like @SpringBean) or have another way to avoid keeping a reference to the DAO so that it isn't serialized in the first place. Try to mailing list with a good explanation (and maybe quickstart project) if you want more help.
2 florin:
Thank You very much.
I tried Click. I should say: Click is really cool!
Post a Comment