Kai is a DZone MVB and is not an employee of DZone and has posted 18 posts at DZone. View Full User Profile

Dynamic Swing OSGi Demo

11.26.2008
| 14828 views |
  • submit to reddit

I am preparing a few talks about dynamic OSGi applications. To get my hands dirty I started a little demo project to showcase different scenarios. That SWT works very well with OSGi is obvious, since Eclipse RCP is based on OSGi. But there are not many Swing based OSGi applications out there. That’s why I started playing around with the dynamic creation and deletion of Swing GUI.

The demo application shows how to use OSGi Declarative Services (DS) and Spring Dynamic Modules (Spring DM) together with Swing UI (and the Swing Application Framework, JSR 296). The goal of this project is to share best practices when it comes to dynamic OSGi-based applications.

The project home page is http://max-server.myftp.org/trac/pm. There you find a bit of documentation and how to get the sources from svn. The current implementation works well with Equinox, I haven’t tried out other OSGi implementations yet.

I would appreciate if OSGi experts take a look at the source code and help me improving the code base. Here is a screen shot:

Have fun!

From http://toedter.com/blog/

Published at DZone with permission of Kai Tödter, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Jacek Furmankiewicz replied on Wed, 2008/11/26 - 8:31am

Everyone is so gung-ho about OSGi, but my experience with it on a large project has been fairly negative.

We get very little additional benefit in exchange for countless hours wasted tracking down obscure exceptions hidden in conflicts 4-5 layers deep in some obscure bundle's dependencies.Pretty much all the devs  I spoke to miss the old monolithic app we had...all its problems were far less than the ones OSGi gaves us. We easily lost 1-2 months of dev time just fighting with dependencies, ClassCastExceptions, obscure exceptions I didn't even know existed in the Java language, not to mention the pain of building this thing into a product, mainaining different targets (dev vs unit testing with extra bundles for example), etc.

The problem with OSGi is that when something does not work (in a large server-side app with 100+ bundles, many of the external open source libs) you're basically up a creek without a paddle. Can't debug anything...(unless someone creates a source bundle), etc, etc.

I had a chance to work on our pre-OSGi version of the app recently...what a pleasure, you can easily debug everything, etc, etc. Goold old Java, always works.

 Don't jump on the OSGi bandwagon unless you really, really need the type of classpath isolation it gives you. If it's not critical to your functionality, I say it's more trouble than its worth.

Sorry, but someone has to start injecting some reality into all of this OSGi hype.

 

Christopher Brind replied on Wed, 2008/11/26 - 8:39am in response to: Jacek Furmankiewicz

We've had a great experiences with OSGi. It has enabled us to isolate and replace parts of our application that needed fixing, sometimes without even stopping the server. Not to mention giving us a service oriented, component oriented and event driven platform to work on.

OSGi is a lot more than "classpath isolation". Your reaction suggests that you embarked down the OSGi route without really understanding it and what it could do for you.

Then again, "right tools for the right job", there are bound to be times when OSGi isn't suitable (can't think of one myself), and there are bound to be applications for which it is *more* suitable (in our case building modular server applications).

Fair enough, get off the bandwagon, but you'll be waving goodbye while the rest of world drives by. OSGi's up-take by major vendors and various success stories is well documented.

Jacek Furmankiewicz replied on Wed, 2008/11/26 - 8:43am in response to: Christopher Brind

Don't worry, we're on the bandwagon, there is no going back :-)

But it's been far from the smooth ride all the Hello World tutorials make it to be. *grin*

Christopher Brind replied on Wed, 2008/11/26 - 8:54am in response to: Jacek Furmankiewicz

How about a fresh pair of eyes on your project?  My company's consultancy fees are very reasonable. :)

http://www.arum.co.uk/

;-) 

Jacek Furmankiewicz replied on Wed, 2008/11/26 - 9:02am in response to: Christopher Brind

Good one :-) I admire your sales skills, always a good thing.

We're good now, but let me tell you converting an existing complex app to OSGi is a trip, full of interesting surprises.

I can only hope creating brand new OSGi apps is smoother.

Oleg Zhurakousky replied on Wed, 2008/11/26 - 10:51am

