Skip to end of metadata
Go to start of metadata

Apache Wicket - web site

The tutorial is almost finished. We have to design the web page that we will use to consult the incidents published in the database. The web framework that we will use is Apache Wicket.

Step 1 : Web pages

To display the incidents in a web page, we will create the file HomePage.html in the directory src/main/java/org/apache/camel/example/reportincident. This file contain html tags with some wicket tags. One of the benefit of Apache Wicket compare to other web frameworks is that it try to keep the html page as clean as possible to facilitate the work of the web designer and integration with code made by the developers. It is a component framework like JSF but not based on programmable page like JSP, ...

Remarks :
(1) - The tag wicket:id="message" is used to display top of the screen a message
(2) - The tags <td> are enriched with parameter wicket:id="" to allow to the wicket code page to replace this property with the property field of the Incident class.

Step 2 : Web page code


Remarks :
(1) - The @SpringBean annotation is used to inject our spring IncidentService service
(2) - To set the message label of the HomePage.html, we call the method add(new Label()) and set the property "message" with the information that we want to display on the screen 'List of incidents coming from web services or file'
(3) - To populate the table of the web page, we will use a DataView object. The DataView class requires as a parameter a IncidentDataProvider which is in fact an inner class implementing the interface IDataProvider.
(4) - The class IncidentDataProvider will call our IncidentSaver service to retrieve from the database the list of Incidents reported.
(5) - The populateItem method of the DataView will map the content of our incident objects with the attributes (= items) of the web page


To tell to the Apache Wicket framework that our application contains the page HomePage.html and class HomePage (1), we will create the class WebApplication in the directory src/main/java/org/apache/camel/example/reportincident) like this.


To inject Spring into Wicket, we have used the approach described on the following web site of Apache Wicki documentation and added the line addComponentInstantiationListener(new SpringComponentInjector(this)); into the class (2)

Step 3 : web.xml configuration

Now that the code/web pages are ready, we have to create the web.xml file in the directory src/main/webapp/WEB-INF

Remarks :

(1) - Wicket applications have a global application object which is a subclass of Application. This global application object is only created once per application and is never serialized (since it contains no user-specific data and thus remains the same across all nodes in the cluster). These qualities make it a good candidate to act as a service locator for the rest of the application. Wicket allows you to provide a custom factory for creating this object, the wicket-contrib-spring project provides such a factory (SpringWebApplicationFactory) that, instead of creating an instance, pulls it out of the spring application context. Wicket keeps the instance of the application object in a threadlocal variable and provides various helper methods in components to get to it, so it is easy to retrieve dependencies in wicket components.
(2) - Spring DM provides a dedicated, OSGi-aware, web application context (called OsgiBundleXmlWebApplicationContext) that offers the same functionality and behaviour to its Spring-MVC brethren, XmlWebApplicationContext. The application context is aware of the web application BundleContext and thus is able to load resources from the OSGi space, import and export OSGi services and support the BundleContextAware and component scanning across the bundles included in the classpath.

Step 4 : Add spring stuffs

To allow our web bundle to have access to the osgi (1) service org.apache.camel.example.reportincident.service.IncidentService, we have to add the following line in the file called applicationContext that we create in the directory src/main/webapp/WEB-INF.

Step 4 : Adapt the pom.xml file

The pom of this project is different from the bundles projects because :
(1) - the packaging here is war and not bundle,
(2) - The MANIFEST.MF file generated must be copied in the WAR
(3) - we must tell to maven that the plugin in charge to generate the MANIFEST.MF file must be called during the goal/phase : process-classes
(4) - we want to define the web application context <Webapp-Context> who will be published by PAX Web

Remark : To deploy the war in your maven repository, execute the following maven command


One big advantage of the approach followed here is that the web application will not be packages with the jar required in the lib directory but only with the classes/pages/... which are part of the application. The jar required by the Web Application must be deployed separately on the OSGI server. Another positive aspect is the clear separation between the front layer from the service/persistence layers. Our application uses OSGI services which are injected in the configuration. So you are no more dependent of a big WAR/EAR file as it was the case with monolithic J2EE applications (wink)

Build and Package the application


To build the project, you must execute the following maven command in the root of the installation directory :


To simplify our deployment procedure, we will use the provisioning mechanism of Apache Felix Karaf called 'Feature'. In a feature xml file, we will define the bundles that we will package and their dependencies. The bundles can be linked to a feature and features can be linked together. This file will be packaged in a jar.

