X

Geertjan's Blog

  • April 5, 2006

Wicket + Glassfish + JAX-WS + NetBeans = Wow!

Geertjan Wielenga
Product Manager
In yesterday's blog entry I wondered aloud why a Wicket user would want to use a 'heavy' application server like Glassfish. Partly my answer was provided in the comments to that blog entry—there Davy De Durpel writes that he's been happily using EJB for persistence with Wicket over Glassfish. Personally, I'm a lot more comfortable with web services than with EJBs (although, now that EJBs are going to be incredibly simplified, maybe I should give them a chance). So, I reimplemented this NetBeans tutorial, replacing JAX-RPC with JAX-WS and servlets/JSPs with Wicket's Java classes and HTML files. And here's the result—a Wicket application that consumes CDYNE's SpellChecker web service:

So, what happens is this: you enter some text in the text area, you click Submit, the text is sent to the web service, which interprets it, and then you use the web service's methods to work with the returned text. For example, the web service has a method called "getSuggestionCount()", which returns the number of suggestions for a wrongly spelled word.

To me, Wicket fits perfectly in the Java EE 5 paradigm. Why? Because Java EE 5 is all about simplification. Take a look at JAX-WS for example (which is nothing more than version 2.0 of JAX-RPC, its predecessor): no entries are needed in deployment descriptors and, instead, you use annotations within the Java code. Also, the implementation that NetBeans generates used to consist of three files—an endpoint interface, an implementation class, and a weird little configuration file. Now, all you get is one file to work with. (Of course, there's a lot of stuff under the surface, but that's exactly where it belongs, not right in your face to confuse and frustrate you.) Similarly, Wicket removes XML files from your development world. Completely. No struts-conig.xml, for example.

Further, Wicket totally separates Java from HTML. When I first started thinking about this blog entry, I was thinking of calling it: "Forget servlets! Wicket rocks!" (That's basically the subtitle of this blog entry, albeit slightly hidden.) Take, for example, a look at the servlet in the tutorial (here). The heart of any servlet is the processRequest method, which spews out an HTML file. When you look at the Wicket version of the SpellChecker client, the first thing you notice is that HTML is found in the HTML files and Java is found in the Java files. Logical, yet oddly unique in the programming world. The only link between the HTML and the Java files is a placeholder tag in the HTML, which has a matching name in the Java file.

As a result, all the formatting is done in the HTML file (which makes perfect sense). This, for example, is the "Report Card" part of the screenshot above (notice that the only parts that are unfamiliar are the <wicket:id> bits, which, despite that, is perfectly well-formed HTML code within the <span> tag):

<span wicket:id = "comments" id="comments">
<p><font color="red"><b>Report Card:</b></font>
<br>
Entered text: <font color="red"><span wicket:id = "text">Entered text goes here.</span></font><br>
Number of wrong words: <font color="red"><span wicket:id="no_of_wrong_words">Number of wrong words goes here.</span></font>
(first is "<font color="red"><span wicket:id="one_wrong_word" class="even">One wrong word goes here.</span></font>")<br>
Number of suggested replacements: <font color="red"><span wicket:id="number_of_suggestions">Number of suggestions.</span></font>
(first is "<font color="red"><span wicket:id="one_suggestion">One suggestion goes here.</span></font>")<br>
</p>
</span>

Finally, would any of this be possible without Glassfish? No. And that's the point. Is there any application server out there, other than Glassfish, that supports JAX-WS? Anyone? Feel free to contradict me. So, by integrating web services into (for example) Wicket applications, you leverage a whole layer of functionality that you yourself don't have to provide. Of course, you better make sure that the functionality you use is reliable and doesn't drop out of the sky in the middle of the night (such as some of the web services I've used in tutorials in the past, aaaargh). But, personally, I would highly recommend CDYNE's web services. They're great and super fast.

So, basically, apart from using EJBs in Wicket applications (see comment at end of yesterday's blog entry for details), you can now also use the highly simplified web service architecture provided by the JAX-WS specification. Which in turn means that you're using... Glassfish.

Join the discussion

Comments ( 4 )
  • jiga Tuesday, July 4, 2006
    Would you like to share code out?
    And, as the WicketBench(of Eclipse) is continuously go forward.

    the netbeans' coordinate should be updated and put all the signality samples and nbwicketsupport together(preferring as the jmaki plugin).

    So, you should re-organize your sample projects in order to synchronize with the latest libraries automatic( Wicket1.2 for example).

    Otherwise, as time went by, your efforts is wasted because most of code are outdate.


    best.
  • jiga Tuesday, July 4, 2006
    Would you like to share code out?
    And, as the WicketBench(of Eclipse) is continuously go forward.

    the netbeans' coordinate should be updated and put all the signality samples and nbwicketsupport together(preferring as the jmaki plugin).

    So, you should re-organize your sample projects in order to synchronize with the latest libraries automatic( Wicket1.2 for example).

    Otherwise, as time went by, your efforts is wasted because most of code are outdate.


    best.
  • Geertjan Tuesday, July 4, 2006
  • guest Wednesday, January 31, 2007
    testing
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.