Atif Khan’s Blog

I wrote a blog entry in April 2007 about RIFE. It has been 2 years since I wrote that entry. I had mentioned that RIFE was lacking in documention and the learning curve was pretty steeep. That was one of the resons why I decided not to investigate further. Geert tried to calrify some of the questions I had, but that didn’t really remove all the doubts I had. I know that Geert has moved on to bigger and better things. The framework seems to be dead now as there hasn’t been any new releases since 2007. This goes to show that with too much complexity, it is very difficult to build a community that can sustain the project beyond the original founders. It was a framework built on some very good concepts and I am sad to see it go. I do see some nightly snapshots, but no new releases. Is RIFE really dead?

I wrote in a previous post from October 20008 that I was very unhappy with the direction of KDE. The Kubuntu Intrepid was about to be released with KDE 4 as the default desktop. I got a lot of responses saying that I could still continue using KDE 3.x or I should switch to another distro like OpenSuse. Neither of those were really feasible options as I didn’t want to be stuck on KDE 3.x and switching distro was even more a radical change.

The moral of the story is that I am KDE free and happy.

I have been a linux user since early days. In fact for home use I only have Linux and Mac OSX. I have used RedHat, Fedora and Mandrake/Mandriva in the past. Then I discovered Ubuntu few years back and it’s been no looking back. I have used both Ubuntu and Kubuntu extensively. But my destop of choice for home computer has been Kubuntu as I have alwyas felt that KDE has better tooling than GNOME. I like the simplicity of GNOME, but KDE always had more applications.

I love how KDE evloved and matured in 3.x versions. But, then I think the focus shifted to make it look and behave more like Windows (especially Vista with Plasma L&;) for version 4. That’s where my frustration with KDE comes from. I have given it a try a number of times since early beta days and I have been disappointed every single time. My main frustrations have been:

• It’s horribly slow compared to 3.x versions.
• It takes more memory to run. In fact it pretty much takes same memory as you would require for Windows XP.
• The Desktop is ugly. I am pretty happy some simple icons on the desktop. I don’t need fancy effects. There is a value in simplicty and I wish KDE devleopers learnt this from Mac OSX.
• I have been using Superkaramba for a long time and love it compared to KDE applets. In version 4, these are replaced by widgets. It just seems like a step in wrong direction as it has fewer widgets and they are horrible.
• Every time I tried to customize the desktop and L&F, it ended up screwing up everything.
• The main KDE menu is almost unusable. I don’t understand how it is more user friendly
• Same applies to Dolphin file manager. I have Dolphin on KDE 3.x as well, but again there isn’t anything mind blowing.

The release of Ubuntu 8.10 is almost here and Kubuntu is going to make KDE 4 as the default desktop. I am seriously considering switching to GNOME or Xfce going forward. The purpose of a desktop is make the life easier for a user and that has not been my impression of KDE 4. May be GNOME was right all along in the philosophy of keeping things simple and usable.

The new and upcoming Apache CXF framework is quickly gaining steam and rightfully so. It’s very intuitive, simple to use and functional. Some of it comes from the fact the its roots are in popular XFire and Celtix frameworks. It’s still in the incubation stage at Apache but the current releases are pretty stable. The documentation is not complete right now, but it’s improving as well.

One of the cases where I found the document and example lacking is the POX (Plain Old XML) service using JAX-WS Provider model and configuring it using Spring. The examples are mainly focussed towards configuring and starting the service from Java code. So, I created this simple EchoService example that shows step by step how to do it.

First step is to create the service Java class that will echo the incoming XML message back to the requester. We will also annotate this class using the JAX-WS annotation to mark it as a web service provider and the message type to be the payload. So, the CXF implementation knows that it should only deliver the message payload to the service class. The CXF binding layer processes any binding level wrappers and headers.

In the above class we specified that we want to receive the incoming XML message as DOM. You can change it to use any concrete subclass of the Source interface (e.g. SAXSource).

Next step is to create the Spring configuration. For simplicity sake, let’s keep the name of this file to applicationContext.xml. Here is an example:

The key things to notice in the above XML are:

• Address of the service (/echo).
• Binding URI (http://www.w3.org/2004/08/wsdl/http). This is really important. This is what tells CXF that this service is going to be simple XML over HTTP.
• Declaration of service factor where we indicate that the messages are going to be of wrapped nature

All that’s remaining is to declare the Spring context listener in your web.xml for the web application that this service is going to be a part of. Here is an example of the web.xml:

As you can see that there is nothing special here at all. It’s all standard Spring configuration using the context loader listener. Also, we are declaring the CXF servlet here and mapping it to /* to make all the requests to this web application go through the CXF servlet.

Now all you have to do is to package this web application and deploy it in your favorite application server. You should be able to access the Echo Service we wrote at http://localhost:8080/AppName/echo (you will have to adjust the port and application name in the URL). Now HTTP post a XML to this URL and you should get the request echoed back to you.

Maven POM
I think it’s more useful to also specify the Maven POM that contains all the dependencies as well to build the run this example. Please keep in mind that some of the dependencies here may not be required anymore as I was playing around with a lot of CXF functionalities.

Here is a list of all the jar files that ended up being in the war file from the build using above Maven POM. Again, some of the jars here may not be needed.

Sometime back I proposed a reversible enum pattern in my post. One thing missing from that implementation was the ability to successfully lookup the enum constants in cases where enum constants can have multiple values. To accomplish this, I utilized another feature introduced in Java 5, namely varargs or variable argument support. This way while building the key for the map, we utilize all the values for a constant and use the varargs in the reverse() method of the enum.

Let’s look at the interface MultiValueReversibleEnum that denotes an enum as reversible and that an enum should implement.

The things to notice in this interface are:

• getAllCode() method - It returns an array of all the possible values for an enum constant
• reverse( E ... code ) method - You can see the usage of varargs here. You basically give all the possible values for the enum constant you want to lookup in the right order

As you can see, the getAllCodes() defined in the interface is used to build the key for the map. Also, the get( final K ... enumValues ) method that looks up the value in map uses varargs.

If you run this class, you should see following getting printed:

Reverse for [1, 11]: ONE
Reverse for [2, 22]: TWO

It’s all very simple and straightforward. If you have any suggestions or feedback to improve this, please leave me a comment.