In just two weeks the conference season for 2009 starts. This spring I’ll speak at the ApacheCon in Amsterdam about OSGi and some of the stuff we have at Apache for using OSGi within your own project.
Later, in April, it’s JAX time again – and again with a new location. My talk for the JAX is about the great Apache Sling project (JCR, REST, OSGi etc.). I’m happy to see that OSGi is one of the key topics for the conference with a lot of famous people there 🙂
Going to these conferences for several years now, I still think that the chance to meet people and talk with them is one of the greatest things – and especially these two conferences provide excellent opportunities. So don’t miss them! See you in Amsterdam and/or Mainz, Germany 🙂

In the last months I had the nice and interesting opportunity to try out several portal servers – ranging from open source to the big commercial ones. As a summary upfront, the first time experience of nearly all solutions is REALLY ANNOYING; in some cases it’s unbelievable how poor and confusing everything is. Just as a disclaimer, this is my personal opinion after playing around with these servers for just a short time.

But let’s be more precise…I started with looking for open source portal servers implementing the JSR 286. Due to bad experience in the past I avoided the JBoss portal (this might be unfair as my experience is two years old.). Apache Jetspeed does not support the standard yet, so I looked for Exo and Liferay. I think their web sites are overloaded, they look too much like a brochure for me and getting to the real downloads requires too many clicks.

After downloading Exo, I found a nice README in the root directory which tells you briefly how to start the portal and what the admin credentials are. Nice and easy. Unfortunately after starting the whole thing, I got lost as I found no way to deploy my portlet. Afer downloading the docs (again some clicks) I found out that the downloaded version does not support the deployment of portlets through the UI. I think deployment through the UI is a number one feature. So I immediately stopped here and went to Liferay.

They have the same shiny web site, sigh, and after downloading you have “something” extracted. The provided README is the Apache Tomcat README, so no real clue about how to start this thing. As I’m able to start Tomcat and know the default port I could get the portal running easily. Looking for the admin credentials required to download the docs and search for it. It took me some more reading that for Liferay everything is a plugin, even a portlet. So I uploaded my portlet through the UI and got it running immediately. I didn’t found any spec related problems with my portlet, however the AJAX based UI of Liferay seems to have sometimes problems with render parameters.

Then it was time for the commercial ones. Fortunately I had someone else downloading and installing WebSphere and Weblogic Portal for me and providing me the admin credentials. Of these two, WebSphere is slow, has an overloaded admin UI, but deploying your portlet through the UI is nice and easy. I didn’t found any spec related problems. Nothing more to say about this one 🙂

But the nightmare of every portal developer is Weblogic Portal. It seems to be even slower than WebSphere, is full of bugs and has a more than overloaded and unstructured admin UI. There is no menu for deploying a portlet. So I went to the website, and really got lost. It took me some time to find a small guide explaining how to deploy JSR 168 portlets…hmm but I had a 286 portlet. Ok, let’s try it anyway. The unbelievable thing is that the UI for uploading a portlet is not linked from the portal admin console. It seems that this vendor is rather ashamed of having this. And after you type the secret url in your browser, you know why. Honestly, I’m really bad in doing nice looking html pages, but I think I could have done even this one better. Ok, good looking is not important in this case, so I ignored that and happily uploaded my portlet. Then I knew why these things cost a fortune….it took the server three minutes to deploy my little portlet – at least that’s what was displayed after three minutes. So back to the real admin console and trying to find my latest deployed stuff…hmm, where is it? Ok, consulting the same docs again, it explained that I have to configure a WSRP provider. Wait a minute…did you say WSRP, like in WSRP = Web Serices for Remote Portlets? Oh well, my portlet is running locally (hopefully), so it makes sense to configure something running remotely. Indeed. Shrug, just follow the docs and you will find success…of course, not! Ok *something* is wrong. Now, if you’ve seen one of these server beasts you know that they have a separate server console where you can see and configure millions of things (the more configurations you have the better the product is, I guess), so after several clicks I found out that my portlet application had not been deployed correctly. How could this be? It wasn’t my fault, so it should be the servers fault..ok to keep a really long story short, in order to deploy a portlet application you have to copy it physically to the hard drive on the portal server, invoke the browser based UI and upload the application through the browser (again). This must be some strange security feature or one of those evil developers still laughing today in his cubicle about this funny joke he did. (Oh and btw, don’t use Firefox 3 to upload your portal applicaiton, the server is not capable of handling the requests correctly…but fortunately the server happily accepts the requests and pretends that everything is fine)

