Developing Eclipse/OSGi component webapps


News: Developing Eclipse/OSGi component webapps

  1. Developing Eclipse/OSGi component webapps (11 messages)

    In "Developing Eclipse/OSGi component webapps," by Wolfgang Gehner, a complete walkthrough of creating pluggable OSGi applications with the Eclipse framework is presented, with extension points and full screenshots. It's a very long article, but it's a very interesting concept.
    I dream about creating truly componentized, "pluggable" web applications.

    So I wanted to see if it can be done by bringing together Eclipse/OSGi plug-in mechanisms with standard Java webapp development, using an established MVC web framework (Struts just as example in this case). The simple answer is: YES, DEFINITELY. This document describes a repeatable way of doing it. It gets me pretty far towards the vision of truly componentized web applications...
    This is the fulfillment of the ideas expressed in "Eclipse goes Server-Side!" from a month or so ago.

    What do you think of the idea of using what is basically a Rich Client Platform on the serverside?

    Threaded Messages (11)


    Are there any spring-based solutions?

  3. A bunch of people (at least four projects that I know of) have been doing this with Wicket quite succesfully. See Wicket & OSGi basics.
  4. A bunch of people (at least four projects that I know of) have been doing this with Wicket quite succesfully. See Wicket & OSGi basics.

    Yep, just as I mentioned here (, I can vouch for using OSGi (in my case Oscar), together with Wicket. This was before the mentioned article, and even before Wicket reached 1.0. The application we built with Oscar consisted of two things: a web service and an administration interface for the web service.

    Both the webservice and the admin interface were done using Oscar bundles, and we used Wicket for the admin interface. Each bundle provided menu items, and corresponding panels to display in the page. This allowed us to quickly add new items to the admin interface, or apply bug fixes at runtime, without taking down the server: just a restart of the bundles was required.

    This service was created as a database backend for storing financial analysis documents in an xml database, created for Finan (a dutch company). The service is in use at three major financial institutions in the Netherlands. The OSGi architecture allows Finan to enable their customers to create additional, custom plugins which hook into updates to financial statements of their customers.
  5. My understanding is that this kind of thing was the inspiration behind Hivemind, used by Tapestry. It's definitely based on the ideas of extension points, and the writer (Howard Lewis SHip) describes Eclipse as an inspiration.

    I'd definitely like to hear if anyone has any idea on how the two can be compared. I know that I had looked into using Eclipse for something like this a while back (I share the same dream), but was somewhat leery of what OSGi might bring to the table that would be above and beyond what was needed in web apps.

    I do know that I liked the Eclipse idea when I looked at it a while ago because I longed to use the extensive plugin development tools when developing extensions, something that Hivemind doesn't have.
  6. Part of the attraction of OSGi is that it is a standard, not just an implementation. Can be used for just about anything really.
  7. Differences[ Go to top ]

    The core implementation for the Spring (in particular) offers dependency injection lazy loading, marking an instance as a singleton, adding interceptors via aop, and invoking lifecycle methods (start and stop). I've probably missed some things, but by and large this is the idea.

    OSGi bundles have a lifecycle, and it includes uninstalled, installed, starting, stopping, and resolved.

    Bundles can receive events from the framework and this is important when another service a bundle depends on becomes available or goes away.

    Bundles also maintain their own classloaders which have the jars the bundle depends on, as well as version information.

    Bundles can declare in their manifest file what services they import and what services they export.

    Both frameworks can make programming much easier, so it really depends on what your needs are and what kind of requirements you're working with.

    If you needed a framework for mobile devices where services can come and go, OSGi is pretty much the way to go.

    If you wanted to make sure your components were testable outside the container, for example, you'd probably look to use HiveMind or Spring.

    Since OSGi at this point in time doesn't include dependency injection in its spec, you could use spring inside an osgi bundle. Of course I wouldn't want to do this on a device with limited memory, but if I was developing an eclipse plugin, for example, I might consider this.

  8. Differences[ Go to top ]

    there are IoC approaches coming into OSGi, check out

  9. Differences[ Go to top ]

    Hi,there are IoC approaches coming into OSGi, check out


    Thanks -- this looks interesting and I plan on checking it out this weekend. I was also looking at the MicroSpring container as one possible solution for this because it is a seriously cut down and (mostly) Spring compatible IoC framework.

    Do you have any thoughts on this?
  10. Differences[ Go to top ]

    Hi Thomas,
    I think the main difference between OSGi and other containers is the concern of the availability of services built into the framework. That means that even teh IoC technique you use needs to take that into account, at least to the extend you want to use really dynamic services.

    AFAIK in that respect Spring is much like any other of the other containers in that is has no support for unregistering/registering services etc etc. So if you want to deploy Spring components in OSGi, you loose some of the advantages you get with OSGi. We have been bridging an Avalon container (Merlin/Metro) and it's about removing flexibility in order to fit.

    I would suggest to use a "native OSGi" approach in order to get your deps into your code, otherwise you might end up with null references or you are forced to make your bundles more static than you want.

    Another concern is tha OSGi is trying to adhere to the specified OSGi foundation profiles (1.0, 1.0) that make your bundles run even on J2ME (CLDC etc). So Java5 is not the best combination if you plan to use more of the deployment potential of OSGi on small devices.

    Just a few thoughts ...

  11. Differences[ Go to top ]


    I agree with all that you've noted. I was looking at Spring to take care of static configuration within the bundle, and this won't work if a bundle imports a service which may come and go. Again I'm going to need to look more at the framework you mentioned in the previous post -- I had a look around the website this weekend, but I'm going to have to actually use it to get a better understanding of how it addresses the issue of availability.

    Thanks for the feedback,

  12. Differences[ Go to top ]

    I am working on a web framework with similiar goals at the moment and we have decided to use spring's IoC container to manage the plugins.

    The main reason for this is that spring is well known already in the web-developer community. It can be used to 'detect' plugins registerd in the IoC container and load them as singletons - already preconfigured through spring.

    The IoC mechanism has advantages when you start with more complex plugins that benefit from those common patterns, i.e. inject a DAO implementation into the plugin.

    The OSGi features like installing/uninstalling a plugin during runtime is a feature that we can live without.

    If you are intrested in our approach, you can find more information here: