If you work with Apache Sling, you have probably encountered the ResourceResolver and its configuration rules. In short, the ResourceResolver is the part of Sling that resolves incoming requests to actual or virtual resources. For example, if a request for /foo/bar is coming in the resolver will resolve that to a corresponding node in the JCR. However, sometimes it is not desireable to expose the internal structure of the repository or the required external structure cannot be represented using the JCR. In that case the resolver can be customized by installing resolver rules. Resolver rules can be modified via the OSGI configuration editor or the OSGI ConfigurationAdmin.

While working on a small toy project using Apache Felix and commons-httpclient, I kept running into the issue that there is no official OSGI bundle for Apache commons-logging out there. While most Apache commons projects either provide simple bundles or full blown OSGI implementations with Activators and Services, commons-logging is an interesting exception. If you scan the Commons OSGI status page, you will notice that there is no OSGI version for commons-logging available, and a separate section to explain why. I haven’t dug into why and how it conflicts with the OSGI classloading scheme, but I can see that being a problem. Be it as it may, there is no official OSGI bundle for commons logging.

I’ve been working with OSGI based technology for a while now and it’s a great piece of technology. However, so far I’ve only worked with OSGI technology that runs in existing instances of the framework. A running framework is easy to deal with, but how do you get to this point? I spent some time today playing with that, and it took me a while to put it all together. So naturally, I’ll have to record my findings here.

I’ve been doing a lot of reading on how OSGI handles class loading. I’m starting to fully understand and leverage OSGI and I’m trying to keep my framework Object Mapper as compatible with OSGI as I can.

In OSGI classloading is very restricted, similar to what happens in enterprisy Java application servers, and completely unlike traditional Java applications where everything shares a single classloader. In OSGI each bundle has its own classloader and what is visible accross the bundle boundaries is subject to strict export rules. In order to use a class outside of a bundle you’ll have to explicitly declare its package as exported. There are many benefits to this strict architecture, clean architectures, reusable components and the ability to update bundles at runtime are probably the most important ones.

So I finally got around to play with Jekyll, a static site generator for websites. I was initially sceptical whether a static site generator would be up for running a blog, but after playing with it for a bit, I’m in love with this concept. The ability to write my posts in vim (MacVim that is) and version them with Git makes me very happy. As much as I like Wordpress, it’s getting more and more sluggish (on my old server at least) and every time I’m logging in to it, I spend half an hour installing updates and patches. And with every upgrade I’m worried about the database – even though, in Wordpress’ defense, no upgrade ever broke the database. Also, I’m particularly impressed with support for syntax highlighting, which is absolutely essential for technical posts. I’m still digging through the documentation and learning how to use Jekyll, but I’m getting there.

I spent some time in India and at a few spots I took enough pictures to create panoramas. Make sure you click the links to the full version and zoom to the original size of the image. They’re huge and you can scroll around for a bit and discover nice details. Full version: India Gate Panorama! Full version: Delhi Rooftop Panorama!

Just figured out how SSH remote tunnels work and wanted to write it down.

Nomenclature:

• [Local] Client: your local computer. In fact, if I say local, I mean the client.
• [Remote] Server: the server you connect to. If I say remote, I mean server.

Forward Tunnels

Your standard tunnel, allows you to take a local port and redirect it to a remote port on the server:

$ ssh -L REMOTEPORT:client:CLIENTPORT user@server

Now, that by opening a tunnel in this way:

Recently at work I had to work on files in our legacy system. Those files, being part of a proprietary product, are unknown to any editor or pretty printer that you can find. And most of them are not formatted nicely, if at all. Being a lazy developer I really love eclipse’s code formatting features, because, hey, it takes away a lot of tedious and annoying formatting. Also, I think properly formatted files are easier to understand, maintain and fix. In fact, as I recently tweeted, I go as far as saying that I’m not particularly good in spotting problems, I just format everything which helps me to understand better.

Not so long ago a freelance client approached me with some updates for their website. The site has been growing organically since 2000 and therefore was a big mess. Several attempts to port the site to a CMS driven system failed largely because those CMS systems are usually to complex for our needs (Typo3) or not flexible enough (Joomla, WordPress). So as I was faced with updates to all the updates including image updates which in turn needed thumbnails to be generated. The same day I stumbled randomly over the xsl:result-document function in XSLT 2.0 which allows you to transform a single XML file into several output files. That sparked an idea with me: why not use that to build a CMS system using XML technologies? I’ve toyed around with Cocoon a couple of years ago but that was not what I was looking for. So I looked for other technologies…

This blog is served by hardware run and owned by me. The only information I see about you, the visitor is whatever your browser sends as part of the connection. That usually includes the IP address visible to my hardware, the user agent string which identifies your browser, and a few other HTTP headers. Log files are rotated frequently so nothing is stored for more than a few weeks.

I do parse the logs with goatcounter and send them to a self hosted instance because I like to see which pages and posts are popular and where my readers come from. All information is aggregated so nothing can be used to identify any specific users.