I published a stat report about this blog in February 2009, which showed 30037 unique visitors during 2008-2009. Here is the StatCounter report for 2009-2010.




There were 55,839 unique visitors, 25000 increase compared to last year. I could not write much blog posts during the last year due to frequent project releases. However which did not seem to affect my user community. This blog was started to help novice users in SOA/Web Service space and Software Quality Assurance community to share my ideas, tips and specially How-Tos. I always refrained from posting any non-technical subject matter in here. I was able to reply most of the questions raised in blog posts, however there were situations that I could not follow the comments and reply. I will try my best to continue writing much more useful blog posts and help users.

WSO2 QA Test framework has been developed to replace repetitive manual test procedures followed during the release cycles. We identified the tests which provide much ROI with automation and used them for phase1 of the test framework development project.
With the introduction of WSO2 Carbon product platform in late 2008, all java based products are implemented using the base carbon platform. All products (9 all together) are released at the same day which is a very different experience specially for a QA team. All products are supposed to go through a set of common tests and a set of product specific tests. All are supposed to work on multiple application servers, multiple JVMs, multiple browsers, multiple operating systems, multiple DBMSs etc.. hell a lot of test combinations! The product count exceeded the number of people in test team. More products are expected to be introduced in near future. Therefore, the only viable solution to manage the QA process is to automating as more tests as possible.
So, we started implementing our automated test framework in 2009 March.
As I discussed in some previous posts, we chose selenium for automation. We used Selenium Remote Control Java client driver to drive selenium tests with Junit. However our tests were not restricted to web based selenium scripts. We have written numerous tests which used Axis2 ServiceClient API and some other API methods to invoke web services, sending messages via secure channels, reliable messaging, message mediation etc.
We derived our project structure which adheres to maven as given below. You can get a SVN checkout of 2.0.3 branch of the test framework (which is the most stable version at the moment) from https://wso2.org/repos/wso2/branches/commons/qa/web-test-framework/2.0.3

common
bps
registry
wsas
esb
gs
mashup
is
ds

Each project is built using its pom.xml at the root of the project directory. We used selenium maven plugin and surefire plugin to start selenium RC server and launch Junit tests respectively.
commons project is used to maintain tests which are used in all products. For example, org.wso2.carbon.web.test.common.RegistryBrowser is common for all products since all products have a common registry browser. We used svn:externals to link the common classes to relevant projects.
You can find all common classes at https://wso2.org/repos/wso2/branches/commons/qa/web-test-framework/2.0.3/commons/src/test/java/org/wso2/carbon/web/test/common/

In addition to that, commons project is used to store the test artifacts which are shared among multiple products. For example JDBC connector jars and keystores are used in all products and those are stored in commons/lib directory.

The other most important resource included in commons project is framework.properties configuration file. It is used to configure the test framework according to the test environment. Under the "global properties" section of the framework.properties file, you could find the following properties.

host.name=172.16.37.1
http.port=9763
https.port=9443
carbon.home=/home/charitha/products/wsas/wso2wsas-3.1.3
context.root=/wsas
browser.version=firefox
admin.username=admin
admin.password=admin
module.version=2.03

You must change these properties as per your test environment settings. http.port and https.port are the embedded tomcat servlet transport ports used in WSO2 Carbon products. (full explanation of these properties will be included in a future post)

Lets look at a product specific test suite. Go to wsas directory in your test framework checkout. This is the project used to run WSO2 WSAS specific tests. You will find the following files and directories at the root of this project.

lib
src
pom.xml
runAll.sh
runAll.rb
wsas_test_suites.txt

lib directory is used to store the test artifacts specific to WSAS such as axis2 services, jaxws services etc.
You can invoke tests using two different ways.

• Direct maven invocation - you can run tests individually by passing a system property as follows

mvn clean install -Dtest.suite=usermanagement

• Run tests through a shell script - You can run tests individually or as a whole suite or few tests at once using this way. Here, it is required to uncomment the selected tests in wsas_test_suites.txt. The runAll.sh shell script read the test names from wsas_test_suites.txt and invoke each test.

sh runAll.sh

In any of the above mechanisms, we call a central test suite class which takes care of calling the individual tests. For each project we have a separate AllTests.java class which extends junit.framework.TestSuite parent. In our example, org.wso2.carbon.web.test.wsas.AllTests.java is the TestSuite.

