I have two bundles:
bundleName.2.0.0.324999.jar
bundleName.2.0.0-SNAPSHOT.jar
When I am trying to install them in Apache Felix console, the one which I am trying to install gets the priority.
So my question is, how does it decides the priority then?
You can install both of these bundles at the same time if you like. OSGi does not have a concept of "priority" between bundles.
Related
I am able to get OSGi blueprint to work in Karaf, but I don't understand how to do it in Apache Felix, or my question can be also defined as how can I use OSGi blueprint in plain OSGi?
I made an example here https://github.com/PhilAndrew/sbt-osgi-felix-akka-blueprint-camel using https://github.com/doolse/sbt-osgi-felix in which Akka is working but Blueprint and Camel not yet working.
This question may help Is Apache Aries running in Felix?
It's not starting Blueprint because your bundle's code doesn't actually rely on any of the classes in blueprint, so you either need to add "Require-Bundle" header to your manifest:
requireBundle := Seq("org.apache.aries.blueprint")
or add the bundles that needed to be started to the osgiDependencies of run:
osgiDependencies in run := bundleReqs("org.apache.aries.blueprint.core",
"org.apache.aries.proxy")
Apache Karaf also runs on felix. So for the most part you just need to install the correct bundles and maybe do the necessary system package exports if you hit package use constraint violations.
Check what karaf installs and try to do the same.
Maybe this question seems odd ?
I am working on OSGi-fication of our software based on Agents collecting some informations on servers.
Concerning Bundles update, it's natively supported by OSGi frameworks (OBR, Apache ACE, ...)
But, concerning the OSGI Container itself (Felix, Karaf, ...), is there a mechanism or a framework/tool having capacity to upgrade the container "automatically"?
Any idea? Any feedback?
Not in the OSGi specification. It assumes the framework is available on the classpath and can be launched. Any ability to update the framework implementation would be specific to a framework implementation as a value add.
I am reading "OGSi in Action" where in an interesting comment has been made :
"The module layer uses the metadata in bundles to make sure all their dependencies are satisfied before they can be used. This symbiotic relationship creates a chicken-and-egg situation when you want to use your bundles; to use a bundle you have to install it, but to
install a bundle you must have a bundle context, which are only given to bundles."
The book goes to great length in explaining bundle dependency resolution , but the "chicken and egg" scenario described above hasnt really been explored further. To install a bundle , BundleContext is needed, which is only provided to bundles. So who created the first "bootstrapping" bundle ? Is this contained in the "shells" that are provided (using packageAdmin?) ? PackageAdmin has
Bundle getBundle(Class clazz);
and Bundle can provide the BundleContext, but the bundle has to be installed first ... and so on !!
How does this work ?
See the Framework Launching API which provides the launcher with access to the system bundle's Bundle Context to install the "first" bundles.
From the javadoc of Bundle.getBundleContext():
If this bundle is not in the STARTING, ACTIVE, or STOPPING states or
this bundle is a fragment bundle, then this bundle has no valid
BundleContext. This method will return null if this bundle has no
valid BundleContext.
I do not know what the writer of the book thought about. If you install a bundle programmatically, you install it via the bundle context of other bundle.
With all my respect, I think this paragraph is wrong. This "chicken and egg" philosophical question could be raised in case of the system bundle. However, I do not think that answering the unnecessary question would give a better understanding for the reader, who wants to get started with OSGi.
Is there a way of controlling the order in which OSGi bundles inside a fuse esb fabric feature are loaded so that later bundles are dependent on the complete loading of earlier ones? For example, in the following feature, I want the simple-client module to only start up once the previous bundles have fully loaded:
<features name="simple-service-features">
<feature>
<bundle>mvn:com.company/simple-datasource/0.0.0</bundle>
<bundle>mvn:com.company/simple-model/0.0.0</bundle>
<bundle>mvn:com.company/simple-service/0.0.0</bundle
<bundle>mvn:com.company/simple-client/0.0.0</bundle>
</feature>
</features>
You can use the attribute start-level of bundle tag in the features.xml to sequence the OSGI bundles start.
A start level is associated with every bundle. The start level is a positive integer value that controls the order in which bundles are activated/started. Bundles with a low start level are started before bundles with a high start level. Hence, bundles with the start level, 1, are started first and bundles belonging to the kernel tend to have lower start levels, because they provide the prerequisites for running most other bundles.
Is anyone using Karaf instead of Servicemix? If so, how did you come to this decision? I'm aware that Servicemix adds a layer of functionality around Karaf, just curious if Karaf is being used on its own and why...
We're using Karaf for a number of our applications. We were already using Camel (JMS and Esper) for integration between several different platforms (a JBoss 4.2 instance, a Tomcat and several Felix instances) and as this was working well there was little justification in migrating this too (which would have been cause to consider ServiceMix).
The only reason we have some Felix nodes, is that they're limited in use (on client desktops), rarely need/get updated and I wanted the smallest footprint for these nodes. For anything OSGi on the serverside we're using Karaf.
Karaf provides all of the features you'd expect and need for a production environment (see the apache-karaf tag's info). We do our development and testing against standard minimal framework (using pax-exam) but deploy to Karaf.
If you don't need an ESB, JCA, BPEL, etc but want a solid, tunable OSGi container, then Karaf on it's own is more than adequate. (And if you found yourself needing a limited subset of ServiceMix's functionality you can always install these in a Karaf instance).
You can also customise the Karaf distribution as part of a maven build - personally I like have the container as part of the application's build, as I can checkout, build and run the entire setup from the command line in minimal time.
Recently there's a clustering subproject of Karaf called Cellar using HazelCast, I not sure if this applies to ServiceMix too.
Karaf's life started as the ServiceMix core. Currently, ServiceMix is really a set of bundles that are deployed into a Karaf container. ServiceMix has a number of very handy bundles which do a lot of cool stuff that karaf doesn't. That said, the two primary reason for using ServiceMix is if you want:
1) an ESB,
2) NMR (a feature that allows you to community between bundles AND instances of Karaf).
This all said, the ServiceMix group is currently planning version 5, which will remove the ESB and NMR features and will be focused on being a management container for Camel. In ESB's a great deal of effort when into creating components that could be described using BPL (Business Process Language). However, the folks that wrote ServiceMix began to focus on the implementation of EIP's (Enterprise Integration Patterns) which largely does the same stuff as BPL, but does it in a more standardized and accepted manner. This work was done under the Camel project.
So, in short. If you are using ServiceMix 4+, you're also using Karaf. If you want a more robust integration environment, the environment of choice today (in the Apache/Felix world at least) is Karaf, Camel, and a few bundles from Servicemix.
Here's a little comparative illustration I made. Going from the simplest case (JVM with OSGi functions provided by Apache Felix at the bottom), to more complete/manageable OSGi functions (Apache Karaf in the middle), to enough functions to implement complete ESB instances (Apache ServiceMix at the top) (note that "an ESB" is not a product but a set of endpoints, routers, databases, ETL functions and whatnot configured together in a particular task-specific way).
Karaf does NOT come with CXF.
Its pure extracted kernel of ServiceMix. However, you can install CXF on Karaf as below.
karaf:root()> feature:repo:add cxf
Once the feature URL is added we can see the "provided" features by using the following command.
karaf:root()> feature:repo:feature:list | grep cxf
To install cxf fire the command below
karaf:root()> feature:install cxf