1. Using the latest and greatest versions of everything.  Eclipse 3.4.  Hibernate 3.3.1.  Spring 2.5.6.  Tomcat 6.  Maven 2.0.9.  Java 6 ( 7? ), DWR 3.0.
2. Using Eclipse plugins to do as much as possible without causing headaches
3. Using as little XML configuration as possible – conventions, conventions, conventions!!!
4. Using JPA annotations for ORM classes.
5. Using Annotations for IOC dependencies.
6. Using Annotations for Transactional demarcation.
7. Using Annotations for MVC mappings.
8. Using very basic JSTL-based JSP’s for views.
9. Using Sitemesh to present a uniform look and feel across all pages.
10. For icing on the cake I’d like to also include GWT components.

Using the latest and greatest versions of everything
If you install Eclipse 3.4 first, and then install the Maven Integration plugin, it will greatly simplify things.  Just add Maven Integration to your project and then use “Add Dependency” option to quickly scour the entire repository and find the exact groupIds, artifactIds, and versions you want.  It also has a great view of the dependency hierarchy!  Getting all of these bleeding-edge versions to play nice together has its fair share of challenges.

Using as little XML configuration as possible

Using Eclipse plugins to do as much as possible without causing headaches

I already mentioned Maven Integration above to help with getting the LAGV of all the technologies being used.  Also of great value and import are SysDeo and  Subclipse.  Sysdeo is great for deploying and debugging your webapp in Tomcat.  Subclipse is great for seamless integration with an SVN repostiory.  Yes – use SCM on personal projects, you never know when you’ll need to revert or bring the code down onto a new machine.

But where do we draw the line here?  When do we have so much annotation cruft that an externalized xml configuration will seem like the ideal solution ( from whence we currently come in search of clarity! ).

Using very basic JSTL-based JSP’s for views
OK – well, tonight I was getting ready to put together the first couple of jsp’s now that the @Controller mappings are working and the pages are being served correctly.  I’ve got the method mapped correctly with @RequestMapping and I’ve got the model being put into pagescope with @ModelAttribute.  I’m ready to loop through a List using JSTL forEach.  But wait, can this possibly be true?  Tomcat6 has no implementation of JSTL.  JSTL 1.2 is the LAGV and the JSTL 1.1 is abandoned.  Only *Glassfish* ships with the reference implementation of JSTL 1.2?!?  Oh brother.  Thanks to Peter Mularien for writing a nice post informing me of this.

As if needing to download and install glassfish in order to get the JSTL 1.2 implementation jars for Tomcat6 wasn’t bad enough, well I hit a couple more snags after that.  First of all, I want to know who decided on the namespaces for JSTL 1.1 vs 1.2.  Here they are:

1.0  == <%@taglib prefix=”c” uri=”http://java.sun.com/jsp/core” %>

1.1 & 1.2 ==<%@taglib prefix=”c” uri=”http://java.sun.com/jsp/jstl/core” %>

I mean all they did was add the “jstl” into the path?!?  I’m supposed to remember this?  OK – I’ll try harder to remember for next time.

Then, I learned that Maven2 doesn’t copy “system” provided jars into WEB-INF/lib by default and they need to be placed there manually as part of the project.  So, the appserv-jstl.jar I copied from glassfish wasn’t being included because I linked Maven to it as a system ( vs provided, or compile, or test, etc… ) dependency.

Connection Pool Showdown

These results completely reinforce the fact that the expensive settings %F, %L and %C should not be used in your production environment. In the unfortunate case that you use all of them, then you’re looking at ( already expensive ) logging calls taking 9 times longer, verging on millisecond timings.

Log4J Conversion Patterns

JVM Version 1.6.0_05-ea
Windows XP[x86] – 2 processors
5.46MB/63.56MB Memory

But, then, how long does the individual usage of the perpetrators cost? I ran that one, too. Here are the results:

%l is the most expensive conversion pattern. On average it takes an extra 140,000 nanoseconds.
%C is the next most expensive, taking about 110,000 nanoseconds longer.
The rest ( %M, %F, %L ) each take about 100,000 nanoseconds longer.

Now you know.

Log4J Conversion Patterns

Freemarker vs Raw Java

JVM Version 1.6.0_05-ea
Windows XP[x86] – 2 processors
4.99MB/63.56MB Memory

