Monday, August 31, 2009

How to add a Log4j Appender to WSO2 Carbon

1) Write a java class and extend AppenderSkeleton. Add the logic to the append(LoggingEvent e) method.
public class JiraAppender extends AppenderSkeleton {
protected void append(LoggingEvent loggingEvent) {
if (loggingEvent.getLevel().toString().equalsIgnoreCase("INFO")) {
System.out.println("INFO invoked!");

public boolean requiresLayout() {
return false;

public void close() {

2) Modify the file located at

a) Add the following entry to the file.
# CARBON_JIRA is set to be a MemoryAppender using a PatternLayout.
log4j.appender.CARBON_JIRA.layout.ConversionPattern=[%d] %5p - %x %m%n

b) Update the file with the following entry.

Sunday, August 23, 2009

Building OSGi bundles using Maven Bundle Plugin

I came across a good article by Sameera on "How to build OSGi bundles using Maven Bundle Plugin". It gives detailed infromation on how to use maven bundle plugin to generate OSGi bundles. In this blogpost, I will demonstrate how a sample can be run. If you are hungry for more information read the above article.

1) Download and extract the samples.

2) Build the sample01
mvn clean install
3) Download Equinox.
eg: org.eclipse.osgi_3.5.0.v20090520.jar

4) Run the jar file using following command.
java -jar org.eclipse.osgi_3.5.0.v20090520.jar -console
5) In the command prompt execute following command.
osgi> ss
Framework is launched.

id State Bundle
0 ACTIVE org.eclipse.osgi_3.5.0.v20090520
6) Install the bundle
osgi>  install file:/home/heshan/Documents/Work/OSGi/maven_bundle_plugin_samples_0/sample01/target/sample01-1.0.0.jar
Bundle id is 1

osgi> ss
Framework is launched.

id State Bundle
0 ACTIVE org.eclipse.osgi_3.5.0.v20090520
1 ACTIVE org.wso2.mbp.sample01_1.0.0
7) Use the following commands to start and stop the bundles.
osgi> start 1
Hello World!!!

osgi> stop 1
Goodbye World!!!

Tuesday, August 18, 2009

Building WSO2 Carbon from source

You can use following steps to successfully build, WSO2 Carbon from source;

1. Checkout commons. Then build caching, eventing, throttle, xkms modules.

2. Build carbon.

3. Build carbon-orbit.

4. Build synapse.

5. Build rhino.

6. Build carbon-components.

Monday, August 17, 2009

Second "First Day" @ WSO2

Today was my first day at WSO2. I joined as a Software Engineer. This was in fact my second "first day" at WSO2. My first "first day" was in February 2008, when I joined WSO2 as an undergraduate intern.

Sunday, August 16, 2009

Good Bye UCSC

Past week was my last week at UCSC. I had my final year project defense last week and it was the last commitment that I had towards my university. The only other thing that we have to do is organize the Research Symposium. It will be held on 25th August.

UCSC had been my second-home for last 4 years and have some wonderful memories associated with it. It groomed me of becoming the person that I am today and I am forever grateful to University of Colombo and UCSC.

GSoC: Experience

This was my second consecutive year as a Google Summer of Code student. During past 3 months I learned a lot of things. I discussed these in an earlier posts. In a nutshell;

1) I worked with a mentor (Matt Boersma) from a different time zone. This was the first time that I worked with a mentor from a different timezone. Our time difference was nearly 12 hours. We preferred email over chat since it was more conveinent for us.

2) It was a privilege to work as a summer of code student for Python Software Foundation (PSF). All the people who were mentoring me helped me a lot, ranging from shaping up the application (project proposal) to development.

3)It was a greatopportunity for me to work with experienced developers.

I would like to take this opportunity to thank my mentor Matt Boersma and Jython community for helping me to make my project a success. I would also take this opportunity to thank my co-mentors Jim Baker and Frank Wierzbicki.

I would like to state that it was a privilege and a honor to be selected as a GSoC student for a second time and thank Google for organizing a program like this. I am looking forward to participating in next year's GSoC as a mentor. :)

Saturday, August 15, 2009

GSoC: Update

During the development phase, I came across some problems. This is a follow up to my earlier posts. You can have a look at them here.

1) One problem is the way the API is designed to define the XML payload. I designed the WSF/Jython API in such a way that it is comparable with the WSF/Ruby implementation. Therefore WSF/Jython API should adhere to the API specified by WSF/Ruby.

When generating code using Axis2's code generation framework, you should generate it in a such a way that it should support XML object model(preferably in the case of axis2 - apache axiom). Therefore it would be better if the API supported axiom, inorder to use the code generation part. Consider the following example.

from org.wso2.wsf.jython.jythonwsclient import *

req_payload_string = "<deduct><var1>1.8</var1><var2>4.87594</var2></deduct>"
LOG_FILE_NAME = "/home/heshan/IdeaProjects/MRclient/src/python_client.log"
END_POINT = "http://localhost:8070/axis2/services/annotationScript/deduct"

client = WSClient({}, LOG_FILE_NAME)
req_message = WSMessage(req_payload_string, {"to" :END_POINT})
print " Sending OM : " , req_payload_string
res_message = client.request(req_message)
print " Response Message: " , res_message

except WSFault, e:

In above code snippet, the payload is set as a string. i.e.

req_payload_string = "<deduct><var1>1.8</var1><var2>4.87594</var2></deduct>"

What should be done is to keep the above feature intact with the API and do a feature addition that will support Apache Axiom.

2) Therefore, the existing WSF/Jython codebase should be modified to support axiom for Jython (should look into this further).

3) Modify the existing codebase to include the code generation part. Having said that there should be more work done to seamlessly integrate this(code-generation part) to WSF/Jython code. More coding have to be done on code generation module for Jython.

4) In a earlier post I said of modifying the Python deployer to support Contract First approach. This happens in the server-side code generation. It's a problem that I am still having.

5) In the same post I said that
0nly generate the client code and use the existing WSF/Jython's client API. Then before running the client code you can add the WSF/Jython client-side jar to the class path.
Now it seems like the best option out of the two options mentioned in the above post.

[The above arguments are my opinions and may subject to change.]