Run time code coverage using Emma

Emma is a free java code coverage tool which measures and reports code coverage of java based products. The most important and usable factor of Emma is, its ability to measure code coverage during the application runtime. At WSO2, we have been searching for a tool to get QA test coverage of our middleware products. Automated QA tests are executed against the binary products. Therefore, source level unit test coverage does not help to identify the figures of QA test coverage. Emma was the best tool which satisfied our requirements.

The procedure is quite simple. Suppose you are going to get the coverage of a binary which obviously contains hundred of jars. First, you need to prepare a list of jars which requires to be instrumented. The list can be prepared easily in *nix environments as follows.

xargs -n 1 $JAVA_HOME/jre/bin/java -cp emma.jar emma instr -m overwrite -cp < jarlist.txt

This inserts tracking code to the jars listed in jarlist.txt.

Now, you should restart your application and Emma starts to gather coverage data. If you have an automated functional test suite, run it over the instrumented binary or test the product manually.

After completing the testing, stop your application. Now, we need to generate the coverage report. Issue the following command.

java -cp emma.jar emma report -r html -in coverage.em,coverage.ec

This generates an html report as shown below.





Currently, we are in the process of developing a selenium based automation framework and we use this test coverage mechanism to find out the components which require more tests.

How to deploy WSO2 WSAS-3.* on JBoss

WSO2 DOES NOT ENCOURAGE INSTALLING WSO2 APPLICATION SERVER (previously known as WSAS) ON TOP OF OTHER APPLICATION SERVERS. WSO2 HAS DECIDED TO DROP SUPPORT FOR WEBAPP DEPLOYMENT MODE OF THE WSO2 PLATFORM AND PRODUCTS.





WSO2 WSAS can be deployed on most of the application servers with a simple set of configuration steps. This post describes the steps to deploy WSO2 WSAS-3.* on JBOSS 5.*


Step 1
Download WSO2 WSAS-3.0.1 from here. Extract the downloaded zip into a directory. Copy conf, database, repository and resources directories in to a new folder. Here after, we will refer it is wsas-repo (i.e:- C:\wsas\wsas-repo)

Step 2
Lets refer to your jboss installation directory, JBOSS_HOME. Go to JBOSS_HOME\server\default\deploy directory and create a new folder, wso2wsas.war.
Now, copy wso2wsas-3.0.1\webapps\ROOT\WEB-INF to JBOSS_HOME\server\default\deploy\wso2wsas.war

Step3
We need to enable https in JBOSS. Therefore, edit JBOSS_HOME\server\default\deploy\jbossweb.sar\server.xml by editing the following entry. (This entry is commented out by default)

<!-- SSL/TLS Connector configuration using the admin devl guide keystore-->
<Connector protocol="HTTP/1.1" SSLEnabled="true"
port="8443" address="${jboss.bind.address}"
scheme="https" secure="true" clientAuth="false"
keystoreFile="C:\wsas\wsas_repo\resources\security\wso2carbon.jks"
keystorePass="wso2carbon" sslProtocol = "TLS" />

Make sure to give the exact location of wso2carbon.jks as highlighted above.

Step 4

We have done the configurations required inJBoss. Now, we must do the necessary configurations in a set of config files shipped with WSO2 WSAS. We will update carbon.xml, axis2.xml, registry.xml and user-mgt.xml which can be found at wsas-repo\conf directory.
First, open carbon.xml and update the ServerURL element as follows.

<ServerURL>https://localhost:8443/wso2wsas/services/</ServerURL>

Note that we have configured tomcat to run on 8443 port.
Save and close carbon.xml.

Open registry.xml and update DB URL as follows.
<url>jdbc:derby:C:/wsas/wsas-repo/database/WSO2CARBON_DB;create=true</url>

Now, open user-mgt.xml and update database URL as follows.

<url>jdbc:derby:C:/wsas/wsas-repo/database/WSO2CARBON_DB;create=true</url>

Make sure to specify the absolute path of the WSO2CARBON_DB in both of the above elements.

It is required to change the contextRoot in the service path of axis2.xml. Change it to wso2wsas.

<parameter name="contextRoot">/wso2wsas</parameter>

We must change the http and https ports in In Transports section of axis2.xml as follows.

<transportReceiver name="http"
class="org.wso2.carbon.core.transports.http.HttpTransportListener">
<parameter name="port">8080</parameter>

</transportReceiver>

<transportReceiver name="https"
class="org.wso2.carbon.core.transports.http.HttpsTransportListener">

<parameter name="port">8443</parameter>
</transportReceiver>

Step 6

We have completed the required configurations. Now, open a new command window and change the directory to JBOSS_HOME/bin.
Define an environment variable called CARBON_HOME and set the path to your wsas-repo directory.

In windows; set CARBON_HOME=C:\wsas\wsas-repo
In linux; export CARBON_HOME=\home\user\wsas\wsas-repo

Start JBoss from the same command window/shell.

WSO2 WSAS will be started successfully. You can access the management console using https:\\localhost:8443\wso2wsas\carbon

How to deploy a Java web service on WSO2 WSAS and secure it with Username token policy

I demonstrate how to deploy a java web service on WSAS and secure it with user name token policy.

How to preserve the original WSDL when requesting ?wsdl of an Axis2 web service

I have noticed a lot of queries in Axis2 forums on keeping the WSDL unchanged when issuing ?wsdl of a particular Axis2 web service. This can easily be achieved by setting useOriginalwsdl parameter to true in services.xml. Then Axis2 shows the wsdl file placed at the META-INF directory of service archive when requesting ?wsdl

