Problems with Jar files

As a developer from a company which uses OSGi for most of their products I thought of discussing the problems we are having with typical jar files. Most of those issues are solved in OSGi Environment.Don't think twice OSGify your products to achieve real modularity for your software.
First and major issue with simple jar files is not having a runtime concept, they are meaningful only during compile time. At runtime no changes could be done to a jar,it is just expose in to all the jar files in the environment which import it.Jar files doesn't contain any meta data about their dependencies and we do not have any control over the dependency management of jar files. All the classes in the jar is expose in to all the packages of the environment. In simple there's not information hiding between jar files in the Java runtime Environment. So I could say those words something like this. With OOP(Object Oriented Programming) we are achieving information hiding in class level but that's is, how nice if we could achieve that in modular level like exposing some of the packages(making public as we do in public methods and public variables in a class) and hide other packages of a particular jar file. And we can consider this as no communication mechanism between jar files in the horizontal direction, it just allow users to communication through the vertical direction by importing packages. No horizontal communication at all ....:-(

With typical jar files if we have different versions of the same jar it will just pick the appropriate class from the classpath according to the order we are specifying the classpath, so we couldn't consider this as a proper versioning system.

Next issue I would discuss is lack of dependency information in a single jar file. Most of the jar files are always depends on other third party jar, but we do not have any proper way of keeping that meta data describe the dependency for a given Jar file. This cause people to get a very popular Exception called ClassNotFoundException.

Keeping only the dependency information in not enough, we should have a proper understanding about the versions of those dependencies otherwise we couldn't guarantee the behaviour since different versions could be having different behaviours. So with the dependency we should have the version information included on it.

I have described couple of issues we are having with typical jar files and I will be blogging on how OSGi(Open System Gateway initiative) is going to solve almost all of the above issues and Lead Software Development in to new Modularity concept which will be an elegant feature of Java world.

WSO2 Registry Initialization

Since I was assigned to work with Registry team at WSO2 I had a look in to the Registry Core source code which ships as a separate bundle with Carbon. I read the code from the Declarative Service level code and thought of blog about the Registry Initialization.
Since this is a bundle of Carbon Environment it calls most of the methods of OSGI(Open Services Gateway Initiative) but other than calling them all the initialization happens inside the start method of the bundle itself.
At the very first stage it will create the class RegistryConfiguration which mainly go through the carbon.xml and find what type of initialization is configured. It could be a Remote Registry or an Embedded Registry(Default Initialization). If it's a Remote Registry users have to give the values for following parameters like URL,UserName and Password in the carbon.xml.After reading carbon.xml it simply validate the configuration and create the RegistryContext object by reading registry.xml and passing RegistryRealm object in to RegistryContext. Almost all the initialization happed during the time of creation of RegistryContext. Major tasks are reading registry.xml and registering Handlers and configurating most of the database configurations in programmatical stage.

After initializing the registry service based on the carbon.xml it add it to carbon environment by calling addCarbonRootCollection method and now RegistryCore is up and running in Carbon Environment. In the latest trunk all the bundle initializations are done using Declarative Service and you won't be able to find Tracker Classes or Activators any more in Carbon platform.

I will be writing more about the structure of the Registry-Core in near future since it could be useful to understand the internal implementation for who ever is going to implement their own repository management system.

Object Passing between JSP's and Normal Java Classes

Recently I was assigned to work with Java Web Component stuff and I was encountered a problem when I was developing new Web Services Component to WSO2 registry. Let me explain my problem....
I have developed a web Service and generated the code for the client side. If you have a look on my JSP code it's calling the method getProfile by passing arguments path,data,session. My requirement in this method is calling the web service client and get the output of the Web service in to the variable data. When I debug the class GetProfileUtil I notice the expected behaviour of variable data but when the JSP runs it throws a Null Pointer Exception when call the get method of the data(Map>). So the modifications happen inside the method getProfile to the variable data is not visible to the JSP.

String path =request.getParameter("path");
Map defaultprofile = null;
Map> data = null;

try {
GetProfileUtil.getProfile(path,data,config,session);
defaultprofile = data.get(UserCoreConstants.DEFAULT_PROFILE);
} catch (Exception e) {
CarbonUIMessage uiMsg = new CarbonUIMessage(CarbonUIMessage.ERROR, e.getMessage(), e);
session.setAttribute(CarbonUIMessage.ID, uiMsg);
}

But when I modify my method like this to create the object inside the method and return it, it worked fine. I simply avoid passing the variabl in to the method getProfile but rather create a data variable and return it.

String path =request.getParameter("path");
Map defaultprofile = null;
Map> data = null;

try {
data =GetProfileUtil.getProfile(path,config,session);
defaultprofile = data.get(UserCoreConstants.DEFAULT_PROFILE);
} catch (Exception e) {
CarbonUIMessage uiMsg = new CarbonUIMessage(CarbonUIMessage.ERROR, e.getMessage(), e);
session.setAttribute(CarbonUIMessage.ID, uiMsg);
}

when I access the bean variable I got all the modifications happen inside the method.
Is this the typical behaviour of JSP's and it's totally different from the way Java hadle object passing between classes and methods.
As far as I understand only wrong thing I have done in my first case is pointing to a null value for data variable....Otherwise it should work...I don't know that approach might be a worst thing to do...

