OSGi + JSP + JSTL

What is so easy with a standard JEE setup becomes quite painful using OSGi. Although there are very interesting projects and approaches like OSGi enRoute, Pax Web or Equinox JSP (and probably a few more), taking a step beyond “Hello World” starts to get quite painful.

OSGi has had support for registering servlets for quite a while. And it becomes even smoother using the HTTP whiteboard approach. But writing a servlet is, in most cases, not what you actually want. It is more like wiring method calls, service methods calls, to URLs, finally rendering it to HTML. Looking at the Spring WebMVC framework, this can be as easy as annotating a class with some @Controller annotation, returning a redirect to a JSP page.

Living in OSGi land, this sounds even better. Dynamically registering and referencing controllers and services. Configuring the application on the fly, during runtime, a dream come true.

Pretty soon its gets quite frustrating from there on. Equinox JSP is not too bad, but suffers from the Equinox HTTP service implementation which has a few bugs and drawbacks. Pax Web is fine, but the whiteboard pattern, although the same name, has nothing to do with OSGi HTTP whiteboard. Most other tutorials around OSGi and HTTP focus on registering a servlet. Since this is pretty much the standard specification right now. Everything around JSP is self made for each framework and mostly works around issues in Apache Jasper. Since Jasper seems to be the only JSP implementation, but it is so deeply tied to JEE, that it is really hard to use it in a different environment. So most tools simply wrap classloaders and tweak “getResource” methods in order to let Jasper think it is in an JEE environment.

Looking at what other JEE applications do, it really seems that everybody does use Jasper. In different patched versions. Tomcat of course, JBoss (aka Wildfly), Glassfish an Geronimo. Also Equinox JSP and Pax Web have their own wrapped and patched Jasper version.

Now it comes to JSTL, sure, you want to have all the fuzz when you develop JEEish applications. Pax Web really does consider looking up dependent bundles for tag libraries. Where Equinox JSP only scans the “Bundle-ClassPath” jars. Apache Jasper however simply ignores the “core” JSTL tag library, although it might get detected on the class path.

Now the good point is, it’s OSGi, and with a little bit of effort you can throw different frameworks together into one pot. Taking Equinox as OSGi framework, Pax Web for providing the Http Service, Equinox JSP for a non-intrusive JSP servlet and a little bit of custom code for the Spring MVC controller like framework, Package Drone got a nice little web framework. The JSTL tags are provided by JBoss JSTL, which feature a OSGi version of the tags.

While the simple servlets are plain Pax Web registrations, including the Equinox JSP servlet, the Spring MVC like setup is a custom part of Package Drone, but with some reusability in mind. A main dispatcher servlet picks up all services which are registered with a @Controller annotation. Calls are simply routed to service methods. The result is a reference to a JSP page, which now actually is part of the controller bundle and not the servlet. The dispatcher mechanism takes care of this an on the one side alters the redirection to the JSP so that the bundle is part of the redirect path, and on the other side registers all relevant JSP resources in a bundle with the JSP servlet of Equinox JSP.

I took quite a while and cost some nerves … but it seems that the next version of Package Drone will have a web framework which is based on OSGi HttpService, supports controller style services and still feels a bit like JEE πŸ˜‰

My day with Google

I had the chance to apply for a job at Google and got invited for the on-site interview after passing the telephone interview. Now there are numerous blog posts out there, about getting a job at Google and cracking the code interview, etc … If you are looking for that, this blog post won’t help you. First of all, I didn’t get an offer, and second it is more about reflecting the on-site day. To be honest, I would never actually consider writing a blog post about such a topic. However, telling family and friends about this caused a bit of a wow-hype, simply because it was Google. So it’s time to make an exception.

If you want to get a glimpse what it will be like (or rather, how it was for me) read on … maybe this helps you to prepare yourself. And if you start reading … please read it completely!

So what was it like?

I had the on-site interview at the Google office in Munich. The office itself is quite impressive and the tour during lunch time was really fascinating. It is a bit like working in Disney Land. Most people are really nice and give you a great time. So wether or not you get the job, you still will have really exciting and fascinating day.

What about the interviews?

Well, that is totally different story. As already said, there are enough web sites out there to get you prepared for the code interview. And nobody asked those strange Google questions, everything was focused on code interviews. More precise, on solving algorithmic puzzles. And that’s it! Nothing about the past, the present or the future of your career.