OSGi is an interesting animal
You are right, it could get very verbose with a lot of knobs and levers that need twisting and tweaking.  This level of flexibility could benefit you in some situation and make your life miserable in others. So the question you should be really asking how do you apply OSGi? As Christopher said - "right tools for the right job"
You are right, in raw OSGi the concept of monolithic application is gone along with the linear class path, parent delegation class loading etc... etc... etc. You can bring it back fully or partially (i.e., writing various OSGi adapter hooks and bundles that create layers of functionality you need), and yes it would require some work. But that level of flexibility is exactly what I need if I am building a product such Java Application Server (for example), that should be able to bring back the concept of monolithic application, but also expose some elements of OSGi dynamics where individual components of the application could be reloaded and refreshed dynamically without bouncing the entire server, where I can enjoy partial package dependency, where I can have multiple versions of the same app running etc. . .
So, we definitely need layers above raw OSGi (think OSI layers). Spring-DM for example created such layer to introduce transparent deployment of Spring based applications in OSGi environment. Spring dmServer took it several steps further and brought pack the concept of Application (PAR) and application isolation along with other things, while still exposing raw OSGi capabilities if needed.
So the real question is not about OSGi or no-OSGi, but rather what OSGi Target Platform will you chose for a particular task that you are about to work on. In other words if I were to develop a Financial app, I would definitely go for a layer above raw OSGi and would start from at least Spring-DM (most likely dmServer). But if I had a concept of a product that I want to build from scratch (i.e., Eclipse, Java Application Server etc. . ) then yes I would go raw OSGi as it keeps all the doors open and that is exactly what I would need.

Oleg

Christopher Brind replied on Thu, 2008/11/27 - 5:05am

I don't like the way Spring and OSGi are finding themself bed partners. I've noticed recently that when people talk about OSGi, they tend to mention Spring somewhere in the same sentence, paragraph or post. I don't think this is a good thing, though I believe the guys at OSGi do (which worries me even more).

It worries me because like you say, you can build a monolithic application on top of Spring DM/AS. This "hides" the fact that OSGi is a fanastic service oriented/component oriented framework and discourages reuse. As a company you would be better off building your application as compositions of discrete bundles which you should put in to an internal bundle repository. Hopefully you will find that you can reuse bundles from your repository in future applications, especially if you are using service oriented concepts.

OSGi is fully equipped for creating great applications, all you need is an implementation of the specification. Eclipse RCP is a great head start for desktop applications and for server applications you can use Equinox and register servlets/HTML and more (with Solstice you can register Flex applications too, though it just uses the HttpService to register the SWFs anyway).

The one thing I think OSGi is missing is a way to "deploy" a bunch of bundles together as a logical application, but I don't think that is a reason to be using Spring DM/AS, IMHO.

Just my thoughts... :)

Oleg Zhurakousky replied on Thu, 2008/11/27 - 4:08pm

@Christopher

I couldn't disagree with you more:  "This "hides" the fact that OSGi is a fanastic service oriented/component oriented framework and discourages reuse. As a company you would be better off building your application as compositions of discrete bundles which you should put in to an internal bundle repository. . .".

Spring-DM and dmServer do not "hide" any of OSGi features and principles, however they create a higher layer in the form of OSGi Target Platform which allows one not to deal with low level plumbing details of OSGi if they don't need to. If I start to develp business aplications using raw OSGi and if I approach it the right way, I am gonna have to write a lot of plumbing/infrustructure type components(bundles), which I would have to maintain together with all of the components that are required to provide business functionality as well. And then I am gonna realize that all that I've developed, as far as plumbing, was already provided for me by other OSGi frameworks such as Spring-DM or dmServer or others. After all OSGi is just a kernel which allows one to build highly modular and dynamic Java systems and that is why I am a big fan of OSGi, but every now and then I have to build an application to run on the Java system and I don't want to build a system as part of that application. It is just like Linux where you can easily start from kernel and assemble your own flavor of Linux or you can ick the one you like most.

IMHO there is a huge difference between building dynamic  and modular systems vs. buidling dynamic and modular applications, so I'll throw your words back at you "right tool for the right job" :-)

Good arguments and good discussion though :-)

oleg

Neil Bartlett replied on Thu, 2008/11/27 - 4:41pm in response to: Christopher Brind

The one thing I think OSGi is missing is a way to "deploy" a bunch of bundles together as a logical application, but I don't think that is a reason to be using Spring DM/AS, IMHO

Aha, it's not missing that at all! Take a look at the Deployment Admin Spec, in section 114 of the Compendium.

With regards to needing something on top of OSGi... well yes, of course you do! OSGi is designed to be the thinnest possible layer above the JVM to give you a dynamic module system. It's not supposed to be a whole application and programming model, though the Compendium does offer some optional components that could be used as part of such a higher-level model.