So how bad is it…drum roll…

Class[10] indicates the pure Java method running a 10 Thread test. FTL[20] indicates the Freemarker test running a 20 Thread test. And so on… Results are listed from best to worst with the avg and max results in nanoseconds.

Class[10]: 1000100 trials, 18046 avg, 67973245 max 1.0x
Class[80]: 1000800 trials, 28960 avg, 104784259 max 1.6x
Class[20]: 1000200 trials, 30387 avg, 106770756 max 1.7x
Class[60]: 1000200 trials, 35917 avg, 96320112 max 2.0x
Class[40]: 1000400 trials, 37220 avg, 162898182 max 2.1x
FTL[10]: 1000100 trials, 293093 avg, 104114975 max 16.2x
FTL[20]: 1000200 trials, 587117 avg, 158432568 max 32.5x
FTL[40]: 1000400 trials, 1204641 avg, 190966244 max 66.8x
FTL[60]: 1000200 trials, 1843190 avg, 284686324 max 102.1x
FTL[80]: 1000800 trials, 2498693 avg, 358187778 max 138.5x

The last piece of info on each line is how much slower that particular test was ( on average ) than the fastest. Notice how the pure Java tests don’t jump right into the crapper when under load. But the FTL tests get progressively worse as the thread counts are increased. Under an 80 thread load, not only is the pure Java way 138 times faster on average, but the FTL way has max time of 358 milliseconds vs a 104 millisecond max for pure Java. This is a perceptible 250 millisecond difference when rendering a single button tag!

The case for easing up on the Freemarker templates is solidifying

When should a template engine be used? There seem to be two answers to this question which both carry equal weight with developers. They are:

1. You want to have an easily editable version of your dynamic view. This will allow easy customization.
2. You want the representation to be easily readable to future developers. This will keep it understandable and maintainable.

Now, this might seem like a minor point to pick at. But bear with me…

So, how much faster is pure java than freemarker templates? Well, this is going to depend largely on the complexity of the template. As an example, I’m going to pick a template of medium complexity that renders an HTML button tag in a consistent fashion. The output will be very simple and we’ll have a lot of HTML attributes that can be set within the template. Here’s the ftl file:

button.ftl

————————————–
[source:xml]
<@compress single_line=true>
<button <#if id?exists>
id=”${id}”
</#if>

<#if name?exists>
name=”${name}”
</#if>

<#if value?exists>
value=”${value}”
</#if>

<#if accesskey?exists>
accesskey=”${accesskey}”
</#if>

<#if classname?exists>
class=”${classname}”
</#if>

<#if style?exists>
style=”${style}”
</#if>

<#if title?exists>
title=”${title}”
</#if>

<#if href?exists || onclick?exists >
onclick=”
<#if href?exists>document.location.href=’${href}’;</#if>
<#if onclick?exists>${onclick}</#if>
”
</#if>

<#if ondblclick?exists>
ondblclick=”${ondblclick}”
</#if>

<#if onmouseout?exists>
onmouseout=”${onmouseout}”
</#if>

<#if type?exists>
type=”${type}”
<#else>
type=”button”
</#if>

<#if disabled?exists && disabled == ‘true’ >
disabled=”disabled”
</#if>
>
<div>
<div>
<#if icon?exists>${icon}</#if>

<span>
${content}
</span>
</div>
</div>

</button>
</@compress>
[/source]
It outputs something along the lines of :
[source:xml]
<button id=”buttonId” style=”buttonStyle” onclick=” alert(’hi’); ” type=”button” > <div> <div> <img src=’pretty.jpg’> <span> This is required </span> </div> </div> </button>
[/source]

Now, is this a good place to use a template like the above? The answer is Yes. But, as with most things, only in moderation. Or perhaps the answer is actually a definite maybe?

So, what can the downside be?

Speed.

Having just benchmarked this I have an unfair advantage, but the raw Java implementation that spits out the same exact templating logic presented above in button.ftl runs over 15 times faster.

Running 1000 trials of button.ftl (FTL) vs ButtonTemplate.java (Class) gives me the following results ( in microsecond timing ):

FTL 419033 micros
Class 31828 micros
Class is 13 times faster!

With only 100 trials:

FTL 15888 micros
Class 834 micros
Class is 19 times faster!

