Article: OSGi for Beginners

Home

News: Article: OSGi for Beginners

  1. Article: OSGi for Beginners (13 messages)

    "OSGi for Beginners" is the first of a series of articles aimed at teaching developers how to create OSGi bundles, including dependencies included with the bundles.
    The Seven-Word and Twenty-Four-Second explanations of OSGi OSGi is a component framework for Java. The twenty-four second explanation: OSGi is a framework for Java in which units of resources called bundles can be installed. Bundles can export services or run processes, and have their dependencies managed, such that a bundle can be expected to have its requirements managed by the container. Each bundle can also have its own internal classpath, so that it can serve as an independent unit, should that be desireable. All of this is standardized such that any valid OSGi bundle can theoretically be installed in any valid OSGi container. Rats. Twenty-seven seconds, no matter how fast I run through - I just can't talk quickly enough. What's worse, the explanation doesn't explain why one wants a module system in the first place. Why a Module System? Module systems provide version support for distributed bundles (where "bundle" goes way beyond "OSGi bundle" - I'm using the term to refer to any application.) Dependency hell is also an issue; lifecycle is ... interesting. All of these things are important; versioning still hasn't made it into web services, EJB versioning is enforced via JNDI, but few use it (nobody in the wild that I know of), jar dependencies are managed normally with parallel jar deployments (except for JCA and WARs, both of which have different ways of managing dependencies). Java EE has solutions, although not necessarily good ones: WARs and JCA can contain jar files, EJB jars can refer to other jar files through their manifests, and of course app servers can provide a higher-level class repository; versioning is provided through JNDI as long as you're not using different versions of the same web app or web services. Lifecycle exists for webapps (load-on-startup servlets, context listeners) and JCA, but EJB 3.1 might have a lifecycle mechanism - it's not sure yet. And we all know that Java EE is a hammer that fits everything. OSGi and JSR-277 are attempts to standardize module deployments for Java, without forcing a Java EE mindset, and without Java EE's weaknesses regarding dependencies and versioning and - for that matter - lifecycle.

    Threaded Messages (13)

  2. Nice. Just 2 days ago I was looking for something like this. Thanks a lot. Now we can change the #java factoid for osgi that currently says: OSGi is a module system for Java, defined by http://www.osgi.org/ . It's a lot cooler than you'd think, even despite Eclipse relying on it for bloody well everything. Naturally, the quality of its documentation in inversely proportional to the usefulness of the framework itself.
  3. Module Systems?[ Go to top ]

    I am new to OSGi, could someone please give an example of these module systems. What would be the big difference between a Module System and a struts app? I'm not even sure if that is a good comparison, but a comparison of the Module System alternative would be helpful as well b/c I do not think I understand the problem well enough to understand the article or anyone's future answers. Any additional information, links, and/or tutorials would be appreciated as well. Cheers, SEan
  4. Re: Module Systems?[ Go to top ]

    Think of OSGi modules as "live" code that you deploy in bundles. The OSGi core pulls modules from a URI either in response to a user action or based on a schedule. A "bundle" is just a .jar file containing your Java code, a manifest file, and at least one class that's "OSGi-aware". The bundles can contain any type of Java classes/objects. They can be deployed and activated simultaneously or with a delay in between. The goal is to provide a mechanism for deployment of "live" code without having to manually start/stop an application or container. Here is an example for understanding the problem: you ship a few hundred thousand Blu-Ray players with software already enabled. You have a bug fix that needs to be deployed by June, and that must be active in September. OSGi provides facilities/APIs for managing all this in a very simple manner. As far as your application is concerned, unless you're doing the actual bundle management you have no reason to worry about OSGi. Write your app as you'd normally would, then create a bundle and deploy it. If all is working well, neither you nor your end-users should care about OSGi. Cheers, pr3d4t0r Non-stop action. A vulnerable hero. A quest to save the world. It's the most exciting novel of the decade and Amazon best-seller Dec. 2007: The Tesla Testament by Eugene Ciurana
  5. Awesome[ Go to top ]

    Thanks Eugene, just what I was looking for. This article now makes much more sense.
  6. Hi, I am new to OSGi and using Knopflerfish. I really liked this article. It mentions separating interface from implementation as two separate bundles. In Knopflerfish it helps avoiding to refresh all installed bundles when you update your implementation bundle as client bundles only interface with the interface bundle. In my project, I'm using internal dependencies which bring me to my question. I get a java.lang.LinkageError while trying to use the same dependent library (JTS) in two different bundles. Is there a way to share and manipulate objects with third-party-datatypes when the same jar(s) exist on both bundles... I return a Geometry object which is not accessible at client side bundle as BundleClassLoader gets agitated over different class versions! The exception I get is: java.lang.LinkageError: loader constraint violation: when resolving field "g1" the class loader (instance of org/knopflerfish/framework/BundleClassLoader) of the referring class, com/abc/klm/Place, and the class loader (instance of org/knopflerfish/framework/BundleClassLoader) for the field's resolved type, com/vividsolutions/jts/geom/Geometry, have different Class objects for that type. Did someone face this situation? Any comments will be highly appreciated.
  7. Ok, the solution to class version conflicts at different bundles was actually resolved quite simply by converting the required third party (LGPL) library into an OSGi bundle. The dependent bundles then receive the same class object at runtime and no conflicts occur. The BND tool by Peter Kriens came in handy.
  8. Nice article! It certainly shows the power and possibilities of OSGi. One thing I do wonder is, won't it be hard to make the bundles of just the right granularity for just the other bundles that just happen to need some sort of shared functionality? I mean bundles that just have different requirements might need a simple bundle or a 'boosted bundle' (with same functionality, but just a little bit more than the simple bundle). In the end how well could it be maintained, any ideas on this yet?
  9. Can your webapp take advantage of the built-in OSGi implementation of appservers like WebSphere or Glassfish rather than including an implementation like Equinox in your web application?
  10. Can your webapp take advantage of the built-in OSGi implementation of appservers like WebSphere or Glassfish rather than including an implementation like Equinox in your web application?
    Well, it depends on the nature of the integration. There are three ways to use OSGi plus web applications:
    • Embed an OSGi container into a web application. This means the .war has to have access to all of the bundles you want installed. It also means that you might have more than one OSGi container in a given servlet container.
    • Embed a servlet engine in OSGi - and install servlets as OSGi services via an http bridge.
    • Use the Spring Application Platform, which allows you to have the best of both worlds - you install OSGi bundles and locate their services via Spring from within your web application.
  11. We've used OSGi for two years and I'm impressed that, even though the technology is new, the bundles run unchanged in all the major OSGi containers available. It solved all the dependency and life cycle problems we had with EJB, without enforcing any of the lame restrictions. Go OSGi!
  12. Re: Article: OSGi for Beginners[ Go to top ]

    Thanks, Joe. Very clarifying article. The start/stop mechanisms remind me of the old WebLogic Startup class concept. I'm so happy to read that OSGi modules manage their own threads. Yay! That makes it easy to deploy our code into an OSGi bundle, since we use plenty of threads and manage them all internally. Can a bundle be started again after it's been stopped? Or is it expected to be unloaded after it's been stopped? Cheers, David Flux - Java Job Scheduler. File Transfer. Workflow.
  13. Re: Article: OSGi for Beginners[ Go to top ]

    Thanks, Joe. Very clarifying article. The start/stop mechanisms remind me of the old WebLogic Startup class concept.

    I'm so happy to read that OSGi modules manage their own threads. Yay! That makes it easy to deploy our code into an OSGi bundle, since we use plenty of threads and manage them all internally.

    Can a bundle be started again after it's been stopped? Or is it expected to be unloaded after it's been stopped?
    I'm just getting started with OSGi myself but the bundles I've created could be restarted after being stopped.
  14. Thanks, Joe. Very clarifying article. The start/stop mechanisms remind me of the old WebLogic Startup class concept.

    I'm so happy to read that OSGi modules manage their own threads. Yay! That makes it easy to deploy our code into an OSGi bundle, since we use plenty of threads and manage them all internally.

    Can a bundle be started again after it's been stopped? Or is it expected to be unloaded after it's been stopped?


    I'm just getting started with OSGi myself but the bundles I've created could be restarted after being stopped.
    Yep - a stopped bundle is just stopped. It's easy to restart.