What you really need for day-to-day programming is a Component framework. Spring-DM is one possible example, but there are others such as Guice, iPOJO, Declarative Services and so on. The really neat thing is they all use Services to glue components together, so they interoperate very cleanly with each other. This enables us to compose applications out of high level components from many sources.

It's a shame that Jacek has had problems with OSGi. The two big issues I see in OSGi today are as follows: (A) legacy libraries that make invalid assumptions about flat classpaths and global visibility, and (B) immature tools for designing and developing applications in a modular way and for managing large numbers of modules with many versions. I think it's pretty clear that both of these situations can only improve with time. Jacek, you're an early adopter, I commend you for that but also feel your pain.

Christopher Brind replied on Thu, 2008/11/27 - 6:32pm in response to: Neil Bartlett

Aha, it's not missing that at all! Take a look at the Deployment Admin Spec, in section 114 of the Compendium.

Of course there is, my bad! However, I'm still yet to investigate using it ... I think I'll make that next on the list.

Sorry for being such a purist guys. I actually enjoy building apps from that level and don't really find the "thin-ness" of OSGi to be blocker in that respect. ;-)

David Savage replied on Fri, 2008/11/28 - 4:05am

I've been working with OSGi now for about 3 years and I have to say from an architectural point of view it's one of the best tools out there. The focus the guys at the OSGi alliance have put into ensuring that the spec is lightweight but /useful/ is really pays dividends as a developer.

Sure you need to go to use component framework tools on top of this to really compose enterprise applications - plug http://newton.codecauldron.org ;) - but given most of the major tool sets have a story this is not a big blocker. Also legacy hierarchical classloading schemes are a challenge but to use OSGi you don't necessarily have to go big bang - there are ways you can incorporate legacy apps inside OSGi bundles which doesn't do anything from the modularity point of view but allows you to use the dynamic install/uninstall. Then tackle the lowest hanging fruit once your architecture is on track.

I think the really big problem I've found and it seems others are finding is managing the dependency graph to get stuff running in an OSGi container. Some of the bundles out there have really complex import/export tree's and "uses" brings in a whole new world of head scratching. My team mate gave a really good analogy of uses when he compared it to trying to put together a puzzle where you have not one set but several each showing basically the same picture but tinted differently. In order to solve the import export graph you need to get all the shapes to match up, but in order to solve the uses clause you have to ensure you have the colours matching (i.e. it's a non-local problem).

I think tooling to support the developer is key here - trying to trace this through from Manifest headers in any non trivial enterprise application is an exercise in futility (especially as in a lot of cases I have to wonder whether the current iteration of bundles really "uses" all the things at runtime that static analysis has implied - but that's another blog post).

So to put my money where my mouth is I and a few others started work on the Sigil project (http://sigil.codecauldron.org) which is a set of developer tools (eclipse/ivy plugins) to help developers build OSGi bundles and do analysis /before/ it goes anywhere near the runtime. The tooling is built around a static resolver that follows the OSGi runtime classloading rules but statically at development and build time. It's currently released as version 0.7 and is useful as I'm using it day to day but there's still stuff to be done if anyone else is interested in contributing ;)

Regards,

Dave

Oleg Zhurakousky replied on Fri, 2008/11/28 - 10:40am in response to: David Savage

[quote=dsavage]

. . .

In order to solve the import export graph you need to get all the shapes to match up, but in order to solve the uses clause you have to ensure you have the colours matching (i.e. it's a non-local problem).

I think tooling to support the developer is key here - trying to trace this through from Manifest headers in any non trivial enterprise application is an exercise in futility (especially as in a lot of cases I have to wonder whether the current iteration of bundles really "uses" all the things at runtime that static analysis has implied - but that's another blog post).

. . .

[/quote]

I agree, figuring out your dependency graph based on Import/Export with "uses" could be a nightmare, but at least Eclipse PDE does an exeptional job in validating your Target PLatform's dependency graph (telling you what dependencies are missing), if you set up yor OSGi Target Platform properly.

Oleg

 

David Savage replied on Fri, 2008/11/28 - 12:39pm in response to: Oleg Zhurakousky

Yep that's definitely really useful, but I think the key problem with PDE in this respect is:

[quote]if you set up your OSGi Target Platform properly[/quote]

the problem being that you have to know in advance what bundles to put in your target platform and managing this in a new project can be another headache.

In Sigil I took a different approach, the user sets up a number of repositories in their workspace (remote support via OBR) and then in their project simply specifies the requirement, the tooling then follows the OSGi rules and downloads the bundle that satisfies the graph for you.

Dave

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.