So, back to the moderation. Nobody is going to notice if a couple of buttons are rendered in 1 microSecond instead of 15 microSeconds, that’s for sure. But, if your entire page, overtime, has been rewritten to do absolutely everything using FTL, and the page ends up taking a second to load. Well, then, a 15x speed increase would get that page out in less than a tenth of a second.

I ran these tests with Freemarker 2.3.10 and then again with 2.3.12 and got the same results, so the optimization they added in 2.3.11 doesn’t seem to affect this type of simple usage ( using maps ).

Here is a screenshot showing the intense framework supporting the Freemarker template engine. Notice how the pure java class ( highlighted in blue ) just goes about its business directly.

So, back to the two reasons to use an FTL template.

1. You want to have an easily editable version of your dynamic view.
2. You want the representation to be easily readable to future developers.

Well, in regards to #1, I don’t think we really need to have an easily editable version of our <button> tag. I mean, really, a button’s a button’s a button. It might keep growing for a while, gathering more attributes and complexity over time, but I don’t think we’ll ever need to plug in a custom version for a different client.

As for #2, I don’t think the java code is really that much more difficult to read, and since we won’t be needing to change this (because it’s a button, for christ’s sake!) template that often, why take the speed hit here?

Here, btw, is the code for ButtonTemplate.java ( w/o Javabean boilerplate )
————————————————————————-
[source:Java]
public void render( Writer out ) throws IOException {
out.write( “<button” );
if ( id != null ) writeAttribute( out, “id”, id );
if ( name != null ) writeAttribute( out, “name”, name );
if ( value != null ) writeAttribute( out, “value”, value );
if ( accessKey != null ) writeAttribute( out, “accesskey”, accessKey );
if ( className != null ) writeAttribute( out, “class”, className );
if ( style != null ) writeAttribute( out, “style”, style );
if ( title != null ) writeAttribute( out, “title”, title );

if ( href != null || onClick != null ) {
out.write( ” onclick=\”" );
if ( href != null ) {
out.write( “document.location.href=’” );
out.write(href);
out.write(”‘;”);
}
if ( onClick != null ) {
out.write( onClick );
}
out.write( “\”" );
}

if ( onDblClick != null ) writeAttribute( out, “ondblclick”, onDblClick );
if ( onMouseOut != null ) writeAttribute( out, “onmouseout”, onMouseOut );
if ( type != null ) {
writeAttribute( out, “type”, type );
} else {
writeAttribute( out, “type”, “button” );
}
if ( disabled ) {
writeAttribute( out, “disabled”, “disabled” );
}

out.write( ” > <div> <div> ” );

if ( icon != null ) {
out.write( icon );
out.write( ” ” );
}
out.write( “<span> ” );
out.write( content );
out.write( ” </span> </div> </div> </button>” );
}

[/source]
Now, I mentioned the torrid love affair we’re in at work. Well, we are using a whole lot more FTL to simply render HTML elements : inputs, labels, selects, buttons, checkboxes, creditCards, datePickers, dropDowns, addresses ( which use the previous elements ) and even style and javascript includes. So, in conclusion, since Freemarker is the artsy smartsy way to do things and it will be used wherever and whenever possible once it takes root – I implore you to only use it where/when it is truly needed. That is, for large views that are truly complex and for views that will be frequently customized. For the simple cases, it’s just not worth the hit.

Time to go refactoring…perhaps…

Afterthough::: If only the freemarker templates would compile into java bytecode, then this would probably be a nonfactor. JSP’s can do it. Is anyone up to the task?

Well, here’s a fairly in-depth overview of both with pros and cons and similarities and differences included.

The first thing to note is that if you’re not in a multi-threaded environment, then DBCP is going to be faster than C3P0 and will also use significantly fewer connections than C3P0. For example, using the default settings for each and sizing the pool to contain 50 connections at most, will yield results like the following single-threaded test.

Single-threaded Benchmark – 50,000 calls to getConnection()

Suffice it to say that DBCP is obviously better suited to Single-threaded applications with high load. Needing 50 connections in the pool to do the work where only 1 is needed is certainly not desired. This is the case with C3P0’s default setting of “numHelperThreads=3″. Regardless of the environment you have ( single-threaded, multi-threaded ) I would always change this setting if you forsee high load on the program. I would always use at least “numHelperThreads=5″. As a bit of background/explanation, C3P0 doesn’t actually make a connection available in the pool when it is checked-in. Instead the HelperThreads will detect these and do the work to get them back in the pool. This is great in high-load, multi-threaded environments as it avoids blocking issues. But it inherently requires a much larger number of connections to provide the same functionality ( especially if you keep “numHelperThreads=3″ ). Also, notice that DBCP is 20% faster regardless of how we tweak numHelperThreads.

Score 2 points for DBCP. 2-0.

Next what if we run the same test with a smaller connection pool size – say of only 5 connections, and numHelperThreads=3 for C3P0?

The results are a bit counterintuitive ( to me at least ). DBCP does at least manage to stay the same – very fast and reasonable ( needing just 1 connection in its pool ). But C3P0, which I expected to take longer because it previously needed all 50 connections, but actually runs faster with a smaller pool : 6.25 seconds down from 6.7 seconds. The lesson here is that C3P0 is slowing itself down with the HelperThreads having to manage all the extra connections to get them back in the pool.

Score 1 point each. DBCP for making sense and C3P0 for speeding up.

3-1, DBCP in the lead.

Now for the good stuff – the multi-threaded tests. I’ll be varying the number of Threads which will be running.
Multi-threaded tests

Score yet another to DBCP. Faster across the board on all accounts. So, what is it about C3P0 that has everybody ( myself included ) using it and singing its praises? Multiple threads yield multiple points again for DBCP – 2 points awarded.

5-1, C3P0 will need a miracle comeback at this point.

I know, usually Connections aren’t just checked out and run with a small SQL statement and immediately returned like the Benchmarks I’ve been running. Maybe I need to put some delay in there to more closely mimic real world performance. I’m going to throw a new setting in here which is a delay in milliseconds that each call to getConnection() will endure before finishing with the connection. I’ll give it a shot with an extra 100ms of sleep time after each SQL statement is run.

Multi-threaded – 100ms of sleep time added

acquireIncrement=5 default(3) Batching the retrieval of Connections is wise because the process of opening a Connection is expensive. Why do it 5 times instead of once? The downside to this is that you may only need the one connection. Read on to maxIdleTime settings to make sure idle connections make their way back into the pool.

maxIdleTime=3600 default(0) Setting the maxIdleTime to a non-zero value permits C3P0 to remove Connections from the pool and freeing up database resources. This will never happen when maxIdleTime is set to 0. Setting to a small value might have Connections being retrieved and returned on too frequent a basis to be practical, so I’ve picked 3600 seconds ( 1 hour ) as a nice happy medium. Once the peak traffic is over, then the connections can be returned.

maxIdleTimeExcessConnections=300 default(0) You need to set this in addition to maxIdleTime to have the Connections removed from the pool and returned to the DB.

maxPoolSize=100 default(15) You’ll have to fine tune this setting base on your own individual situation, but it’s important to keep this on the largish side for the simple reason that C3P0 doesn’t synchronously return connections to the pool. The implication of this is that the pool should actually be sized slightly larger than what you think the maximum number of Connections needed at peak time would be. For more on this, see numHelperThreads.

minPoolSize=20 default(3) This one too can be fine tuned based on your individual needs, but let’s just say that you don’t always want to be returning all your Connections and having to reacquire new ones. 20 is a good size to allow for handling of new bursts of sporadic traffic w/o having to reacquire them.

numHelperThreads=6 default(3) This is a very important property if you’re going to have large bursts of traffic on your site. C3P0 ( as was alluded to previously ) doesn’t return connections to the pool synchronously and as a result doesn’t have the same issues with blocking that DBCP has. However, as a result, Connections are not made available until some arbitrary time after they are returned to the pool. C3P0 has helperThreads which are responsible for doing the actual return work and making them available. Under large load I’ve experienced times where these spikes could require 400 Connections using the default setting of 3. Using 6 HelperThreads will keep this spike under 100 connections. If you can afford the connections or won’t have huge loads on the system, then the default of 3 will probably be fine for you.

unreturnedConnectionTimeout=3600 default(0) I’ve set this to 1 hour. If a Connection is used for longer than an hour, then C3P0 will assume it’s been orphaned and will reclaim the Connection to the pool – closing it in the process.

It should be noted that the elusive activation.jar and mail.jar from J2EE 1.4 were used to get the above to compile and run. When I tried using the JEE5 libraries, I didn’t have a POP3 implementation and got “JavaMail – NoSuchProviderException: No provider for pop3″ exceptions.

Here’s a code snippet that will show you all of the providers you have available to you:


Properties props = new Properties();
Session session = Session.getDefaultInstance(props, null);
Provider[] p = session.getProviders();
for (int i=0;i System.out.println(p[i].getProtocol());
}


I get back the results: imap, pop3, smtp.

So, basically everything ( apart from the WebApplication itself ) in Wicket is a Component. Now the Wicket Component is no slouch; it’s a 3,000+ line abstract class with loads of functionality built right in. I’ll dig into this base class later, but for now, let’s focus on the two immediate subclasses of Component: MarkupContainer and WebComponent.

MarkupContainers include things like: WebPage, RedirectPage, Form, FormComponent, FormComponentLabel, Button, CheckBox, TextArea, and TextField.

WebComponents include things like: Image, Include, Label.

I’m surprised, initially, to find controls such as Button, CheckBox, TextArea and TextField as MarkupContainers and not as WebComponents.

Also of interest is that subclassing is used to achieve behavior that might seem best placed in attributes of some of the classes. For example, to create a hidden input field, I might expect to create a TextField instance and set its visible property false. Instead, TextField is subclassed as HiddenField. This is also true for adding password characteristics (PasswordTextField) or making the input required (RequiredTextField). This same pattern of subclassing is used most thoroughly for Links ( AjaxFallbackLink, BookmarkablePageLink, DownloadLink, PageLink, PopupCloseLink, and ResourceLink ).

So, there’s a very rich Component-Model existing within Wicket for creating all the elements you’ll need on a web page, but where does the web page come from? For this we look to another subclass of MarkupContainer. The class WebPage is the primary analog to a conventional webpage. So much so, that the Wicket convention is actually to sit an HTML file of the same (prefix) name as the (simpleName) of the Java class extending WebPage. That is, if you were to write a new class called FunPage like this:

package org.javatech.wicket.examples;
class FunPage extends WebPage {}


Then you would have an HTML file named FunPage.html located in org/javatech/wicket/examples which would contain the HTML used in rendering the webpage.

Cool.

But this is still a bit too abstract – should we really bother writing (yet another) Hello World application for Wicket? No – there are plenty of them out there. Instead, let’s discuss how the Components get added to the WebPage and then how the HTML is able to provide the layout used to create the desired web page. And since every website since the beginning of time has forms on it, let’s show how to add a form.

Adding a form using Wicket Components and a Wicket WebPage:

When I think of an html form, my mind drifts towards thoughts of Maps where the form element’s names are the keys and the values entered by the user are the corresponding values. Then there are just a few other lingering details like the form’s name, whether to use POST or GET, and to what URL the form data should be sent. Having isolated the Component Form as the candidate for the job, I’m immediately stunned by the Constructor which takes an id and/or an IModel. The id makes sense. I mean, really, every html element should have one. But what on god’s green earth is an IModel? I know one thing, it’s an interface – score one for the I-school of thought! Upon inspection, it turns out that an IModel is simply a wrapper for a model object used by a component. It provides methods to get/set the actual model object and to drill down into a nested model object. This being learned, I see that it isn’t required for such humble beginnings as just getting a form to work and shall be forgotten for at least two days now.

So, our first form will be called DemoForm and starts out on the Java side as:

package org.javatech.wicket.pages;

import wicket.markup.html.WebPage;
import wicket.markup.html.basic.Label;
import wicket.markup.html.form.Button;
import wicket.markup.html.form.Form;
import wicket.markup.html.form.TextField;

public class DemoForm extends WebPage {

public DemoForm() {
Form f = new Form( “myForm” );
f.add( new TextField( “myTextField” ));
Button button = new Button(”mySubmitButton”);
f.add( button );
f.setDefaultButton( button );
add( f );
}
}
Which should look something like:

When I start Wicket and hit the URL, I get an exception, because I haven’t created the appropriate HTML file.
WicketMessage: Markup of type ‘html’ for component ‘org.javatech.wicket.pages.LandingPage’ not found

So, it turns out that you need to have EVERY component added in the Java represented in the corresponding HTML. In this case, the HTML would need to contain:

<form wicket:id="myForm">
<input wicket:id="myTextField" />
<input type="submit" wicket:id="mySubmitButton"></button>
</form>


So I gotta admit that my Spidey-sense is tingling at this point. This has the potential to grow quite ugly – having to manage the same essential layout in both Java code and in the HTML. More on that later – so, now my form comes up and works.
I can type into the textbox and click on the button. When I do click on the button, however, I’m taken to a urHell:
http://localhost:8080/hello_wicket/?wicket:interface=:24:myForm::IFormSubmitListener – SAY WHAT?

So, enough suspense. Here are the remaining hoops that Wicket requires you to jump through:
1) You must have a backing model object for your form.
2) You must explicitly implement onSubmit() on the Form object being used.
3) The onSubmit() method will ( in Java code! ) specify the response page for the form.
4) You must (manually) pass the model object to the Confirmation Page.

