Friday, March 07, 2008

Small GWT / OSGi Problem

I thought I would document a small problem I had today in case others ran into the same issue.

If anyone has been to my website you know it's not that exciting. A few links, a picture or two and links to my blog. What is exciting (for me at least), is how I built it. My website is actually an OSGi engine (Equinox) with a Jetty bundle to serve up the pages, a small EMF model in the back end (to hold some links), and GWT to tie it all together. To be clear, this is overkill!!! But I enjoyed setting it up and I learned a bunch!

Now the problem. Today I decided to see if I could modify things on my site (both client and server side) and update it using the OSGi update command. (With P2 on its way this seems like a cool thing to do). However, after I did the update *BOOM* GWT died.

It turns out that GWT does some server side security checks and they use the classloader attached to the current thread to do them. However, this doesn't play very well with OSGi. To fix this I added:

Thread.currentThread().setContextClassLoader( MyActivator.getDefault().getClass().getClassLoader() );

This way, the same class loader that loaded my activator will be used when GWT does its security checks.

I'm not sure if this is the best way to fix this, so if anyone else has suggestions I'll try them out and let you know how they work. Also, I found this bug after I sorted all this out :).

7 comments:

Benjamin Cabé said...

It's funny to see we ran into the same problem using EMF over...Android..!
http://groups.google.com/group/android-developers/browse_thread/thread/51c361ff98ae7dc6/9a03147e0a070536?lnk=gst

Neil Bartlett said...

Interesting, thanks for that. In general libraries that expect to use the thread context classloader are problematic because OSGi does not define what should be visible from that classloader. I believe that the next release of OSGi (i.e. either R4.2 or R5, depending on what the marketing dept decide to call it) will address some of these issues.

Hopefully BJ Hargrave will have some more info in his EclipseCon talk "What's next for OSGi?". Also his talk "Why Class.forName sucks!" should be relevant.

Ed Merks said...

Did you do this with a try-finally block that always restores the original thread context class loader after you've done whatever things require this to be set?

Ernie said...

You built your website with OSGI? You are an unrelenting Eclipse nerd. Just thought you should know that.

lubosp said...

Ian,

any chance you would be willing to share or publish the code? I am project admin and lead developer for open source project Luntbuild (CI server), and we are about to start complete rewrite on the application based on GWT and OSGi, and it would be nice to have an example to get us started.

Thanks, Lubos

Ian Bull said...

Neil B. I'm pretty upset I won't be at EclipseCon this year, but I will check those slides out.

Ed: :-) Good idea. Now you're debugging my code without even seeing it.

Ernie: In between thesis edits I need something to do.. I guess I could spend time with my family :-)

Lubos: Sure, or I could at least provide a skeleton system. There is some information on the OSGi / GWT wiki at Eclipse. Send me an e-mail if you need a hand.

Gunnar said...

Ian, I haven't run into this security problem yet. However, I have found another few issues regarding GWT and OSGi. Issue 1888 for example would allow to make RPC working without buddy classloading. We want speak about this in our Server-Side Eclipse tutorial.