Monday, April 29, 2013

Customize the height of header div of Docbook Webhelp in Docbook 1.78.1

Recently, I've been getting some queries on how to change the height of the docbook webhelp html output. This has been straight forward in the previous releases where, where you just change the CSS height property of #header, #content, and #leftnavigation. But starting from Docbook xsl release of 1.78.0, you need to do an additional change to get it working because of the introduction of left panel resize handler.

The left panel resize handler is a feature introduced with 1.78.0 to let the users resize it as they wish in case the contents of left navigation panel is not completely visible. {webhelp-dir}/template/common/splitterInit.js .  There, we divide the webhelp output in to main three sections. the 

  • North pane - #header
  • West pane - #sidebar
  • Center pane - #content

Then, it gives you the ability to add resize handler to the edges of these three panes. In the case of webhelp, we have suppressed the ability of users to resize the north pane, and kept only the left pane resizable. I believe the reasons are obvious. So, that's a little intro about the resize handler. 

Now, if you want to customize the header, first you need to few modifications to this file. Here, I'm explaining how to change the height of the #header.

  • First, open {webhelp-dir}/template/common/splitterInit.js
  • Look for the attribute north__minSize in that file. Currently, it has the value 99 which is in pixels. This values over-rides the #height css property in positioning.css. So, change this value to a height you like. 
  • Change the the height of #content, and #leftnavigation appropriately.
You might want to replace the header-bg.png with a wider image too.

Friday, April 26, 2013

Highlights of WSO2 ESB 4.6.0 Documentation

With WSO2 ESB 4.6.0 release, we have seen lot of improvements in several areas including the Passthru transport which provides far better performance compared to the NIO transport. The comparison include the latest ESBs of Talend, Mule and WSO2 ESB 4.5.1 vs WSO2 ESB 4.6.0. We have chosen to do the benchmark on two different WSO2 ESB versions to show the performance gain we have received. You can find the architectural details at Hiranya's blog How the World's Fastest ESB was Made.

While these were, one of the complains WSO2 had was the lack of documentation. Some of the cool features go unnoticed because of this, and people have faced some difficulties finding what they want. So, after the release of Carbon 4.0.0 release, WSO2 has given special attention on getting the documentation right. We have held several documentation hackathons, discussions and we I believe we have come up with a decent set of documentation now.

WSO2 promotes the documentation in the means of the WSO2 documentation site, WSO2 OT knowledge-base articles, blogs etc. This time, we have focused on our official documentation site,

So, I wanted to share the highlights of the documentation of WSO2 ESB 4.6.0. It shows the capabilities of ESB with examples covering quite a lot of use-cases of any given features with examples. We still have a lot to write, but I guess we have come a long way so far.

The ESB 4.6.0 documentation is located here -

We can first start with the FAQ page -
This is a good starting page to know whether WSO2 supports a given feature, where we can find the performance numbers, introduction to common components of ESB like endpoints, mediators, sequences etc.

REST Support
With WSO2, you can have REST support using either proxy services, or the rest api. Each of these are explained with a message flow diagrams, sample configuration proxy/rest-api, sample request, and response.

JMS Support
Explains how to use JMS with ActiveMQ, QPid, or the wso2 in-house AMQP implementation, Andes, with WSO2. Under the JMS usecases section, you will see that the common scenarios are covered.

SAP Integraion -
Describes integrating SAP systems with WSO2 ESB

Clustering WSO2 ESB - Worker-Manager separation with ELB
Explains how to setup the WSO2 worker-manager separation fronted by WSO2 Elastic Load Balancer.  Has detailed info on each of the configuration that needs to be made.

The Samples Guide
The usual samples guide

ESB Monitoring
Covers the JMX Monitoring, Monitoring the mediation, transport, system statistics among others.
In addition to this, you can integrate WSO2 Business Activity Monitor (BAM) with WSO2 ESB, and see the detailed statistics employing MapReduce technologies. You can find more info here -

