Stuart McCulloch

Augusto Sellhorn wrote:Thanks!
Interesting, we're using version 2.0.1 and I wasn't aware of that feature. Probably not turning it on I guess ... (perhaps I have to tell it where the xml files are???)

It should be enabled by default and scan Spring-DM/Blueprint files that end up under META-INF/spring, META-INF/blueprint, or OSGI-INF/blueprint in the final bundle. I think there were some additional improvements in 2.1.0 but if you're still having trouble then send a message to the Apache Felix dev list http://felix.apache.org/site/mailinglists.html as we have several developers that use this feature in their projects (and know more about it than me :).

You could ship each component as a separate bundle and use OSGi services to wire the components together at runtime. As Richard suggested you could then use something like iPOJO (or one of the many IoC frameworks that support OSGi services, such as Spring-DM/Blueprint) to provide null/mock proxies for situations where you ship a subset of bundles and some services are missing.

In other words bundles can help you divide up your application and services can help wire them back together. The book contains a simple paint example that we take apart and re-implement using different parts of OSGi (modularity, lifecycle, services, IoC, etc.) to show the pros and cons of each layer. We also take an existing application (jEdit) and turn it into an OSGi application.

Hope this helps - you might want to read the first chapter (which is free) as this takes a smaller "Hello, world" example through similar steps.

Augusto Sellhorn wrote:For example, we got weblogic JMS to work in an OSGi container but encountered a lot of issues, and it was not a trivial thing to make it work in OSGi. Things in this regard are a bit complicated when you introduce declarative frameworks like Spring. For example, Spring classes you use in a context are not scanned by the maven bundle plugin and it can't put packages in for you automagically :-(

FYI, support for parsing Blueprint and Spring-DM XML for imported packages was added to the maven-bundle-plugin in version 2.0.1: https://issues.apache.org/jira/browse/FELIX-1552

Richard S. Hall wrote:

Pradeep bhatt wrote:Thanks authors. what about .NET langauges like C# ? Is modularity taken care of there ?

.NET has more support for modularity by default than Java, but it is not as fine-grained and dynamic as OSGi. .NET packages its types into assemblies, which are its module concept. Assemblies contain a list of their dependencies on other assemblies. This way the .NET runtime can make sure all requirements are satisfied and it can support side-by-side versions. Additionally, .NET has another access modifier (besides public, private, and protected), called internal. This provides visibility within the entire assembly, but not outside of it (i.e., module global).

The closest thing to OSGi on .NET is probably the Managed Extensibility Framework (pdf transcript of a podcast discussing MEF) but it doesn't have the same concepts of lifecycle and services that OSGi has.

Pradeep bhatt wrote:

Richard S. Hall wrote:

Pradeep bhatt wrote:
How does osgi ensure that dependency are satisified. Can the author throw more light on the internal implementation details ?

Each bundle JAR file lists its dependencies on external code. The OSGi framework that reads this information at execution time and makes sure that other bundles have been deployed to satisfy the requirements. If not, you get an exception up front telling you some required code is missing.

Wouldn't it burden the deployer to specify the external depedency. There is a chance it may be missed because the code uses say class.forname(..)

The developer is best placed to know what their bundle needs to import - that's why ideally OSGi metadata would already be available in third-party libraries to begin with. And once this metadata is available everyone else gets the benefit and they no longer have to guess what a library might require. How many times have you juggled with the classpath adding and moving various JARs around to fix some obscure exception?

Tools can help detect what you need to import, but as you say they can't detect all uses (such as dynamic Class.forName calls) - but then neither can users of your code unless they can see the source. At least OSGi gives you a way to tell other people what your code requires - and because this metadata uses a standard format it could even be used by other modularity frameworks in the future.

Pradeep bhatt wrote:Why is the expansion of ogsi no longer equal to Open Services Gateway Initiative ?

The scope of OSGi has grown beyond the initial initiative so the expansion no longer makes sense.

Pradeep bhatt wrote:

Yes. I use OSGi with Spring. My modules have most of the time, at the code level no dependencies to OSGi (via activators) or even Spring. So I like this approach as these are pretty framework independent POJOs.

ummh I thought ogsi was a runtime thing meaning no imports in my class.

Depending on what parts of OSGi you want to use, and whether you use other abstractions on top of OSGi you may (or may not) need to import OSGi packages. You don't have to add any imports to take advantage of the modularity layer.

sourabh girdhar wrote:Are there some code examples?

All the code examples can be found at http://code.google.com/p/osgi-in-action/

Augusto Sellhorn wrote:Actually I am using karaf, so yeah, karaf has a feature:install command (and features have a version) but I don't really see how you can do an update of a feature. I got the impression features were not officially in the spec, but I thought they were a common feature of other containers too (like equinox and felix).

Eclipse also has features, but they're not quite the same as in Karaf - the idea of atomically installing a related set of bundles (and providing some isolation between sets of bundles) is common, but has yet to be standardized by the OSGi Alliance. There is the DeploymentAdmin compendium service, but that has the drawback that you cannot share bundles between deployment packages.

Lance Colton wrote:

Stuart McCulloch wrote:
Unfortunately we didn't have enough space to cover Eclipse RCP, but there are plenty of good RCP books around. However a lot of the concepts and best-practices in the book can be used when building RCP applications and Eclipse plugins. The Maven Appendix covers building applications with the maven-bundle-plugin (we tend to use bnd for examples in the book).

