I get an error whenever I try to install the iPOJO bundle.
If I install it by itself or as a part of a content package I still get the error:
Unresolved constraint in bundle org.apache.felix.ipojo [612]: Singleton conflict.
I am using iPOJO 1.11.2 and deploying it as a part of an AEM package.
I couldn't find this package in the framework bundle, nonthelesse you could try the following and don't provide it with your package:
In your sling.properties File you have a key called "org.osgi.framework.bootdelegation". There you could try to add "org.apache.felix.ipojo.*" to the comma separated list.
Depending on the way AEM is started, the sling.properties file is located in a different folder. Best is to search for it an keep them in sync if you find more than one.
This is how you can make system packages that are hidden by default accessible in OSGi. I had to do this for org.w3c.* and for com.sun.jndi.*
You most likely already have deployed a version of iPOJO and are trying to install a second version.
This is prohibited through the iPOJO manifest that contains: Bundle-SymbolicName: org.apache.felix.ipojo;singleton:=true. I didn't know this header until a few minutes ago, but this is what the OSGi Core R4 spec says:
singleton – Indicates that the bundle can only have a single version resolved. A value of true
indicates that the bundle is a singleton bundle. The default value is false. The Framework must resolve at most one bundle when multiple versions of a singleton bundle with the same symbolic name are installed. Singleton bundles do not affect the resolution of non-singleton bundles with the same symbolic name
Chose the version of iPOJO you want to use and remove the other.
Related
I created one maven project with aem-project-archetype version 13.
After installing the bundle to AEM, I am getting error in felix console that 3 of the imported bundles could not be resolved.
I am trying to find out that from where these are being included into my manifest file which is inside the target/MANIFEST folder.
so that i could modify the versions of the respective bundles.
the error i am geting in felix console, my bundle is in installed state, not active
org.apache.sling.api.resource,version=[2.10,3) -- Cannot be resolved
org.apache.sling.api.servlets,version=[2.2,3) -- Cannot be resolved
org.apache.sling.models.annotations,version=[1.4,2) -- Cannot be resolved
When you're developing AEM applications, the OSGI bundle (and Manifest) is typically generated via the Felix maven-bundle-plugin.
The plugin writes your package imports based on the java packages you import in your all of your Java code. If you are importing from a maven dependency, say Sling the version for that import will be the package version from Sling.
The issue you are having here could be one of two
The package you are importing does not exists in OSGI (AEM Instance)
There a mismatch between the version in your maven dependencies and the version in OSGI (AEM instance). Hence OSGI cannot resolve the version you are importing.
2. is likely the case because sling is always bundled with AEM.
What can you do to debug/fix?
You can go to http://localhost:4502/system/console/depfinder
and try your packages there to see what version is actually exported
in OSGI.
Check wha versions of your dependencies you have in your pom.xml
and make sure the OSGI version is within the range specified by the
manifest imports. You can use maven dependency tree to list all
your dependencies and their versions.
This specific to AEM, if you are using uber-jar make sure you are
using the correct version for the correct AEM instance you're
running.
Note that in manifest imports the range [2.10,3) means it accepts all versions between 2.10.0 and 3.0.0 but NOT including 3.0.0. In my experience, Maven bundle plugin will always write the range where the min is your maven dependency package version and the max is the next major version.
Changing the imports manually:
This is not recommended and has very specific use cases, but you could manually tell the bundle plugin what version to add to the imports. See import-package instruction in the bundle plugin docs
These imports are based on the code you compiled against. There are not some nasty little tidbits that are there to pester you. Their purpose is to verify that what you run against is compatible with what you compiled against. I assume that the runtime has a lower version than you require. This implies that your compile path as setup in Maven has later versions than your runtime. If you could run your code you would likely run into Class Not Found Exception or No Such Method errors.
And maybe not. But then you might have the worse situation that things are not correct (promises made during compilation might not be fulfilled) and problems might happen much later after damage has been done.
This stuff is there for a very good reason. They are like earth pin on plugs, they protect you.
How to fix this? Take a look at your dependencies. Your must ensure you compile against a version that is lower or equal then what is present in your runtime. You can first look at the versions in your POM. If these versions are not there then look at the compile path Maven uses.
Replacing the numbers in the manifest is like sawing off the earth pin on a plug because otherwise it won't fit in the wall ... bad idea.
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 have a bundle (jersey-server) that imports a package (org.objectweb.asm) with a resolution of optional and no version specified:
org.objectweb.asm;resolution:=optional
Currently, our application is deployed to Apache Karaf (using the Equinox framework), which exports a new version of this package (org.objectweb.asm), namely version 4.0. The problem I am attempting to solve is that since the jersey-server bundle does not specify a version for the package it is wiring to 4.0. However, the version of jersey-server I am using (1.12) is incompatible with this version. I have a 3.1 version of the package available in the container that I need the jersey-server bundle to wire to.
I have attempted to use a fragment to suit my needs, but it does not appear to be working. I don't fully understand how fragment import-package conflict resolution works in Equinox (or Felix) to know if what I'm trying to do is even possible. Perhaps there is another way?
No, fragments are additive only. I.e. they can add extra imports to their host bundles, but they cannot replace or remove the imports of the host.
The jersey-server bundle is simply broken and must be fixed.
I had a similar issue with pax-web, I created a "workaround" for it:
https://github.com/ops4j/org.ops4j.pax.web/tree/master/pax-web-features/xbean-fragment
it's available also through maven:
http://search.maven.org/#artifactdetails%7Corg.ops4j.pax.web%7Cxbean-fragment%7C3.0.0.M2%7Cbundle
Is there a simple way to understand why Bndtools OBR resolution has decided it needs a particular bundle to satisfy the run requirements? In my particular case, I have all org.slf4j.* packages in -runsystempackages, but it still insists on including slf4j-api.
Are there bundle fragments involved? Fragments need to be installed into a host bundle, and in the case of SLF4J, the static binding mechanism is expecting to be installed into the slf4j.api bundle.
I'm building an OSGi-based web application consisting of just two bundles for now. In one of them, I'm loading process instances from a process engine. Each process instance is supposed to correspond with a specific version of the other bundle, which it was initially assigned to.
For example, I would like to load one process instance in Bundle A and work with it using packages from bundle B in version 1.0. Afterwards, I would get hold of another process instance and work with it using packages from bundle B in version 2.0.
Do you see any way to achieve this functionality?
Thank you very much in advance!
Johannes
Bundle A can only be exposed to a single version of a package at any given point. So other than possibly just using reflection, Bundle A cannot use 2 versions of the same package exported by different versions of Bundle B.
Or, do you mean that the 2 versions of Bundle B implement that same package differently. Then Bundle A could see different implementation objects from the 2 versions of Bundle B because they appear to be the same interface type to Bundle A. If this is the case, then OSGi services are the best way for Bundle B to publish these objects for Bundle A to use.