Performance Tuning

Hope the above are useful.

Thursday, April 25, 2013

Run soapUI via Command-Line in Linux

I always wanted to run soapui load tests via command line because then I could run it on a remote machine that I SSH to. I don't want to run it on my machine because it slows down the machine considerably, so I can't do my day-to-day work with it. That will also affect the result of soapui.

Recently, I wanted to re-produce a OOM issue in WSO2 ESB. So, the setup was, the ESB instance was running on one server, soapui load tests, JConsole, and JProfiler on my machine. So, I only wanted to keep the monitoring softwares, ie. the JConsole, and JProfiler in my machine, and move the soapui tests to another server instance. It turned out this is actually pretty simple.

First, start up the soapui gui interface, and save the project you already have. If you don't have one, create a new one, and set all the load tests parameters appropriately. These include setting the soap message, no. threads, time limit etc. Let's save it as myProxy-test-soapui-project.xml.

This file, myProxy-test-soapui-project.xml, contains all the necessary information regarding the project. It include the WSDL file, the endpoints, load test info etc. This makes it easier run the same test on another machine. You just have to transfer this file. Then you can run the command in a terminal with soapui in place.

  • Transfer the saved soapui project file to the server where you wish to run the load tests. ex. scp
  • Download soaup from here - I got -
    • Let's called the extracted folder of this as $SOAPUI_HOME
  • Copy the following command, and change it to match your needs.

sh $SOAPUI_HOME/bin/ -s"TestSuite Name" -c"Testcase name" -l"LoadTest name" -r -f/home/kasun/load-tests/reports/ /home/kasun/load-tests/myProxy-test-soapui-project.xml

Here, the names can be easily copied from the project hierarchy from the left-side Navigator tab.
Example command look like the following. Run it with nohup, so the process won't be killed if you disconnect from the server. 

sh /home/kasun/load-tests/soapui-4.5.0/bin/ -s"myProxySoap11Binding TestSuite" -c"myProxySoap11Binding TestSuite" -l"LoadTest 1" -r -f/home/kasun/load-tests/reports/ /home/kasun/load-tests/myProxy-test-soapui-project.xml

Tuesday, April 23, 2013

Generating p2-repo for custom WSO2 Features, and Components

Here, I'm going to discuss how to generate a p2-repo for custom, user-written WSO2 components, and features. This can be easily achieved using the maven plugin, carbon-p2-plugin, that WSO2 have written.
First, you may have a look at Creating-your-own-wso2-carbon-components webinar to know how to write carbon components, and a feature for those components. It covers quite a lot of basics, and best practices as well.
Now, to install these features to WSO2 products like WSO2 Enterprise Service Bus, you need to generate a p2-repository. Then, you can add that p2-repo via the "Feature Management" utility in management console, and install the features you want. p2-repo concept comes from the underline Eclipse equinox project that WSO2 products use. In the following I will tell you how to generate a p2-repo for your features.
  • Simply create a new maven project (packaging: pom)
  • Add carbon-p2-plugin as a maven plugin
  • Then set the features you want to publish under the carbon-p2-plugin plugin configuration as shown in the following sample pom.xml.  
  • This sample pom.xml was copied from the p2-repo generation pom.xml of carbon 4.1.0, and I simplified it for clarity.
  • There are two sample feature definitions I have specified. Replace those featureArtifactDef with your own feature definitions. The format is $groupId:$artifactId:$version.

I have tested this pom file, and it worked for me just fine. 
When you build this via maven, maven creates the target/p2-repo directory. This has the p2-repository which contains the complete p2-repo including artifacts.jar and content.jar. You can just use this folder to install features, or you can host it somewhere. There're no special requirements on hosting.

<project xmlns=""


    <name>WSO2 Carbon - Feature Repository</name>


<!-- change the featureArtifactDef to match your needs -->