I bought "Eclipse Plugins", which is extremely relevant to Eclipse RCP and a pretty good book.
Why I asked about Maven was I have expirence with ant, and always wanted to find the time to teach myself Maven, so there are Maven build examples inside of "OSGi in Action?"

The Maven Appendix contains examples for building various sorts of OSGi bundles, but it's not a general guide to Maven. If you want to teach yourself Maven from scratch then I can recommend the free books from Sonatype http://www.sonatype.com/books/maven-book/ (disclaimer: I work for Sonatype).

John Todd wrote:

Richard S. Hall wrote:

John Todd wrote:Hi,
What are Eclipse Gemini and Eclipse Virgo?
Sometimes, Eclipse definitions are too theoretical.
Thanks.

I'm not involved in Eclipse at all, so my descriptions might not be totally accurate.

Eclipse Gemini is about creating enterprise-oriented modules. It is implementing some of the OSGi Enterprise specs, like Blueprint and Web Applications.

Eclipse Virgo was SpringSource's OSGi-based App Server project, which was contributed to Eclipse.

Things are fuzzy to me now.
I have basic and primitive idea about OSGi but what is OSGi Enterprise Specs? what is a blueprint?

The OSGi Enterprise specs define (optional) APIs, schemas, and services for using OSGi in Enterprise Java. It sits alongside the OSGi Compendium specs that define additional (non-core, non-enterprise) APIs, schemas, and services - which themselves build on the OSGi Core specs. The Alliance tries to keep the core lean and mean by using in-process services to add functionality, which is why the org.osgi.framework package only contains a handful of classes.

Blueprint is the new name for Spring Dynamic Modules which was turned into an official standard by the Alliance - it defines an XML schema for describing service components, which the Blueprint bundle then manages at runtime. This developerWorks article provides a good introduction: http://www.ibm.com/developerworks/opensource/library/os-osgiblueprint/

kri shan wrote:

OSGI is a technology for creating code in an SOA framework (a coding framework). Complex Service Oriented architecture supports OSGi as the foundation for its next generation runtime infrastructure.

Why do we need another SOA runtime framework ? Already Axis2 / Spring Web Services are supporting SOA coding frameworks.

OSGi is a layered framework (module, lifecycle, services) which means you don't have to use all the layers - if you just want modularity then you can focus on that layer and ignore the lifecycle and service layers. While the SOA-like service layer was developed a long time before SOA was defined, you could think of it as SOA inside the JVM. And thanks to the efforts of the Enterprise OSGi Expert Group you can now integrate distributed SOA runtimes like Axis2 with OSGi.

kri shan wrote:

Equinox is an implementation of the OSGi R4 core framework specification, a set of bundles that implement various optional OSGi services and other infrastructure for running OSGi-based systems. The goal of the Equinox project is to be a first class OSGi community and foster the vision of Eclipse as a landscape of bundles. As part of this, it is responsible for
developing and delivering the OSGi framework implementation used for all of Eclipse.

What Equinox does (still i am not clear) ? Is it Eclipse plug-in for OSGI framework support ?

Equinox is the reference OSGi framework. It is also the foundation of the Eclipse runtime - so when you install Eclipse plugins you're installing them on Equinox.

Lance Colton wrote:First of all, this promo is probably the most exciting I've seen since I've been on coderanch, OSGi in a very cool topic.

Does the book go into Eclipse RCP development in any way? (or any kind of RCP development built on the OSGi framework) or is it strictly a book relating to building your own modular applications on the OSGi framework? I see an Appendix for Maven on this page does it cover Maven? or how to integrate OSGi application execution into Maven?

Thanks in advance

Unfortunately we didn't have enough space to cover Eclipse RCP, but there are plenty of good RCP books around. However a lot of the concepts and best-practices in the book can be used when building RCP applications and Eclipse plugins. The Maven Appendix covers building applications with the maven-bundle-plugin (we tend to use bnd for examples in the book).

Sai Hegde wrote:You could use IOC enforcement during your build process. So, why OSGi then???

Actually I personally believe the best way to use OSGi is with IoC, then you can get the advantages of OSGi but you're not tied to the framework

Richard S. Hall wrote:

Augusto Sellhorn wrote:So a nice feature of OSGi is the ability to manage multiple versions of modules at the same time. However, when we install new bundles in our container, every time we increment the version id (say from an mvn url) a new bundle is installed.

So if I had bundle example.bundle.A, version 1.0.0.0
And the install bundle example.bundle.A, version 1.0.0.1

I now have two bundle.As in my environment.

Is there a way to do this in place? That is, update that same bundle (by id maybe?) but replace the old version with the new one, while also preserving the same bundle id (and install order in the container).

I have the same question about features, but kind of curious first at the bundle level.

BundleContext.installBundle() is how you install a new bundle.
Bundle.update() is how you update an existing bundle.

As Richard said, install is different from update. Sometimes you want more than one version of a bundle installed (ie. you might have two applications loaded with different requirements) in which case you can install them alongside each other. In other situations you want to update an already installed bundle, say to rollout a fix, which is a different process. It's also important to remember that updating is a two-step process in OSGi. Existing applications won't immediately use the updated packages, you need to initiate a refresh (PackageAdmin.refreshPackages) which will then stop and re-start the affected bundles so they can rewire to the new packages.

(In advanced cases this may involve persisting user state so the application can restart seamlessly)