The advantage of the feature is that you avoid to deploy manually your bundles in your OSGI server and they can be versioned as you will see in the file. Moreover, the feature can be seen as a contract between your development and the deployment team. Different versions can be created according to the environment where the code will be deployed (development, acceptance and production).


If you prefer to generate automatically the file based on the dependencies of yours pom, then you can use the maven plugin maven-features-plugin

Create the file reportincident.features-1.0-SNAPSHOT-features.xml in the directory src/main of the project reportincident.features

Remarks :
(1) - The reportincident feature has the number version 1.0
(2) - Each feature is a collection of bundles or bundles/features. The bundle tag contains the URI syntax used by PAX URI to install the JAR or the resource on the OSGI server. We us the mvn protocol to download the jar from Maven repository but other protocols exist (see OPS4J for more info)
(3) - The camel feature include a list of camel-xx features.

To generate the jar file containing the feature xml file, adapt the pom.xml like this :

During the execution of the following maven command :

maven will put the file reportincident.features-1.0-SNAPSHOT-features.xml in the jar and the jar will be installed in your Maven local repository under the directory {{localMavenRepository/org/apache/camel/example/reportincident.features/1.0-SNAPSHOT


The deployment process is very simple and two steps will be necessary :

Step 1 : Copy properties files in etc directory

Copy the files containing your properties file org.apache.camel.example.reportincident.datasource.cfg, ... in the etc directory of Apache Felix Karaf and customize them if required

Step 2 : Edit the file org.apache.felix.karaf.features.cfg

To use the feature file created in the previous section, we must adapt the file org.apache.felix.karaf.features.cfg that you find in the etc directory

Replace the current featureRepositories line with the following :

This line will be processed by PAX Url who will pickup the reportincident.features-1.0-SNAPSHOT-features.xml file from the jar located in the maven repository localMavenRepo/org.apache.camel.example/reportincident.features/1.0-SNAPSHOT


replace the existing line containing the featuresBoot parameter


By adding these two lines, we will configure our Apache Felix Karaf server to install bundles from features defined in the order appearing at the line of featuresBoot


The deployment order of the bundle is critical in an OSGI environement. This is why for the purposes of this project/tutorial we have organised in consequence. If you plan to change something in the application, be aware of that


The /etc/system.property file must be modified to define the environment variable servicemix.base used by activemq bundle

Add the following line

Test it

Step 1 : launch application

It is time to launch the karaf server and to test if our application works well. If this is not yet done, download Apache Felix Karaf 1.4.0 server and install it. Launch the server by executing the command in the bin folder:


If this is the first time that Karaf is started, then you will see that a new data folder is created. This directory will contain subfolders :

  • cache : containing the bundlles deployed
  • log : where the log file is updated by the application

Step 2 : Check osgi list

When the following prompt appears on the screen :

execute the command :


During the first launch of Karaf, it will install all the bundles defined in the features (one by one) in the order defined. 134 bundles must be deployed, so be patient because it can take time depending of your internet connection, cpu, processor of your machine.

but after a few minutes, you must see the following list


If errors happen during installation of the bundles, the list could be not completed. In this is the case, the feature provisioning system has stopped the installation. You have to check the log file of karaf and depending of the error reported, correction made, the installation can be relaunched in the menu 'feature' using the command :

If a problem occurs with a bundle, you can by example recompile the code, regenerate the jar and update the bundle using the command

where xxx corresponds to the bundle to be updated

The features list can also be very helpfull to see which features has been installed

Step 3 : Incident file

To test the Camel routing, we have to produce an incident file report and put it in the file defined in the from uri of your inittial route. Create a file containing csv lines :

Save your file and copy it in the folder

Check the log of SMX and you must see something like this


Next, open the web page of your application : http://localhost:8080/reportincidentweb/

Step 4 : Call a webservice

You can use the tool Soapui to call the web service of the application.

Use the following url from Soapui, to generate the client interface to communicate with the web service : http://localhost:8080/cxf/camel-example/incident?wsdl.

Call the web service with the request : http://localhost:8080/cxf/camel-example/incident
and the following SOAP message request by example :

Check the Karaf log :


and web screen result : http://localhost:8080/reportincidentweb/


Well, this tutorial was a little bit long but we have tried to provide you all the required information to design a real application using Apache Camel, Felix Karaf, OSGI, CXF and Apache Wicket frameworks. We hope that we have reached the goals defined in the introduction and will continue to improve its content based on Apache frameworks evolution. A part which is not covered but we plan to add it in the future concerns the testing/debugging of the application and transactional aspects.


  • Name Size Creator Creation Date Comment
       Drag files from your desktop onto your browser or select files by clicking "Browse"
  • No labels