Charitha's Web Log

After nearly a decade of inactivity, I thought to revive my blog. I created this blog in 2006 while I was a core contributor to Apache open source projects. In those days when social channels like YouTube and Stack overflow were not readily available for software developers to assist in technical subject matters, bloggers like me became reference materials for open source software troubleshooting. Some posts in this blog generated 1k+ daily hits and tech enthusiasts reached me via various channels and engaged in productive discussions.   I quit contributing to open source software since I joined Amazon in 2014. Since then, I was not active in the blogosphere primarily because of the proprietary technologies that I have been using at Amazon and the restrictions on sharing confidential information. Over the last 8 years, I advanced my career at Amazon by transitioning from an individual contributor to Engineering Management role. In this process, I gained a wealth of experience in workin

Occasionally, you will get requests from legacy client applications that do not include HTTP Content-Type header. WSO2 ESB proceeds with the mediation flow only after building the relevant SOAP infoset using the message builders registered against the Content-Type of the incoming request. In case the Content-Type is blank, you will experience an error similar to the following in the log. ERROR - RelayUtils Error while building Passthrough stream java.lang.StringIndexOutOfBoundsException: String index out of range: -1  If modification of client applications to include the mandatory Content-Type HTTP header in POST requests is out of your control, we should be able to set a default content type for such incoming requests. In WSO2 ESB, you can use the following property to set a default Content-Type for the incoming requests in case the HTTP request does not have Content-Type header. i.e:- <parameter name="DEFAULT_REQUEST_CONTENT_TYPE" locked="false&

There are various types of post processor elements that we can use out of the box when handling responses in a JMeter test plan. For example, Regular Expression Extractor can be used to capture a specific value or set of values from a XML, HTML or JSON response. However, handling JSON responses through the default regular expression extractor will be a daunting task when the JSON response becomes complex. When handling complex XML responses, Xpath extractor is the obvious choice in JMeter. Similarly, it will be quite efficient to have a similar post processor element to handle complex JSON responses. JSONPath is a way to extract parts of a given JSON document and is now available in many programming languages. In this simple post, we will look at how we can use JSONPath expressions to extract values from JSON responses in JMeter. Pre-Requisites: Download and install JMeter version 2.8 or later Step 1 Download this JMeter plugin library and unzip JMeterPlugins-ExtrasLibs-

In the third post of the common mistakes to avoid in WSO2 Carbon platform blog series, I'm going to look at another frequently raised question.  I have been struggling to get rid of this issue for few hours recently and figured out the fix by consulting one of my colleagues, Nuwan Let's look at the problem in detail. Problem Suppose I'm calling a REST API hosted in WSO2 API Manager with a set of query parameters as shown below. GET http://192.168.1.10:8280/qa/1.0/GetData?name=charitha&city=colombo HTTP/1.1 In order to match with the GET URL/query parameters, I define the url-pattern in API publisher as shown below. Note**** We cannot define a uri-template in API publisher UI in the latest version of API Manager (At the time of writing, it is API Manager 1.6.0). However, the specified url-pattern, /GetData/* does not match with the request URL since my API call contains a set of query parameters. Thus, I open the API configuration file which

This is the second post of common mistakes blog series which I'm planning to share with you. In this post, we are looking into another common mistake which we do when working with WSO2 Carbon platform. Registry mounting is a way of federating the registry space across multiple servers in a product cluster. For example, if you have a WSO2 ESB cluster, you can use a single registry space to store all configuration data common to cluster nodes. There are 3 different registry spaces provided by each WSO2 Carbon product; local, configuration and governance. You can find more details about these spaces in here . We have to keep in mind a few important concepts when building a shared registry setup. You cannot share the local registry space among multiple cluster nodes. The local registry space is used to store node-specific data hence it should not be shared among other nodes in the cluster. However, we mistakenly do this when configuring shared registry setups and experience many

In the next few weeks, you could expect a series of blog posts from me which explain the remedies to avoid some common mistakes which we do when working with WSO2 ESB . This is the first of many. During the initial rounds of testing your integration solution or even in production systems, you may have come across the following error. org.apache.axis2.AxisFault: The system cannot infer the transport information from the URL .... Some of you may have struggled hours figuring out a solution to address this issue. Let me explain this error in detail and possible causes of this. So, next time when you see this error in your WSO2 ESB setup, you will not have to spend time unnecessarily googling everywhere. There can be many different causes of this error. I have observed  four main reasons. Cause 1 This is the simplest cause. Suppose, you have a proxy service similar to the following. <proxy xmlns="http://ws.apache.org/ns/synapse" name="MistakesTest&q