Wicket with Java EE 7

I’m currently working on a quite big Java EE project. Started on Java EE 6 I decided to switch to Java EE 7 when it was released. I got the question on Twitter how we used Wicket with Java EE 7. Long story short. We use CDI to glue all parts together of EE. To get Wicket working with Java EE is the wicket-cdi module the most important module.

I will show you here an example.

First download Glassfish 4 server.

Now we can create a project. We will use Wicket Quickstart archetype. Run the following command

mvn archetype:generate -DarchetypeGroupId=org.apache.wicket -DarchetypeArtifactId=wicket-archetype-quickstart -DarchetypeVersion=6.10.0 -DgroupId=nl.turabdin.blog -DartifactId=wicket-javaee -DarchetypeRepository=https://repository.apache.org/ -DinteractiveMode=false

After we created the project we can add wicket-cdi and Java EE 7 api dependencies. Add following block to dependencies in pom.xml


javax
javaee-api
7.0

Add the wicket-cdi-1.1 dependency to the project to support CDI 1.1 which is used in Java EE 7, I’ve started this project, this project is a fork of wicket-cdi-1.1 in wicket, but I ported it to Wicket 6.x. I’m planning to change some parts to make it more lightweight again. I’ve found some issues if you’re using the beans (share a module (jar library) over different projects and deploy these web project to same Glassfish instance. I’m not sure if this is a Weld or Glassfish or wicket-cdi bug. I’m figuring it out.


com.github.javawithmarcus.wicket-cdi-1.1
wicket-cdi-1.1-weld
0.3

I’ll post another blog post for some advanced features of the wicket-cdi-1.1 plugin.

To make the plugin work you have to change the web.xml, open src/main/resources/webapp/WEB-INF/web.xml. You have to change the filter class. Change

org.apache.wicket.protocol.http.WicketFilter

to

com.github.javawithmarcus.wicket.cdi.CdiWicketFilter

Now you can deploy to Glassfish 4. Any component (page, panel etc) will be injected by wicket-cdi-1.1. You can use the @Inject annotations. For objects that are constructed manually (like models etc) you have to put

CdiConfiguration.get().getNonContextualManager().inject(this);

in the constructor to make injection work.

From this CDI context (CDI beans) you can access other Java EE API’s like JMS easily.

I’m working on more parts of how to integrate Wicket in Java EE container.

2 thoughts on “Wicket with Java EE 7”

  1. Nice post, I should try this out some time. How does Wicket CDI handle injected dependencies in relation to the stored state? Are references set to null, or are they lightweight and portable across storage?
    I particularly wonder about models, since they have their deps injected manually.

    1. Hi Pepijn, This is just a bridge between CDI and Wicket. It will depend what kind of bean you’re injecting. We mainly inject managers, these beans are application scoped. CDI will most of time create a proxy to resolve the instance (ApplicationScoped means 1 instance per application). These proxy classes are serializable and small, thus these will travel to the page state. We didn’t encounter any problems with these proxy classes.

      You can do a lot of tricks with it, like ConversationScoped bean or RequestScoped. Also if you look at the Weld project (CDI reference implementation) you can see a lot of other handy features.

Leave a Reply

Your email address will not be published. Required fields are marked *