Interestingly all people there were of the same type. A friend of mine, knowing a few people working at Google, warned me with something like these are the type of nerds you don’t want to work with. I did not understand what he meant. And I am pretty sure there are lots of people that don’t want to work with me either πŸ˜‰ So I just ignored this, which was a good thing, but understood what he meant afterwards. I still can’t put it into words, and from my perspective I would not warn anyone! But it is true, there really seems to be only one type personality/nerd/geek there. Maybe it was just a coincidence, but diversity looks different.

And then… ?

After I came out of the last interview and left, I was pretty sure that I won’t get an offer. And I was pretty unsure about the idea of working at Google. Wait, why that? Everything seems really cool, it was a great day … how can that be?

Of course I did ask a few questions myself, mostly the same to each person in order to compare the results for myself. I also found it quite strange that beside one or two questions, which were asked outside the interview process, nobody else asked questions. Having worked over 15 years in building complex software systems, I would have expected at least a single question about the facts that I listed in my resumΓ©, beside one question in the telephone interview, from a curious guy what had some experience in the same field. All the answers to the questions I asked, where pretty much the same (and sorry, but I won’t post the questions or the answers). This made me think about all of this from a different perspective.

Why, oh why?

I asked myself the question (again): Why do I want to work for Google? I came up with two simple answers: a) It is cool working place! – Yes, I saw that! It really is! b) You can create great things there! – And this is what I really doubt after being a day at Google and talking to the people there.

The second question is: Why do people actually leave Google? – If it is such a cool place, why do some people leave it? (Of course for some it might not be their choice, but for others it is). And I got this answered as well, not in the interview day at Google of course.

Innovation?

It all comes down to innovation. Maybe the term is a bit vague, but in the end, what I mean is … creating something new. Having great ideas, turning them into great products. And this is what my idea of a job at Google was.

The reality is different … based on the answers of my questions, on how their interview process works, what I have seen, experienced and heard from others … there is actually nothing innovative there. Everything is about slightly improving what is already there. And not everybody likes that. Which is a reason for people leaving Google.

Proof?

Of course this is all my talk after not getting an offer … do me a favor and read the next section as well! Of course I will not quote peoples answers and name who said what!

So just look at the bigger picture. What are the most successful Google products. And I am not talking about the financially successful products, just to most used, the most recognized … the first products which pop up into your mind when you hear Google. For me it is: the search engine, Android, Youtube, advertising (AdSense, AdWords, Analytics).

Sure, the search engine is their thing … and then:

Data from: Google Acquisitions at Wikipedia
Android August 17, 2005
YouTube October 9, 2006
DoubleClick April 13, 2007

The initial invention, idea, vision, innovation … what ever you name, it was not born at Google, it was acquired. Everything after is only a bit of improvement, but nothing new. Just check the full list at Wikipedia.

Interestingly Heise comes to the same conclusion after the Google I/O 2015 (see article, in German). The summary is: Google did only show “expected” advances but nothing visionary, exciting … truly innovative, just minor improvements.

So what?

So what am I saying? Don’t work for Google? No, absolutely not! I do not want to say that at all!

But you should re-think it from a different perspective. If you want to do “great things”, maybe it is better go somewhere else and get acquired by Google πŸ˜‰ Working for Google seems like a hype. Like a hype for the Apple Watch, or for Maker Bots … it is really cool. Until you have a closer look and be honest with yourself.

Did this change my view on what Google is doing? Not at all. I still like many products and think others could be improved a lot.

Now wait – wouldn’t this post look totally different if you got an offer?!

Sure it would! I guess the blog post would not even exist. Instead of writing about it, I would put the effort in changing things to the better. Writing a blog post would not achieve that.

Package Drone – what’s next?!

Every now and then there is some time for Package Drone. So let’s peek ahead what will happen in the next few weeks.

First of all, there is the Eclipse DemoCamp in Munich, at which Package Drone will he presented. So if you want to talk in person, come over and pay us a visit.

Also I have been working on version 0.8.0. The more you think about it, the more ideas you get of what could be improved. If I only got the time. But finally it is time for validation! Channels and artifacts can be validated and the outcome will be presented in red and yellow, and a lot more detail ;-). This is a first step towards more things we hope to achieve with validation, like rejecting content and proving resolution mechanisms. Quick fix your artifacts πŸ˜‰

Also there are a few enhancements to make it easier for new users to start with Package Drone. “Channel recipes” for example setup up and configure a channel for a specific purpose, just to name one.

