Chasing order related failures in JUnit tests

Today we were confronted with a tricky situation where a few JUnit tests failed on our hudson build server whereas everything went fine locally. The failing tests hadn't recently been touched - the types under test neither.
As I'm pretty sure many of you have run into the same problem before here's a short transcript on how that problem was solved:

1.) Analyze what changed (as always, right?)
In our case a new unit test for another type had been added. A new test causes existing ones to fail?!

2.) Spot the difference between central and local build
As I was sure resources where not missing, the potential culprit was the order of execution. Reading the logs
I discovered that NewlyAddedTest was executed before the NowFailingTest on Hudson whereas the order was vice versa locally

3.) Reproduce the problem locally
In order to not miss-use Hudson as a trampoline, I wanted to provoke the failure locally. Therefore I had to reproduce the problematic order. This can easily be done using a TestSuite:

@RunWith(Suite.class)

@Suite.SuiteClasses({NewlyAddedTest.class, NowFailingTest.class})

public class TestSuite {

    // nothing 2 do

}

4.) What's actually the problem?
Normally such a situation indicate that some requirements were not properly tearedDown in NewlyAddedTest. So I first @Ignore(d) the test method of NewlyAddedTest and just executed @Before and @After methods in the suite. NowFailingTest passed successfully. Then I started to analyse how far I had to proceed in the test in order to produce the error. It turned out to be the next-to-last line...

To make a long story short - The newly added test uses a Util-Class with static methods that delegate to a JSR-330 @Singleton. The problem was that the static type kept that singleton in a static variable that was only populated when this class was loaded. If another impl for that singleton got registered later the static type would still use the previous one. Potentially a severe bug/problem...

Lessons learned:
Unit tests are your friend! Even though in this case it was not a specific unit test for the Util-Class that showed the error, we were lucky to have tests that produced the problem

@Hackergarten

Yesterday (late) evening there was the Magnolia Night at Hackergarten. Next to our host Hamlet D'Arcy and 4 Magnolia fellows, there was 7 attendees from various companies. After a short introduction to the product we quickly choose the topics for the night.

We ended up splitting into two groups. Mine was trying to dig into the recently created OpenSocial Container module and especially attacking the currently missing OAuth integration there.

I have to admit we did not get something to run (in contrast to the other group) but this was not really surprising considering the fact that all group members (except me) had never before worked with Magnolia nor had knowledge about OpenSocial. Next to some deeper insights into OAuth we had a lot of nice conversations and were discussing many Magnolia and/or OpenSocial related aspects.
Considering that most of as had already worked some 8+ hours before and that Basler Fasnacht was still going on outside this is quite an outcome I'd say ;-)

Especially striking: again it turned out that the social in OpenSocial doesn't really help to convince people that this is something extremely useful for less social use cases. That's why I added a short intro to our module's Wiki page especially pointing out that there's a whole bunch of big companies using it for there less social apps.

To summarize I can say it was a great evening and I got to know a bunch of cool hackers. I bet the others liked it as well...

Thx a lot Hamlet for hosting the whole event and providing food & beer!

Magnolia Module OpenSocial Container is out

About one month ago I was writing about a PoC having the aim to integrate existing webapps into Magnolia-powered websites by bringing OpenSocial to the Magnolia world. This PoC could successfully be finished a couple of days ago. All envolved developers as well as the project owners were really happy as - thanx to the power of OpenSocial and Magnolia CMS - all requirements could be fulfilled. In order to do so we only had to dive into OpenSocial and write few lines of java, javascript and freemarker. This was enough to construct the Magnolia OpenSocial Module and transform the gwt-based webapps into first class gadgets.


The requirements were:

• be lightweight: We just store a gadget title and its URL in magnolia. To be able to do so we just need a magnolia instance with the new module installed.
• preserve the existing web-apps as far as possible: Having understood how the mechanism works, it only took about 2 hours per app to convert into a gadget.
• allow to render different views for each app (minimized, maximized): We just used the home and the canvas view as defined by OpenSocial. The js files of Apache Shindig already supported them - the gwt-apps came with two corresponding views that could be mapped to the ones of OpenSocial.
• allow communication between the apps: OpenSocial pubsub mechanism is also provided with Apache Shindig so we only had to activate the feature.

Of course many deliverables of the PoC are very customer specific. The good news is that the new OpenSocial module is not - and it'll be available to you in a few hours...


I created a short screencast to show were we currently are:

Seeing separate gadgets being rendered within magnolia was already quite impressive. When we put in the converted GWT-Apps at the customer's side, OpenSocial revealed its real power:


Styles of the container and of all the gadgets were aligned so it really looked like an enterprise portal. On top - using the pubsub feature - gadgets can easily interact with each other. I'd be really surprised if we'll not see lots of Magnolia empowered websites hosting gadgets within the next few months.


Me I'll jump back to Magnolia 5.0 development now, but will keep an eye (or more) on the new module - you probably should do so as well...

Magnolia getting (even more) open & social

Recently, we were asked to integrate several existing web-apps (mainly GWT-based) into one Magnolia empowered website to build something like an enterprise portal.

Among others, the integration should
- be lightweight
- preserve the existing web-apps as far as possible
- allow to render different views for each app (minimized, maximized)
- allow communication between the apps

First decision was whether to go for a client-side integration (iFrames & more) or a server-side one like the Java Portlet specifications (JSR 168 and 286). It was quickly agreed to choose client-side because these are more lightweight by nature and reuse of the existing web-apps (especially the GUIs) should be straightforward.

So the next question was the classical make or "buy". Should a proprietary portal be developed, or is there anything existing that could fulfill our needs? Further analysis revealed that OpenSocial - the emerging standard for client-side, lightweight web-app integration and it's reference implementation Apache Shindig offer almost everything we were looking for - for free! So everybody agreed to opt for this approach.

Some people might ask why a standard originally developed for satisfying the demands of social network sites should be a good match for a lightweight enterprise portal. Well, it's because OpenSocial offers much more and can hence be a good match for various enterprise usages. In addition that's precisely the direction it is envolving to (see enterpise-opensocial).

By using OpenSocial/Shindig we get
- a well established standard (would take a lot of time to define yourself)
- gadget-to-gadget and gadget-to-container communication
- an easy way to reuse GWT-based web-apps as they can easily be transformed into OpenSocial gadgets

- a sophisticated security mechanism (OAuth)

- and more...

That's what I call a jumpstart.

We took the default approach to dig into OpenSocial by installing Shindig v2.0.2 as ROOT.war in Tomcat. I was really impressed when playing around with the samples. On the other side, trying to change the context path or the used port quickly stopped our container from working properly :-(

Plain Shindig wasn't our main focus so we then started creating an OpenSocial container within Magnolia encapsulated in a regular OpenSocial-Container module referencing Apache Shindig. Actually, this is somehow similar to what quite a few other companies did in the last 1-3 years. Here we quickly encountered similar problems as described above.

As we could not find good documentation on how to configure Shindig the right way and especially on how to create a OpenSocial container based on Shindig we started looking into the sources. There, Shindig revealed a well defined and understandable structure, so we're now realizing what issues are to be solved next and can hence steadily progress. In the meantime I stumbled over a Slideshare-presentation of one of the major contributors of Apache Shindig. Especially slide 30-40 helped me a lot in understanding what we have to do...

Although still being in a proof of concept, we already have the strong feeling that this will become a  very valuable extension to the Magnolia ecosystem.

So stay tuned - I'll keep you up to date!

Ps.: blogger itself is based on OpenSocial