Tuesday, April 28, 2009

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

Friday, April 24, 2009

Thursday, April 23, 2009

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?


Saturday, April 4, 2009

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.

Thursday, March 26, 2009

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.

Thursday, March 19, 2009

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.

Thursday, February 19, 2009

Performing QA with last minute code changes




Changes are inevitable at the last moments of most projects. There are urgent requirements to do such changes and there will be situations where you
must do some critical fixes before shipping the product. In any case, both development and QA teams must be in a common understanding on how such changes affect the stability of the AUT (Application under test).
Sometimes, it will be required to repeat a complete functional test cycle after a significant change. In such cases, sufficient time must be allocated to do a full round of functional testing.
Or else, everyone (both development and QA) should take the responsibility if something goes wrong.
It is a common practice in most organizations to transfer responsibility to QA teams when clients find issues in a product after a release, which is not always valid in agile processes where everyone test and contribute to quality assurance regardless of their title/role playing in the project.
After doing a significant change at the last moment without providing enough time to complete the testing on affected areas, there is no point to blame QA. Everyone should take the responsibility.
This is one of the weird situations most QA teams come across regardless of the process being followed. With better understanding about the tasks and responsibilities of each other, project teams can avoid these concerns. Otherwise, rigid hard core processes must be followed although they are not always realistic.
After all, each team member should understand that QA is not a trivial activity. It takes time and effort to setup and configure test environments, uncover bugs, reproduce them in different platforms, report through defect tracking systems, verify the reported bugs in new builds, ensure the issues are not regressed.
A few months back, Krishantha posted a nice blog entry about how last minute changes affect software QA testing which is a good reference for anyone interested in this.