Of course this is important since, with a little bit of luck, there will be an article in the upcoming German “Eclipse Magazin“, which might bring some new users. Helping them to have an easy start is always a good idea πŸ˜‰

The next version also brings a new way to upload artifacts. A plain simple HTTP request will do to upload a new artifact. While I would not call it “API”, it definitely is the starting point of exactly that. Planned is a command line client and already available is the Jenkins plugin for Package Drone. It allows to archive artifacts directly to a Package Drone channel, including adding some meta data of the build.

So, if you have more ideas, please raise an issue in the GitHub issue tracker.

Meanwhile @ Package Drone

Since Package Drone has its own home now, I would simple like to sum up here what progress Package Drone has made in the last few weeks.

First of all, the most recent release, as of now, is 0.4.0. The last two releases were mostly focused about the processing of zipped P2 repositories and what comes with that. These can be processed in two different ways now. Either using the Unzip adapter, which is more like a way of deep linking, but still allows one to access a P2 repository inside that ZIP artifact. The second way it the P2 repository unzipper aspect, which unzips bundles and features and create virtual child artifacts. The second approach makes these artifacts available to all other Package Drone functionality, but also modifies the original content but unzipping and creating new meta data. However both variants can be used at the same time!

There is also a setup for OpenShift, and a quickstart at the OpenShift Hub. So if you want to try out Package Drone, the most simplest ways, just create a free account at OpenShift und simply deploy a new Package Drone setup with a few clicks. Including the database setup.

If course there have been lots of things cleaned up and improved in the UI and the backend system, but this is more a topic for the actual release notes at GitHub.

So the question is, what the future will bring. One thing I would like to see Postgres again as a database. With the most recent Postgres JDBC driver and some help from my colleague, this might be feature appearing in one of the next versions. MySQL works fine, but also has a very bad behavior when it comes to BLOB support. And since all artifacts are stored in the database, this can cause some huge memory requirement. Hopefully Postgres does a better job here.

Of course there is also the idea of storing the artifacts separately in the file system. While this requires a little bit of extra processing when it comes to backup up your system, it might be right time to add a full backup and restore process to Package Drone. This would also solve the problem of how to switch between storage backends.

And of course, I you would like to help out, please report bugs and become a contributor πŸ˜‰

Controlling the screen resolution of a Windows Guest in VirtualBox

Now I wanted to create another screencast for Package Drone and stumbled over the same issue again. Time to document it πŸ˜‰

VirtualBox with the Windows Guest drivers installed allows for any screen resolution which you could ever think of. Just resize the guest window and the screen resolution of the guest system will adapt.

But what if you want to set a specific screen resolution, pixel perfect?! Windows allows you to change the screen resolution but does not allow you to enter width and height. You are stuck with a slider of presets.

Googling around you will find the idea of adding a custom screen resolution to that selection. However, it seems that for some users this works, for others it doesn’t. I am one of the latter users.

But there is simple command which will tells your guest session to change to a specific resolution, directly from the command line:

VBoxManage controlvm "My virtual machine" setvideomodehint 1280 720 32

This will tell the currently running virtual machine to change resolution to 1280×720 at 32bit.

Maven basic authentication fails

While working on Package Drone, I stumbled over an interesting issue.

Deploying to Package Drone using Maven requires a deploy key. A random token, generated by the server which has to be used as either username or password on the basic authentication process of HTTP.

This worked fine as long as I started “maven deploy” from inside the Eclipse IDE. Starting “maven deploy” using the external maven installation or from the command line caused:

Caused by: org.apache.maven.wagon.TransferFailedException: Failed to transfer file: http://localhost:8080/maven/m2test/de/dentrassi/test/felixtest1/0.0.1-SNAPSHOT/felixtest1-0.0.1-20150217.162541-1.jar. Return code is: 401, ReasonPhrase: Unauthorized.

Although I did configure Maven to use the correct credentials in the “settings.xml” file:

…
<server>
  <username></username>
  <password>abc123</password>
  <id>pdrone.test</id>
</server>
…

After several hours of googling, source code reading and debugging maven it was actually pretty easy.

First of all, the embedded Maven instance in Eclipse uses “AetherRepositoryConnector” instead of “BasicRepositoryConnector” for accessing repositories. “Aether” simply takes the username and password values, as provided, and uses them.

The “BasicRepositoryConnector” however decided that an empty username (or an empty password) is not good at all and simply dropped the whole configuration without warning.

So in the end, introducing a dummy user name did the trick.