Charitha's Web Log

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-ExtrasL...

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...

I have been away from blogging for more than 2 months. Many of the readers of this blog, asked me if I stopped writing or what. The last few months were hectic due to a many reasons. First, I moved to Bloomington , a beautiful small town in Indiana, USA from my home country, Sri Lanka . Thus, I had to focus on many initial settlement stuff which allowed me very little time to scan through my blog. Next, I had to spend time on adjusting to the totally new environment specially crazy coldness in here. I believe I'm back in business now. As the tag line of this blog says, "no nonsense", only SOA and testing. Therefore, I'm not going to write about what is happening around me. I will continue sticking to the objective of this blog. Helping at least one person who is stuck figuring out an answer for a problem related to Service-Oriented architecture, enterprise integration or software testing.