See https://wso2.org/repos/wso2/branches/commons/qa/web-test-framework/2.0.3/wsas/src/test/java/org/wso2/carbon/web/test/wsas/AllTests.java for more details about this class.

You will also notice in AllTests class that initBrowser() method of the BrowserInitializer class is called to launch the browser instance for a particular test as follows.

public synchronized static void initBrowser()throws Exception{


if (browser == null) {
browser = new DefaultSelenium("localhost", 4444, "*"+property.getProperty("browser.version"), "https://" + property.getProperty("host.name") + ":" + property.getProperty("https.port"));
browser.start();
browser.setSpeed("200");

}
}

You can easily try out WSO2 QA test framework once you download and start using any of WSO2 Carbon based product. This is not a detailed explanation of the all features available in our test framework. I will guide you through more information in future posts. If you encounter any issues while using the test framework, please drop us a mail - architecture@wso2.org

Stay tuned.. will post more on automation soon!

If you are looking for software test automation information, you will get the best results by using Google Automation search engine. It only searches the sites that matter most to automators.

The latest product versions of WSO2 SOA platform are available for download now. This release addresses various bug fixes and enhancements. In addition to the usual binary, source and document distributions, WSO2 products are now available as cloud virtual machines.
WSO2 cloud virtual machines provides you with the ability to implement your SOA infrastructure in private or public cloud. In this post, we will look at how AMIs of WSO2 Carbon family of products can be used.
I will use WSO2 ESB AMI for the demonstration, however you can follow the same steps to start any of the WSO2 Carbon AMI.

Pre-requisite:
You should have the necessary Amazon EC2 account ready for AMI administration. AMI EC2 API tools should be installed in your computer. You may refer to this tutorial in order to set up the infrastructure.

Step 1
Go to WSO2 ESB home page in Oxygen Tank. Click on WSO2 Cloud Service under the Download icon.
You will find WSO2 ESB cloud virtual machines in that page. Take a note of AMI ID given there (ami-878569ee)

Step2
Open a shell and issue the following command to start 64bit WSO2 ESB AMI instance.

ec2-run-instances ami-878569ee -k --instance-type m1.large

Replace with the name of your public/private keypair. Read http://docs.amazonwebservices.com/AmazonEC2/gsg/2006-06-26/running-an-instance.html if you do not know hot to generate a keypair.


Step 3

The above command starts up an AMI instance with a pre-configured WSO2 ESB server. Also, the above will return the ID of the started instance (instance-id).

e.g:-

INSTANCE i-c28093aa ami-878569ee pending charithakankanamgewso2-keypair 0 m1.large 2010-02-04T06:03:25+0000 us-east-1c aki-a3d737ca ari-7cb95a

After a few seconds, issue the following command to get the public DNS name of WSO2 ESB so that we can access ESB management console.

ec2-describe-instances

e.g:- ec2-describe-instances i-c28093aa

This will return the public DNS name as follows.

INSTANCE i-c28093aa ami-878569ee ec2-174-129-86-140.compute-1.amazonaws.com domU-12-31-39-0C-21-B2.compute-1.internal

Step 4

Open a browser and access URL, https://ec2-174-129-86-140.compute-1.amazonaws.com. You will be able to log in to WSO2 ESB management console.

Recently James Bach posted a nice blog entry in which he identified logging as a good friend of an exploratory test team. I believe the comprehensive logging of AUT (application under test) is an extremely valuable asset to any tester regardless of the context of exploratory testing.
A detailed log will surely help to minimize the effort required to reproduction of issues. There are intermittent failures, random application crashes which are extermely hard to regenerate in successive attempts. If the AUT is written in a way in which all the major user events are logged, then the root causes of such random failures can be traced easily.
A comprehensive log is a useful test report. After a test run, you can store the log somewhere safely and use it as the test report. Specially, in agile test processes, test teams do not find sufficient time to record test results and maintain detailed test reports due to the short release cycles. If the AUT provides good set of logs, it will help testers to use them instead of maintaining separate test logs.

IMHO, comprehensive logging is a must have feature of any of the enterprise-scale application. At WSO2, this has been identified as a extremely important tool and the necessary modifications are in-progress to improve logging in WSO2 Carbon SOA middleware suite.

