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
Step 2 : Web page code
To tell to the Apache Wicket framework that our application contains the page HomePage.html and class HomePage (1), we will create the class
To inject Spring into Wicket, we have used the approach described on the following web site of Apache Wicki documentation and added the line
Step 3 : web.xml configuration
Now that the code/web pages are ready, we have to create the
(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.
Step 4 : Add spring stuffs
To allow our web bundle to have access to the osgi (1) service
Step 4 : Adapt the pom.xml file
The pom of this project is different from the bundles projects because :
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
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
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
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
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
Replace the current featureRepositories line with the following :
This line will be processed by PAX Url who will pickup the
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
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
If this is the first time that Karaf is started, then you will see that a new
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
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.