Ok, but the best part was still to come. I went back to the portal admin console, configured the WSRP consumer (still, can someone explain me why? – ok, I’ve an idea why it could be this way, but I think it’s wrong to impose technical decisions on the UI.). From here everything went smoothly, I configured the portlet, added it to the page, got some server crashes and broken pages and finally came to the page with my portlet. Remember that this was a JSR 286 portlet deployed through the JSR 168 import tool? Ah well, everything went fine until my portlet should render itself. Some wired exceptions occured.

After some experiments it turned out that the server exposes the portlet 2.0 API and is able to deploy portlets relying on this API and using the new deployment descriptor. And if you inspect the API version from within your portlet it confirms to be a 2.0 compliant portal server. BUT as soon as you invoke a 2.0 feature you get an exception. I have zero idea what the intension of such an implementation is. Perhaps it’s again this developer in his cubicle? Or is it a whole team making fun of dumb users like me?

So after reducing my portlet to just use JSR 168 features it nearly worked – except for some more quirks and errors in the implementation of the spec. As a summary, I don’t want to use the WebLogic Portal server again.

In general, Liferay seems to be a good open source solution, if they only would add a small README to the downloaded archve. Without a deployment functionality, Exo is of no interest for me. If you’re into complicated UIs, slow running servers with zillions of features noone needs, use WebSphere – forget about WebLogic. The portlet API 2.0 spec compliants seems to be given with Liferay and WebSphere. So now I’m waiting for Jetspeed to finalize their support 🙂

OSGi is today used in many places, for desktop applications, complex application servers and even for web applications. But what about portlets?
In the last weeks I developed some portlets for our product offerings. The portlets allow you to display, edit and manage content inside a JSR 286 (portlet API 2.0) compliant portal server. As our whole product offering is based on OSGi for the obvious reasons, I thought about using the same technology for implementing the portlets.
By using the great Apache Felix implementation, togther with some of the nice things we developed in the Apache Sling project I could easily manage to start the OSGi framework inside the portlet web application. A simple generic portlet implementation running outside the OSGi world receives the portlet calls, like events, actions and render invocations. This generic portlet just forwards them to a receiving portlet running as an OSGi service. Once you are inside the OSGi world you can use all the benefits of OSGi for your implementation and it was quite simple to develop the “real” portlets. Besides using the same base for all of our products and being able to reuse stuff through well defined bundles and services, one of the main advantages during development has been the easy update of the portlet code. While the whole portal application has been deployed to some portal container, updating the portal did not require an update/redeployment of the portal web application. Just updating a bundle through OSGi is enough and your new code is deployed. This makes the development and testing way faster.
I really don’t want to miss OSGi in everyday development, it creates clear boundaries, enables real modularization and reuse and makes the development much easier. Start your server once and just update the parts that have changed. No need to restart, no need to update the whole application. Priceless!

It’s over 🙁 We spent 15 beautiful days on the islands (Oahu, Kaui, Big Island, and Maui) and it really was a remarkable vacation. There’s a lot to see and each island is different. But…sigh…that’s over now.
Yesterday night we started our long trip back home and now arrived at LAX. Later today we’ll fly from here to Frankfurt and than back to good old Paderborn.

ApacheCon is over – as you can read everywhere it was – as always – a great conference. Congratulations to everyone involved! For some reason or the other I couldn’t enjoy it this time as much as the last times, but that’s how things are sometimes.
In addition my wife and I have a very tight schedule, so we left New Orleans friday afternoon to enjoy the full weekend in Disneyland in sunny LA. Unfortunately our flight out of New Orleans was delayed by two hours so we arrived at LAX around midnight. Picking up the rental car, driving to Anaheim, and checking in took some time, so we managed to get to bed around 2 in the morning 🙁 But we also managed to be early in the park today nevertheless 🙂
The wheather here is way too hot for me – and someone told me in New Orleans that it would be freezing cold in LA (thanks Ralph). But I guess it’s better to have high temperatures than rain, so we’re happy.
I’ll be working out of our New Port Beach office from monday to wednesday, before our real vacation starts on thursday where we will be traveling even further to the west…

