I am very new to the OSGi platform.
Having an OSGi bundle B1 that has a dependency to another bundle B2, which is very probably not provided by the container, can I package both bundles in the same jar?
If yes: howto do that? what would happen if the jar is installed and the bundle is already installed?
Yes you can do this... kind of.
Normally OSGi bundles are JAR files because they need to have a META-INF/MANIFEST.MF. The OSGi framework cannot directly read your "multi-bundle" JAR.
However, installing bundles in OSGi involves calling the BundleContext.installBundle method. This method has two flavours, one of them takes an InputStream as a parameter; this InputStream should supply the content of the OSGi bundle. Therefore you can take your big JAR and read it with a JarInputStream, passing the individual entries to the installBundle method.
Although OSGi doesn't directly support multiple bundles in the same jar, there is a standard for multiple bundles in the same archive, which solves the distribution problem you're trying to address. Unfortunately, it may introduce an extra problem in your scenario, because it's part of enterprise OSGi, rather than core OSGi, so it wouldn't be part of a bare bones Equinox or Felix framework. If you have more control over the starting platform your users are using, it may do what you need.
The basic idea is that you package all your bundles into a zip with a .esa extension, along with a simple manifest. You can then distribute the esa file. This tutorial includes lots more detail:
http://coderthoughts.blogspot.co.uk/2013/04/osgi-subsystems.html?m=1
Related
We have a very big web application containing many features.Now for maintainability we want to split the application in components so that can remove / add particular components (jars). For that one suggestion is coming is to use OSGI. I think converting jars into bundle will take huge effort. I think same functionality can be achieved by Maven. According to my understanding OSGI is packaging tool. If I can make Maven plug-in for each component then any particular component can be included or removed at compile as opposed to run time as in case of OSGI.
Modularizing the application using Maven will be simpler than OSGI. I have read similar post on this site and it commented that OSGI and Maven are like comparing apple with orange. But I think in one sense both are same as they both meant for packaging difference is one is used at run time and one for compile time
Looking forward for well though answer :)
best wishes
Shailesh
As you already hinted at yourself: you're comparing apple with orange.
OSGi is not a packaging tool.
OSGi bundles are plain JAR files with some OSGi-specific metadata in the Manifest file.
You can create OSGi bundles using Maven e.g. using the Maven Bundle Plugin (I can recommend this approach). So regardless if you're using OSGi or not I strongly recommend using Maven.
Here some use cases for OSGi:
You want to create different versions of your application e.g. for different customers. With OSGi you can just add/ remove bundles without having to touch any other configuration.
You need a plugin system so 3rd parties can provide plugins to your application
You want your application to be truely modular
You want to share some code with other applications but want to hide some internal classes
...
OSGI is much much more than a packaging tool. You could say that OSGI has a packaging tool inside. Maven is a packaging tool and a dependency manager. I'd say that, given the level of complexity and the use you say you'll make of this technology, go with Maven.
I am working on a simple Java-DB2 insert program connected to cics region via CICS explorer. I created a plugin for an external jar(com.ibm.db2.jcc), exported the plugin as a deployable plugin and added this in the build path of the program. The package has also been added in the dependencies (import-package) of the program. But installing the bundle in the cics region, I am getting an exception.
The bundle ABC could not be resolved. Reason:Missing constraint:Import-package:com.ibm.db2.jcc;version="0.0.0".
Can someone help me trace the problem?
I'm assuming the program you're writing is in an OSGi bundle that's being deployed into a CICS JVM Server as your OSGi environment, using CICS's OSGi CICS bundle parts. It sounds like you're taking an existing binary dependency and rebundling it as an OSGi bundle, and want to have your program resolve it using OSGi.
Based on these assumptions, it sounds like you're having to add the bundle to your build path automatically, which I don't think you should have to do. Once you've set up your target platform (http://pic.dhe.ibm.com/infocenter/cicsts/v5r1/index.jsp?topic=%2Fcom.ibm.cics.ts.java.doc%2Ftopics%2Fdeveloping_sdk.html) any dependencies should then be resolved either from OSGi bundles in your workspace, or your target platform. It should then just be a case of adding an OSGi bundle part for each of your bundles, and exporting your CICS bundle to your region. Explorer should take care of exporting all of your relevant dependencies to CICS.
If you wanted, it should be possible to add the DB2 jar file as a lib without rebundling as an OSGi bundle, by adding the library to your Bundle-Classpath manifest declaration, but you might already have considered this!
Can a OSGi bundle have two dependencies, each on a different version of the same OSGi bundle?
Can a OSGi package have two dependencies, each on a different version of the same OSGi package?
(I am trying to learn OSGi from the ground up. This question is just intended to help me understand the basic concepts. From reading online articles about OSGi services, I gather that such dependencies certainly wouldn't be recommended practice. But are they possible at all?)
(Update: rephrased the two questions.)
No. OSGi provides a consistent class space for a bundle. This means that it is only exposed to a single class of a given name. So a bundle cannot simultaneously see more than one version of a package at a time.
This does not mean that ClassCastExceptions are impossible since code your bundle is directly dependent on, can expose objects from their dependencies to your bundle. The proper use of uses constraints on export packages is important to prevent this.
Can a OSGi bundle depend on two different versions of another OSGi bundle at the same time?
Can an OSGi package depend on two different versions of another OSGi package at the same time?
Sort of. You can depend on ranges or specific versions of another OSGI bundle or package like this:
Import-Package: org.osgi.framework;version="[1.3,2.0)"
Not sure if that applies in the first section because bundles should not depend on other bundles, only packages. This is what 'Require-Bundle' does but is suggested you don't use it. Require-Bundle takes versions as well so theoretically it should support version ranges.
Once your OSGi bundle is resolved within OSGi, it will find the package of any of those versions. However, it can't resolve a package (org.osgi.framework) to two separate bundles (one which provides version 1.9 and one which provides 1.8). It will choose the most recent version based on SemVer.
If you try to specify it twice in Import-Package, you will get a 'Duplicate Import' error.
I am trying to understand the intended use case for Bundle-Classpath in OSGI bundles.
Here is my understanding, please help me understand if this is correct.
Let's say I am working on creating an OSGI bundle which will be deployed in an ecosystem of other bundles. The bundle I am working on needs some other bundles, but they are not loaded/exported in this ecosystem, and I do not have control on what the ecosystem exports. In such a scenario, I can put these bundles inside some directory (say 'lib') which becomes part of my bundle. These bundles should also be referenced from the Bundle-Classpath, so they can be loaded.
Is this a correct use case for Bundle-Classpath ?
Will these additional bundles also be loaded in the OSGI container and will packages exported by them be available to other bundles ?
Bundle-ClassPath is intended for including dependencies in our bundle, so that our bundle can be deployed standalone.
Let's take an example. Suppose the code in my bundle uses a library, e.g. Google Guava. I have two choices for packaging my bundle:
Simply create my bundle with only my own code inside it. The bundle will now have the Import-Package statements that declare a dependency on Guava, and anybody who wants to deploy my bundle into his application will also have to deploy Guava.
Alternatively I can include a copy of Guava inside my bundle and reference it from my Bundle-ClassPath. Whoever deploys my bundle can deploy just my bundle, and doesn't need to worry about where to get Guava from. In fact, the existence of Guava inside my bundle is an implementation detail, and the deployer doesn't even need to know that I am using it.
The choice between these two options is a trade-off. Option 2 has the advantage that my bundle is easier to deploy because it is standalone -- everything it needs is right there inside it. On the other hand my bundle is much bigger than it needs to be, which could become a problem if lots of other bundles also embed their own copy of Guava.
A more severe problem with option 2 is that all of the dependencies of the library now become my dependencies as well. Actually Guava is a rare example of a Java library with no dependencies of its own... but many other Java libraries drag in a huge tree of transitive dependencies. If you use this approach with, say, Hibernate then your own bundle will also have that large dependency set. This gets very ugly, very quickly.
So, you should be cautious not to overuse Bundle-ClassPath/Embed-Dependency. You should only consider using it if the dependency is (a) small, and with no transitive dependencies, and (b) your bundle uses the library as an internal implementation detail, i.e. it is not part of your public API.
UPDATE
I forgot to answer your second question about the exports. The answer is NO, the exports of any "bundles" you put on your Bundle-ClassPath will NOT become exports of your own bundle. In fact the JARs we put on Bundle-ClassPath are not treated as bundles at all, they are just JARs.
You can choose to export packages that come from within the JARs on your Bundle-ClassPath but you have to do this in the MANIFEST.MF of your own bundle.
The most common use case for this header is the packaging of external libraries. Let's say you have some library foo.jar, and want to use its classes in your bundle.
You put the jar into your bundle like so,
/
com/company/Activator.class
foo.jar
META-INF/MANIFEST.MF
In you manifest, you can now use
Bundle-ClassPath: foo.jar,.
Remember to include the . on the classpath, or you will not be able to find the classes in your bundle.
When classes are on the Bundle-ClassPath, you can use them like any other class: use them in your code, or export them.
I think you may be a bit off here.
A Bundle-Classpath is an ordered, comma-separated list of relative
bundle JAR file locations to be searched for class and resource
requests.
What this means is that when some bundle class needs another class in
the same bundle, the entire bundle class path of the containing bundle
is searched to find the class.
From OSGI in Action.
Let's consider a concrete case. Imagine a bundle (JAR file) with the following structure:
src/a/A.class
src2/b/B.class
src3/c/C.class
if you wanted a.A, b.B and c.C to be available to each other, you'd have to define src, src2 and src3 as pertaining to the bundle classpath. That would mean you'd have to add to your manifest file the following line:
Bundle-ClassPath: src,src2,src3
I am new to OSGI framwork So this question might seem silly.
Can we run Apache Nutch 1.4 in OSGI framework. I want to create an OSGI bundle of nutch. I am using eclipse indigo to compile the Nutch source code. So i think there should be some kind of plugin which can create OSGI bundle instead of jar after the compilation. I just need the OSGI bundle of Nutch.
I don't even know if it is possible.
You need to look for a bundle that implements Nutch. A quick google turned up this. If this particular bundle doesn't meet your needs, you can just embed the Nutch dependency into one of your own bundles, using the Embed-Dependency field in your bundle's manifest.
A bundle which already implements Nutch, as the other answer suggests, is your best bet. More generally, you can easily convert an existing jar into an OSGi bundle (without having the source code) using the wrap function of the bnd tool. If you do have the source code and want to recompile, maven's bundle plugin and the bundle packaging will generate bundles.
In the interests of modularity, which is one of OSGi's main drivers, I'd suggest using a separate Nutch bundle rather than embedding the dependency.