Question

I am making an application in which I want to integrate Wicket + Spring. Application is a grocery store on which user comes and buy something. I know there are two ways to do this.

1. Using the annotation aprroach. Wicket-Spring integration shows various ways on how to inject Spring Beans into Wicket pages.

   public class FormPage extends WebPage
   {
     @SpringBean
     private IContact icontact;
     ...
     Form<Object> form = new Form<Object>("contactForm",
        new CompoundPropertyModel<Object>(contact))
     {
       private static final long serialVersionUID = 1L;
   
       protected void onSubmit(Contact contact)
       {               
         icontact.saveContact(contact);
       }
     }; 
   

2. The @SpringBean is of course valid and considered a best practice by many. But there is also another approach, where your Wicket Application has the services you need.

   public class YourWicketApp extends WebApplication{
     public static YourWicketApp get(){
       return (YourWicketApp) Application.get();
     }
     private ServiceA serviceA;
     // getter and setter for serviceA here
   }
   

   Now in your component, call

   YourWicketApp.get().getServiceA();

I want to know which is the best way to integrate spring with wicket and what are the drawbacks in each case.

However as far as I remember Wicket pages and components aren’t managed by Spring container so you cannot use @Transactional annotation on them (which is a bad idea anyway – transactions belong to deeper levels). Is this statement valid?

Answer 1

There are certain advantages and drawbacks for the different options. The different options are explained here. Personally, I prefer the annotation-based approach, since it guarantees proper detaching of the annotated fields and reduces the components’ dependency on the application object.

1. Using @SpringBean

The @SpringBean annotation is nice. It is guaranteed that the fields marked with it will not be serialized with the components. I.e., the Wicket framework “manages” the beans by nullifying the fields in each detach cycle so you don’t have to worry about it.

The fields marked with @SpringBean are easily testable, since you can always replace them with mocks. Wicket even has a ApplicationContextMock class from which the beans will be injected when using WicketTester:

MyComponent.java

public class MyComponent extends Panel {
    @SpringBean
    MyServiceA myServiceA;
}

In MyComponentTest.java

final ApplicationContextMock appContext = new ApplicationContextMock();
appContext.putBean(mock(MyServiceA.class));
Application app = new Application() {
    public void init() {
        ...
        getComponentInstantiationListeners().add(new SpringComponentInjector(this, appContext));
    }
}
WicketTester wicketTester = new WicketTester(app);
wicketTester.startComponent(MyComponent.class);

2. Using YourWicketApp.get().getServiceA()

This is a quite lightweight approach, since it does not require binding Spring to your web application. If you’re not building a large-scale application, this might be a feasible alternative.

The major drawback of this approach is poor testability. Since you’re accessing the application statically, you are not able to replace the application easily in tests. Of course, you can write an application YourWicketAppForTeststhat extends YourWicketApp, but you will always be restricted to that application. By doing this, you are creating a dependency from each of your service-dependent components to the application class. Furthermore, you would need a method for each of your service classes, which would add to the clutter of your application class (which, usually, is not too short in the first place).

3. @Transactional

The transactions definitely don’t belong to the Wicket pages and should be handled in the service layer. Since it is Wicket and not Spring that is handling the injection of beans and component instantiation, the @Transactional annotations would not work, anyway, if I’m correct.