Suppose your Axis2 service archive (*.aar) includes a test.wsdl in the META-INF directory. Now, you deploy your Axis2 service and issue http://<host>:<port>/services/?wsdl.
Then, Axis2 generates a wsdl instead of your own wsdl placed in your service archive. How do you avoid this behavior?

Open your services.xml and add the following parameter.

<parameter name="useOriginalwsdl">true</parameter>

Now you will get the original wsdl when requesting ?wsdl of your service.
Simple.. isn't it?

How to add FindBugs maven plugin to your project

FindBugs is a very useful static analyzer which inspects java bytecode for bug patterns. Static code inspection is important element in a good continuous integration process. Integrating FindBugs to your Maven build system is extremely simple as follows.

1. Add FindBugs maven2 plugin to the root pom of your maven project. You can add the plugin configuration element as a child of <reporting> element.

<reporting>

<plugins>

<plugin>

<groupId>org.codehaus.mojo</groupId>

<artifactId>findbugs-maven-plugin</artifactId>

<version>2.0</version>

<configuration>

<xmlOutput>true</xmlOutput>

<xmlOutputDirectory>C:\projects</xmlOutputDirectory>

</configuration>

</plugin>

</plugins>

</reporting>

Note: The xmlOutputDiectory is hard coded intentionally for demonstration purpose.

2. Go to the directory where the above pom.xml is placed and issue the following command.
mvn findbugs:findbugs

This will generate an XML report in the specified output directory. Here is an excerpt from such report.

<file classname="org.test.ExampleService">

<BugInstance type="OBL_UNSATISFIED_OBLIGATION" priority="Normal" category="EXPERIMENTAL" message="OBL: Method org.test.ExampleService.archiveFile(String, String) may fail to clean up stream or resource of type java.io.InputStream" lineNumber="69" />

<BugInstance type="OBL_UNSATISFIED_OBLIGATION" priority="Normal" category="EXPERIMENTAL" message="OBL: Method org.test.utils.ArchiveManipulator.extract(String, String) may fail to clean up stream or resource of type java.io.InputStream" lineNumber="114" />

<BugInstance type="OS_OPEN_STREAM" priority="Normal" category="BAD_PRACTICE" message="OS: org.test.utils.ArchiveManipulator.extractFromStream(InputStream, String) may fail to close stream" lineNumber="148" />

-------

<BugInstance type="RV_RETURN_VALUE_IGNORED_BAD_PRACTICE" priority="Normal" category="BAD_PRACTICE" message="RV: org.test.utils.ArchiveManipulator.extractFromStream(InputStream, String) ignores exceptional return value of java.io.File.mkdirs()" lineNumber="124" />

</file>

Thats all! For more information about plugin usage and configuration parameters, havea look at the plugin home page.

Automated testing of wso2 products using Selenium

I have never been a fan of open source UI test automation tools due to the annoying issues of majority of them. Most of the tools provides you with a good first user experience however fails when try to use in advanced use cases. At WSO2, we have been looking for a test automation tool during the last few years. Due to the tight release schedules, we were not able to focus much on researches.
At the end of 2008, WSO2 started to build its SOA product suite based on revolutionary Carbon platform and a new JSP based UI framework has been designed. When I got the initial builds of new WSO2 carbon products, I was curious about the possibility of automating user interface. I tried with one of the tools which we have tried once but never got a chance to continue working on. That is, Selenium! For me, it is the best open source tool I have used so far in my career.
After the releases of WSO2 carbon based products, we have started to automate UI and functional use cases using Selenium. We are making a rapid and steady progress so far with this great tool.

We use Selenium RC with Junit. All the test are written using Junit. WSO2 products are built using maven2 and eventually our test framework will be integrated to build system. We have already used maven selenium plugin and surefire plugin to integrate our tests with maven. With the power and high flexibility of Selenium we are in a good position of cross browser testing.

While automating the product UIs with selenium, we had to overcome some blocking issues but thanks for the materials available in openQA forums and some nice blogs, we were able to resolve most of them. I'd appreciate Selenium team for their great vision and innovativeness of developing such a helpful free web automation tool.

Adding BPEL features to WSO2 WSAS/ESB

A few days back, WSO2 has released carbon feature packs which allow users to integrate various functional components into their existing WSO2 products. I blogged about plugging in service hosting components into ESB while we were preparing for carbon release. With the carbon feature packs, now it is much more easier to add the functionalities what you want.

WSO2 BPS provides the facilities to execute business processes written using the WS-BPEL standard. BPEL feature pack enables the business process management inside your WSO2 WSAS or ESB instances.
Let's see how BPEL features can be added to WSO2 WSAS or ESB.

Pre-requisites:
Install WSO2 WSAS-3.0.1 or WSO2 ESB-2.0.1

Step 1
We are hoping to install BPEL features into WSAS or ESB. Therefore, download BPEL feature pack from here.

Step 2
Unzip the downloaded feature pack into a directory in your file system (suppose it is $BPEL_feature_pack_home)
You will see two sub directoris inside the extracted zip file, plugins and repository.

Go to $BPEL_feature_pack_home/plugins/ directory and copy all the jars to WSAS_HOME/webapps/ROOT/WEB-INF/plugins/ directory. (WSAS_HOME is the root directory of your WSO2 WSAS instance)

Then, go to $BPEL_feature_pack_home/repository directory and copy the contents to WSAS_HOME/repository.

Step 3
Restart WSO2 WSAS and access management console. You will see the BPEL features shown in the left menu as follows.



Thats it. We have installed BPEL features into WSAS. You could follow the same steps to install BPEL features into WSO2 ESB.