Hurray, I’m finished with my Richards talk about OSGi and Apache Felix. I’m very happy and proud to step in for Richard who originally submitted this talk and got accepted but wasn’t able to attend.
I think, in the end it went very well, there were several intesting questions and it seems that the interest in OSGi is really high – I submitted a practical talk for ApacheCon EU next year. Let’s see if I get selected!
Reflecting the talk, I have the feeling that people might got my comments about Spring DM wrong. Just to clarify, I love Spring and it does a great job (there are some things I would like to have different, but I guess that’s always the case). Spring DM is a great thing and they’re doing a great job; I really like it especially the testing stuff. But compared to declarative services it is more a heavy weight solution – heavy weight is not bad by itself, so there is nothing wrong here. In the past years I never had the use case for this, I’m really happy with the simplicity of declarative services and the Apache Felix SCR plugin. That’s all 🙂

I’m really wondering what happened to the great news section on the site where you could immediately read about new releases. And the new download “process” is really really annoying. It requires way too many clicks to get what you want 🙁

So go grab them at our booth here at the ApacheCon in New Orleans as long as they’re hot…

This is day one of the conference part of the ApacheCon US in New Orleans. As always it’s a very busy conference full of stuff to hear or talk about. Today is the Fast Feather Track which kicked of very well attended, although it’s not that easy to find (it’s next to napoleon A2 for all those still wandering around….) I really like this concept as it contains a wild collection of sometimes unrelated topics. It comes with the advantage of learning about stuff you might have never looked at by yourself.
Unfortunately the second part of the Fast Feather Track is not attended very well. And I’m wondering why this is the case 🙁 The talks are really interesting. And I’m pretty sure that the poor attendence is not correlated to the topics. I guess it’s more that people did not really realize that there is a FFT and perhaps they wanted to attend longer sessions.
The final talk for today about QPid will start at 17:30 – so don’t miss the last part of the FFT!
Finally a big thanks to all speakers of the FFT. I really hope you didn’t get too annoyed about the poor attendence. You did a great job!

Now, if you’ve ever heard me talking about programming languages and my preferences in this area, you might know that I really hate javascript. And it is really disgusting that most code you have to write for today’s web applications happens to be javascript (with a little bit html and a lot of brain bursting css). How do we poor developers deserve this? I really don’t know – and I really don’t understand why nobody is doing something against this.
In the past years I used (was forced to use) various javascript libs. Btw, why are there so many overlapping javascript libraries? People are mocking about the huge number of java web application frameworks, but nearly noone is mocking about too many javascript libs. It’s a strange world after all (or was it a small world? hmm).
Now, eventually, a good friend and collegue, Felix, mentioned jQuery as an alternative. I always thought that our Sling slogan “Bringing back the fun” is the greatest slogan on earth, but jQuery’s “write less. do more” is even more intriguing. As I wanted to do some ui updates on the Apache Felix web console, I read the jQuery tutorials, looked at the examples, read the api docs etc.
And I’m really impressed – well, it’s still javascript..sigh – but the approach is very appealing and I managed to get something running in a very short time frame. For instance, adding sorting to a table is just one line of code. You “attach” the table sorter plugin to the already existing html table. And that’s it. So if you start with POH (plain old html) improving your ui with jQuery is really simple and easy. Amazing.
So I can only suggest everyone to take a look. I didn’t do that much so far with jQuery, so I can’t tell that much atm. Currently it seems that the docs are partially outdated and there is an unbelievable amount of plugins which I think is the same mess as the eclipse plugins. It’s really hard to tell which plugins are useful or what they do and even harder to decide if this is a good and active plugin. But I guess this will improve over time.