Web Services API for WSO2 Registry

With WSO2 Registry we have a REST API which users can use to implement their own features for the registry based on our Atom Publishing Protocol Client (RemoteRegisty instance). Currently most of the User interfaces are implemented based on Web Services and we are calling most of the REST API methods inside those web services but we did not offer a complete web services API for our clients even though we have used web services method which are scattered among various User Interface bundles in OSGi Environment of our platform.I was able to do this implementation which is identical to our REST API and users can implement their own web services using our WS-API. We are in the process of testing those API calls through web services and if anybody is going play new WS-API please be kind enough to report any issue when you are dealing at runtime. If you are willing to use our WS-API you can alway have a look in to our carbon components repository and have to build the registry module to use the WS API.

Resource Caching for WSO2 Registry

Once I started employing at WSO2 I was assigned to work with WSO2 Registry which is again another useful product ships Under carbon platform. This is a Registry which users can keep all the resource in their SOA platform and manage all of those resource in elegant manner. As the very first job I was assigned was to implement resource caching for the WSO2 Registry.
In Registry every content is treated as Resource which is having a defined path for each resource to identify it. With resource caching when a particular user do a get operation for a particular resource first it checks in the Hashmap resurce is already cached or not so that it can find whether the user is going to do a new get operation or not. If user is doing a new get operation it adds that resource in to the Hashmap after checking the maximum size of the hashmap and directly get the resource from the serverside and return it. If that resource is already in the Hashmap it send the last modified date to the server side. In the server code it check whether somebody modified or not by comparing metadata of the resource and send a 304 HTTP header if nobody modified. If we get a 304 for the Remote Registry we just give the cached resource rather getting it from our server.
When users are dealing with large datasets this approach uses the users bandwith in an efficient manner rather getting resources from the serverside each and everytime user request for resources. You will be able to get this feature with our next release or if you are using our SVN repository it's already available for you.

First Job Experience at WSO2 Inc

I was able to get an offer from one of the leading open source software company in Sri Lanka as well as in the world. Even with the recession getting an offer from company is a big deal for a fresh graduate. I got my first offer from WSO2 Inc which is almost developing complete SOA (Service Oriented Architecture) platform.Most of the development works are done in Sri Lankan office though we have offices in US and UK. We have basically two streams of products with Java and Scripting-C products. Main Java product is WSO2 Carbon which is a complete SOA platform with lot of bundles integrated all together using OSGi to give a collection of implementations to have a single platfor for SOA. During these days I'm trying to catch up the works going on WSO2 which is a really cool experience for a fresh graduate since I have whole a lot of thing to be learn by myself.

I'm suppose to work with one of the major product called WSO2 Registry which is a registry implementation for SOA platform which help to make a complex unmanagable system more structured and managable. This is not a product which is very specific for SOA management but we can use to manage our resource generally. I will be writing more technical blogs in future about Registry work and my technical experience I'm getting during my time at WSO2.

Trips to Amsterdam and New Orleans

Fortunately I was able to travel overseas two times during my undergraduate time simply because I contributed over Apache Software Foundation during the time I spend at the university as an undergraduate. It was a really really cool experience for me since I haven't been in abroad before that. I went to New Orleans in Louisiana in November 2008 and Amsterdam in March. But due to the touch schedule at the university I couldn't write about both.

My first to participate in ApacheCon US 2008 and I had to give a talk in one of the sessions and it was all about Apache Qpid which was the project I got the committership and now I'm a PMC member for Apache Qpid. That was a very strange experience for me to travel over US alone and I was shocked when I landed over Atlanta AirPort since all most all the people who were around to me was foriengers and I never being to that kind of a scenario before in my life. During my time at the ApacheCon I was able meet lots of Apache folks and discuss certain thing which are technical and really helpful for me for my career and I was able add lot of professional contacts. Whole trip went pretty decent other than delaying my baggage during my arrival to US but now I feel it's good since I got enough cloths from one of the WSO2 collegue and got 50$ from the AirLine.

Now the Amsterdam trip was again a cool experience and opportunity I got from ASF travel assistance committee and I'm really grateful to ASF giving me all of these opportunities. Amsterdam is a damn beautiful city and most of the people are riding their own bycicles and no trafic in the city at all. When I was there it was very cold but I love that weather since I don't want to wash my cloths :-) Most of the people used to close their shops when it comes to 6 in the evening and they go home and enjoy. Almost all the houses are very much similar to houses in Galle Dutch fort so those architectural thing were not unfamiliar for me since my home town in Galle. I was able to get a real experience with the streats I used to see in films with lot of shops around the road and flow of the road is not build with tar but with some kind of bricks. I have noticed couple of differences between Europe and US during the two weeks of my time in Europe and US. US people are friendlier than Europians but they Europian people enjoy their lives and less traffic and little bit of less complex life stile than US. And most of europians used to speak something other than English and sometimes it's hard to do the work in English (All the ATM machines were in Dutch).

I have lot more to tell about my experience but that's all I can write due to busy schedule with my first job which is one of unmemorable opportunity I got in my life.