Once Azeez has written a 10 minute guide to installing WSO2 WSAS on Weblogic server. That guide explains the steps to deploy 2.X family of WSAS on weblogic. With the introduction of WSO2 Carbon platform in December 2008, WSO2 WSAS is no longer distributed as a separate war distribution. Hence, the instructions given in that document is not applicable when deploying WSO2 WSAS-3.X series on Oracle WebLogic server.
Since all WSO2 java products are built on Carbon platform, users can configure running WSO2 products on any application server using a set of components included in binary distributions. I have already explained the steps to deploy WSO2 BPS on tomcat and WSO2 WSAS-3.X on Jboss.

This post describes the steps to deploy WSO2 WSAS-3.X on WebLogic 10.3

Step1

Create a new weblogic domain by running config.sh {bat} located at WebLogic_HOME/wlserver_10.3/common/bin directory.
Lets assume the new domain is wsas.

Access your weblogic domain direcrtory and start weblogic (Go to WebLogic_HOME/user_projects/domains/wsas/bin and run startWebLogic.cmd)

Step 2
Download the latest version of WSO2 WSAS-3.X 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)

Also, create a new directory, wso2wsas and copy the WEB-INF directory located at the webapps/ROOT directory of the downloaded WSO2 WSAS-3.X to wso2wsas directory. Now, your wsas-repo should have five sub directories - conf, database, repository, resources and wso2wsas.
wso2wsas will be used as the webapp root directory.

Step 3

We need to enable SSL in weblogic server. Log in to weblogic administration console (You should have configured username and password for admin console when creating your WebLogic domain) and go to Environment --> servers. Select AdminServer.
Click on KeyStores tab. Configure keystores as shown below.



Keystore = Custom Identity & Custom Trust


Custom Identity Keystore = C:\wsas\wsas-repo\resources\security\wso2carbon.jks

Custom Identity Keystore Type = JKS

Custom Identity Keystore Passphrase = wso2carbon

Confirm Custom Identity Keystore Passphrase = wso2carbon

Custom Trust Keystore = C:\wsas\wsas-repo\resources\security\wso2carbon.jks

Custom Trust Keystore Type = JKS

Custom Trust Keystore Passphrase = wso2carbon

Confirm Custom Trust Keystore Passphrase = wso2carbon

Now, select SSL tab and enter the following values.

Identity and trust locations = keystores

Private Key Alias = wso2carbon

Private Key Passphrase = wso2carbon

Confirm Private Key Passphrase = wso2carbon


Save the configuration and go to the General tab. Select the check box next to "SSL listen port enabled".

Now we have configured the necessary changes to enable SSL on weblogic. Lets continue with deploying WSO2 WSAS on weblogic.

Step 4

Now, we should update the 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 the above wsas-repo\conf directory.
First, open carbon.xml and update the ServerURL element as follows.

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

Note that we have configured weblogic to run on 7002 port.

Update WebContextRoot element as follows.

<WebContextRoot>/wso2wsas</WebContextRoot>

Save and close carbon.xml.

Open registry.xml and update DB URL as follows.

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

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

<url>jdbc:h2: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.

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">7001</parameter>

</transportReceiver>

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

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

Step 5

We have completed the required configurations and we can deploy WSO2 WSAS on weblogic now.
First, shutdown the weblogic server instance if it is still running.
open a new command window and change the directory to WebLogic_HOME/user_projects/domains/wsas/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

Run startWebLogic.cmd

Once the server is started successfully, log in to weblogic administration console using https://localhost:7002/console
Then, go to the Summary of Deployments page and select Install.
Locate the deployment root by selecting C:\wsas\wsas-repo\wso2wsas directory. (web app root directory will be shown with a radio button option as follows.



Click on next to proceed through the wizard and continue with the default settings.
Once the deployment is successful, save the configuration and select start --> servicing all requests

Now, we are done with the deployment. You could access the management console using https:\\localhost:7002\wso2wsas\carbon

Note:-
1. In order to set the log4j logs, you may copy log4j.properties file in the extracted WSO2WSAS-3.X directory to wsas-repo\wso2wsas\WEB-INF\classes

2. If you want to deploy JaxWS services in WSAS/WebLogic platform, you should do the following configuration to avoid a class casting issue (https://wso2.org/jira/browse/CARBON-4835)

- Remove weblogic.jar/META-INF/services/com.sun.xml.ws.api.wsdl.writer.WSDLGeneratorExtension & restart Carbon

3. Also, Make sure to copy xalan-*.jar, xercesImpl-*.jar and xml-apis-*.jar from the lib/endorsed directory of the extracted WSAS binary distribution to weblogic endorsed directory before you start WSAS.

Domain hosting