We’ll have a new class called DemoFormModel defined as:


package org.javatech.wicket.pages;

import java.io.Serializable;

public class DemoFormModel implements Serializable {

private String myTextField;

public String getMyTextField() {
return myTextField;
}

public void setMyTextField(String myTextField) {
this.myTextField = myTextField;
}
}
An instance of DemoFormModel will be instantiated in the constructor of DemoForm and will then be passed ( in the new onSubmit() method ) to the DemoFormConfirmation WebPage. DemoForm now looks like:


package org.javatech.wicket.pages;

import wicket.markup.html.WebPage;
import wicket.markup.html.form.Button;
import wicket.markup.html.form.Form;
import wicket.markup.html.form.TextField;
import wicket.model.CompoundPropertyModel;

public class DemoForm extends WebPage {

public DemoForm() {
Form f = new Form( “myForm” ) {
@Override
protected void onSubmit() {
DemoFormModel o = (DemoFormModel)getModelObject();
DemoFormConfirmation landingPageSubmission = new DemoFormConfirmation( o );
setResponsePage( landingPageSubmission );
}

};
f.setModel( new CompoundPropertyModel( new DemoFormModel() ));
f.add( new TextField( “myTextField” ));
Button button = new Button(”mySubmitButton”);
f.add( button );
f.setDefaultButton( button );
add( f );
}
}
The Java and HTML for DemoFormConfirmation look like:

DemoFormConfirmation.java

package org.javatech.wicket.pages;

import wicket.markup.html.WebPage;
import wicket.markup.html.basic.Label;

public class DemoFormConfirmation extends WebPage {

public DemoFormConfirmation(DemoFormModel o) {
this.add( new Label( “myTextField”, o.getMyTextField() ));
}
}
DemoFormConfirmation.html

You entered:<span wicket:id="myTextField"></span>


So, in a mighty big nutshell, we needed to create 5 files to pull off a simple form submission and confirmation:

DemoForm.java, DemoForm.html, DemoFormModel.java, DemoFormConfirmation.java, and DemoFormConfirmation.html.

DemoForm specifies the form, the components on the form, the model object the components will bind to, and the form’s onSubmit() method. The onSubmit() method is responsible for retrieving the model object, instantiating the DemoFormConfirmation instance with that object, and finally redirecting to that instance.

Then, DemoForm.html needs to reference the components added in DemoForm.java by the same String id’s and DemoFormModel.java needs to have properties which match these names. DemoFormConfirmation.java and DemoFormConfirmation.html have the same sort of coupling but on a smaller scale ( 1 field only ).

The big lesson here is that naming conventions are super important and having a reliable, predictable mechanism for coming up with wicket id’s is going to be essential. Fortunately, there are numerous ways to do this with the simplest being a ModelObject first driven development cycle. Once your ModelObject is created, then it’s fieldNames should be used verbatim in both the Components added on the Java side and the wicket:id’s in the HTML.

I’m not particularly excited about hardcoding site navigation inside of onSubmit() methods in Java code. I’ve been completely brainwashed that this should be configurable behavior, but I’ve seen configurable behavior become a royal pain in the butt and am willing to entertain this backward seeming restriction. Besides, there are way to dynamically wire this stuff together if one is determined to do so ( custom code at this point in time ).