Friday, July 31, 2009
UCSC Research Symposium
A gallant display of research prowess awaits unveiling as the country’s premiere Computer Science and Information Technology research community stages the biggest event of the year - the UCSC Research Symposium 2009. With the memories of the inaugural UCSC Research Symposium in 2008 that revolutionized the undergraduate Computer Science research in Sri Lanka, the University of Colombo School of Computing (UCSC) expands this year’s event into new bounds, embracing cutting-edge research in both quantitative and qualitative disciplines.
Date:
Tuesday, 25th of August 2009
8.00 AM to 5.00 PM
Venue:
Prof V.K. Samaranayake Auditorium,
University of Colombo School of Computing,
Colombo 7,
Date:
Tuesday, 25th of August 2009
8.00 AM to 5.00 PM
Venue:
Prof V.K. Samaranayake Auditorium,
University of Colombo School of Computing,
Colombo 7,
Sri Lanka
Friday, July 10, 2009
GSoC: How to integrate with existing code base
This post will contain my arguments on "How to integrate this project to the existing WSF/Jython code base". This is a followup to my last post.
1. Modify the Python deployer to support Contract First approach.
2. To support Contract First approach you need to be able to generate a skeleton and a message receiver for your service. The generic message receiver that I have already written may not work because it works only on a limited schema structure.
3. Another way to look at the above argument(2) may be; only 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.
The above arguments are my opinion(for now) on integrating the gsoc code to existing code base. The above arguments may subject to change.
1. Modify the Python deployer to support Contract First approach.
2. To support Contract First approach you need to be able to generate a skeleton and a message receiver for your service. The generic message receiver that I have already written may not work because it works only on a limited schema structure.
3. Another way to look at the above argument(2) may be; only 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.
The above arguments are my opinion(for now) on integrating the gsoc code to existing code base. The above arguments may subject to change.
Sunday, July 5, 2009
GSOC: Problems faced during development
Earlier I said that I would be writing a blog post on the problems which I encountered during the development phase of my GSoC project. Here I am compiling them to a list. Some points in the list may not directly be problems but important things which came across during the process.
1. Had a problem with building axis2. This was overcome when I found a workaround for this. (This was a hard issue to regenerate because this will only happen occasionally.)
2. There were lot of dependencies inside axis2's code generation framework. Some dependencies were not set by the build script. Therefore had to manually add the dependencies and run the code. When it gives a compilation error stating a dependency is not there, had to set the dependencies. This took some time :).
3. Had to take some time to understand the existing code base and the architecture of the code generation framework.
4. Learned to work with XSLTs.
5. Another important point to note is that the WSF/Jython distribution, now needs some additional libraries to successfully run. You may have wondered "why is this happening?". As you may already know WSF/Jython is built on top of Apache Axis2. The new releases of Axis2 are having more dependencies towards other liblaries/jars (eg. wsdl4j, etc). Since I no longer work for WSO2, I do not have the access writes to change the build script for WSF/Jython. As soon as I get there, I would remember to revise the build script. Until then you could do a small workaround:)
Download Axis2 standard binary distribution. Then extract it. Add the jars which are residing in the lib folder, to the classpath. Then you could carry on with your work.
6. How to integrate this project to the existing WSF/Jython development. (I will present my arguments on this on a new post)
1. Had a problem with building axis2. This was overcome when I found a workaround for this. (This was a hard issue to regenerate because this will only happen occasionally.)
2. There were lot of dependencies inside axis2's code generation framework. Some dependencies were not set by the build script. Therefore had to manually add the dependencies and run the code. When it gives a compilation error stating a dependency is not there, had to set the dependencies. This took some time :).
3. Had to take some time to understand the existing code base and the architecture of the code generation framework.
4. Learned to work with XSLTs.
5. Another important point to note is that the WSF/Jython distribution, now needs some additional libraries to successfully run. You may have wondered "why is this happening?". As you may already know WSF/Jython is built on top of Apache Axis2. The new releases of Axis2 are having more dependencies towards other liblaries/jars (eg. wsdl4j, etc). Since I no longer work for WSO2, I do not have the access writes to change the build script for WSF/Jython. As soon as I get there, I would remember to revise the build script. Until then you could do a small workaround:)
Download Axis2 standard binary distribution. Then extract it. Add the jars which are residing in the lib folder, to the classpath. Then you could carry on with your work.
6. How to integrate this project to the existing WSF/Jython development. (I will present my arguments on this on a new post)
Subscribe to:
Posts (Atom)