In all versions of SLF4J that I've looked at after 1.6.0, the slf4j-api MANIFEST.MF looks like (this is in 1.7.21):
Import-Package: org.slf4j.impl;version=1.6.0
But the backends (e.g. slf4j-log4j12) say:
Export-Package: org.slf4j.impl;version=1.7.21
This doesn't fit together, it leads to unresolved package wiring.
I know that lots of people use SLF4J in OSGi. Heck, I use it, and it works, but pax-logging may be obscuring the issue. Am I missing something?
Import-Package: org.slf4j.impl;version=1.6.0
Specifying an exact version at Import-Package means version 1.6.0 or greater. Therefore this line does not cause an unresolved package.
However, all of the SLF4J implementation bundles need the API, too. By having this rule, we get a cyclic dependency. SLF4J guys solved this issue by making each implementation bundles as fragment bundles of the API.
In every implementation bundle you can see these:
Fragment-Host: slf4j.api
and
Import-Package: org.slf4j;version=1.7.21,...
Based on the MANIFEST headers: The implementation bundle must be at least version 1.6.0 and the API bundle version must be at least as big as the version of the implementation bundle.
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.
Short version:
How can I configure the maven POM of a AEM / CQ5 content package so the package embed different versions of the same OSGI bundle ?
Long version:
I'm building a content package for AEM (CQ5). This content package embed direct and indirect osgi dependencies needed for the project.
I have an issue with one of the bundle (let's call it BundleX) who remain inactivated after the content-package is deployed because of an unresolved package import on a specific version of Google Guava. Guava is part of the osgi dependencies that I embed with the project. The problem is that different bundles are dependent on different versions of Guava.
So I have:
project-content-package:
MyBundle:
depends on Guava:15.0 ( I do need this version for some features)
BundleX
depends on Guava:r06 (r06 < 15.0. I don't have the control on this bundle)
When making my content package, I'd like to embed the two guava versions. As we know, OSGi supports multiple versions of packages deployed at the same time.
Until now, in my AEM content package pom configuration, I had:
<plugin>
<groupId>com.day.jcr.vault</groupId>
<artifactId>content-package-maven-plugin</artifactId>
<configuration>
<embeddeds combine.children="append">
<embedded>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<target>${cq.slingUrlSuffix}</target>
</embedded>
...
</embeddeds>
...
</configuration>
...
</plugin>
The version of the embedded dependency is determined by maven and of course is unique for this maven project.
So, to sum up, to solve by problem, I should:
embed multiple versions of Guava in osgi container. The only solution I see is creating another artifical content package pom just to upload the other Guava dependency. But it's far to be optimal since I'd like my main package to contain all embedded osgi dependencies.
override the version of the dependency of bundle2 from r06 to 15.0, so I need only Guava 15.0 in my container. Since I don't have the control on this bundle, I should override that from outside, but I have no idea if it's possible to do that.
In advance, thank you very much for your help !
The Apache Sling OSGi installer that AEM uses under the hood does not support installing several versions of the same (meaning having the same Bundle-SymbolicName) bundle. So just adding several versions of a bundle in a content package won't help, the highest bundle version always wins and the other ones are not installed.
You can install multiple versions using the standard OSGi tooling, like the webconsole.
A workaround is to repackage a bundle with your own symbolic name (like "foo.0.15" for V0.15) so that the Sling installer considers multiple versions as distinct bundles and installs them all.
In both cases those bundles to have the correct version ranges in their Export-Package statements, to avoid conflicts.
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
We have a Maven built Netbeans 7.1 rcp application that successfully mixes OSGi modules (packaging: bundle) and Netbeans modules (packaging: nbm) by wrapping the OSGi modules in Netbeans module wrappers. We want to migrate from using these wrappers to using the OSGi modules directly to simplify the build. There are around 30 wrapper, osgi module pairs and I would like to tackle the removal of the wrappers, one module pair at a time.
However when we replace a specific wrapper dependency with its osgi dependency in a modules pom that depends on it, and use the
<useOSGiDependencies>true</useOSGiDependencies>
in the nbm-maven-plugin configuration. Any other dependencies to other wrappers suddenly fail to build with transitive dependencies not available at runtime error.
Project uses classes from transitive module [xxx] which will not be accessible at runtime.
-- where [xxx] is the name of the OSGi module.
Of course I can fix the build by replacing the wrapper dependencies with the OSGi modules they were wrapping, but that escalates the size of the migration task considerably.
Once Ive got a build by "fixing" these transient dependencies the OSGi module that I picked to migrate appears successfully in a new cluster “extra”.
But at runtime the rcp fails to find the other osgi modules because, I guess, elsewhere in the build, they are still being referenced through wrappers.
Is there any way these wrappers and direct OSGi dependencies can co-exist? Or do I have to migrate all of the Netbeans wrappers to OSGi in one go?
Many thanks,
Phil Wilkinson.
Looks like theres no way to do this one wrapper at a time, its all-or-nothing with useOSGiDependencies. :(
You can change them to useOSGiDependencies=true one module at a time.
A detailed step-by-step guide would probably be too long for an answer, so here are some general rules for this to work:
Use nbm-maven-plugin version >= 3.11. Lower version has some bugs.
NBM wrapper's OpenIDE-Module & OpenIDE-Module-Specification-Version must match the wrapped bundle's Bundle-SymbolicName & Bundle-Version respectively.
If the bundle has package versioning, that has to be copied into the NBM wrapper's MANIFEST.MF as Netigso-Export-Package.