How can I find unsatisfied constraints of a bundle which didn't start from Apache Karaf console? I.e. what is its equivalent of Equinox's diag command?
Which version of Karaf are you using? The following should be relevant to Karaf 2.x
Annoyingly the package:imports/package:exports commands only work on a bundle in the STARTED state.
If the bundle is only INSTALLED you can use: headers ${BUNDLE NUMBER} will highlight any missing imports in red.
Also trying to start a bundle should print to the console any unresolved constraints as an LDAP filter expression.
Related
I created a maven project in eclipse and installed the bundle in osgi console but the bundle is in Installed state. All the dependencies are reolved and there are no errors but still status is not active.
How to call the OSGI service from my AEM component page. Can i invoke the osgi service from my component jsp page only if bundle state is "active"? Do i need a ServiceID to be generated for my bundle for invoking the service.
Try this -
Tail your error logs
On browser goto /system/console/bundles
Search for you bundle and try activating it manually (use the play button on right side of bundle entry)
If bundle is active successfully then possibly u need to fix you deploy script so it starts the bundle after installing
If bundle still doesn't start, look at the logs. There could be possible wiring issue or in case you have activator class for bundle its throwing exception while activating the bundle
Please go to felix console and activate the bundle using play button .
If still it doesn't get activated,expand the bundle there will be some error in the bundle(it will be shown in red).
So you need to resolve the class where the error is shown.
I hope this is helpful.
Thanks.
I am attempting to create a Websockets- based application using the Grizzly Websockets bundles. I am doing this in Apache Felix using Bndtools.
Unfortunately, I seem to have all the needed dependencies, but the Grizzly bundles are failing to load due to the following failure:
org.glassfish.grizzly.websockets-server-2.3.23Unable to resolve
org.glassfish.grizzly.websockets-server [23](R 23.0): missing
requirement [org.glassfish.grizzly.websockets-server [23](R 23.0)]
osgi.wiring.package; (osgi.wiring.package=sun.misc) Unresolved
requirements: [[org.glassfish.grizzly.websockets-server [23](R 23.0)]
osgi.wiring.package; (osgi.wiring.package=sun.misc)]
I have researched this failure, originally looking for a bundle, only to discover that apparently this is some kind of JVM library that is really not needed. I have seen workarounds and solutions that involve adding a line to a conf/config.properties file:
org.osgi.framework.system.packages.extra=sun.misc
I understand that this is a dangerous workaround, and there are rumors of "safer" solutions to this problem. They all involve making changes to tags or to the config.properties file.
Unfortunately, in a Bndtools environment, there are apparently no such tags or files for me to edit!
Or, at least, I cannot find these things in my Bndtools project.
Is there some way to fix this "sun.misc" problem within a Bndtools- based project? I am using Bndtools repository and am wondering which of the various "bnd" files I need to edit, as well as what to put into those files.
Someone please advise...
You need to add -runsystempackages: sun.misc to the bnd/bndrun file.
The best tool for that is https://github.com/diffplug/osgiX
You just will change PKG=sun.misc(or another package) in gradle.properties and run gradlew build.
It will generate bundle-fragment, which you will can add to your class path.
The bundle then contains:
Manifest-Version: 1.0
Export-Package: sun.misc
Fragment-Host: system.bundle; extension:=framework
Bundle-ManifestVersion: 2
Bundle-License: public domain - http://unlicense.org/
Bundle-SymbolicName: com.diffplug.osgi.extension.sun.misc
Bundle-Version: 0.0.0
I'm trying to use the servlet-api version 3 in an Adobe CQ5 installation, without much success.
there is already a bundle that exports the javax.servlet package (version 2.5), so I deployed a bundle with version 3.1.0. this bundle starts ok.
The problem is starting the bundle that uses the api v3. I am getting an OSGi exception that I cannot fully understand:
POST /system/console/bundles/250 HTTP/1.1] cqse-httpservice %bundles.pluginTitle: Cannot start (org.osgi.framework.BundleException:
Constraint violation for package 'javax.servlet' when resolving module 250.9 between existing import 266.0.javax.servlet
BLAMED ON [[250.9] package; (&(package=javax.servlet)(version>=3.0.0)(!(version>=4.0.0)))]
and uses constraint 22.1.javax.servlet
BLAMED ON [[250.9] package; (package=com.day.cq.wcm.foundation.forms), [210.0] package;
(&(package=org.apache.sling.api.resource)(version>=2.0.0)), [93.0]
package; (&(package=javax.servlet)(version>=2.4.0))])
bundle 266 exports javax.servlet v=3.10 (I installed this one)
bundle 22 exports javax.servlet v=2.5 (provided by CQ5)
bundle 250 (mine) imports javax.servlet,version=[3.0,4) from 266. It also imports packages from 210 and 93.
bundle 210 imports javax.servelt v=2.5 from 22 (but the import in manifest does not have a version. maybe this is the problem?)
bundle 93 has javax.servlet; version="2.4" in the Import-package. but it resolved to javax.servlet,version=2.5.0 from (22) somehow.
The problem seems to be around the dependencies of bundle 250, but Im not sure what is the problem. AFAIK two versions of a package can coexist in an OSGi container. bundles 210 and 93 are running without issues.
This is most likely due to the fact that the used http-service only supports servlet 2.5 that's why this is the pre-installed servlet version. Since you installed a servlet 3.0 api your bundle does resolve but as it tries to export a service which is picked up by the http-service you run into this issue. The root cause is the http-service implementation that is used. I don't know if this would work but you might try to replace the http service version by using Pax-Web 2 or 3 instead. Pax-Web does support Servlet API since version 2.
After reading the article left in the comments, I noticed that dependencies of my bundle expose classes of the servlet api 2.5. This is causing the constraint and prevents my bundle. If I understand correctly the classpath from bundle 210 is expanded up to my bundle.
So, the only option will be to remove the dependency of my bundle with the other bundles, which I am afraid I cannot do. I will have to deal without the V3 api
I have defined four bundles:
bundle 1 : export package x version 1
bundle 2 : import package x ver [1,2] and export package y;y uses x
bundle 3 : export package x version 2
bundle 4 : import package y and also import package x version 2
Using apache felix (distribuable binary), I found that I should manually impose to not resolve (or start) the bundle 1 and then bundle 2 before starting the bundle 3 (otherwise a uses constraint problem appears because bundle 2 will use package x version 1 and in bundle 4 will appear package x version 1 and version 2 --> uses constraint violation).
Thanks to the authors of these posts:
http://njbartlett.name/2011/02/09/uses-constraints.html
http://blog.springsource.com/2008/10/20/understanding-the-osgi-uses-directive/
I don't like to impose order to my bundles, I need to copy all my bundles in the /bundle directory and then the instance of framework install and start them.
I noticed that Apache felix sorts the bundles to be installed alphabetically (so bundle 1 will be installed and then started the first).
I tried with Apache karaf, I copied my bundles into /deploy and I found that the problem disappears, so my question is:
Does Apache Karaf, (or felix file install) apply a strategy to impose any order for starting bundles in order to avoid these kind of problems ?
You should try to use a Karaf feature for this kind of deployment. You create a feature file with one feature in it and add all the bundles to this feature. Karaf will then load all the bundles and resolve and start them in one pass. So the resolver should bee able to correctly resolve all your bundles.
Apache Karaf does automatically add a startlevel to the bundles in the deploy folder this is configurable. The default of it is 50. So all your custom bundles are installed as StartLevel 50. This also makes sure the basic bundles of karaf itself are already up and running, especially the file-installer bundle.
Felix FileInstall does not have any ordering capability.
Start order isn't really important (bundles should be able to be started in any order), but a good Management Agent should be able to install and resolve a batch of bundles as a single operation. However FileInstall installs/resolves/starts bundles whenever it happens to poll the filesystem directory. Therefore FileInstall is not really usable for production deployment.
I don't know anything about Karaf, but any management agent that simply polls a directory is likely to have the same problem.
I am trying to understand/get a working example of PAX-EXAM. From my understanding, i need to deploy the bundle i want to test (in this case, boohoo-esb-common) and any bundles that it uses (in this case, camel-xstream).
However, when i try to run the test, pax-exam/felix fails to deploy the xstream feature. Below is the error i get in my console window when doing a: mvn clean install
ERROR: Bundle com.boohoo.boohoo-esb-common [25] Error starting file:/C:/Users/GARETH~1.HEA/AppData/Local/Temp/1346170773171-0/bundles/com.boohoo.boohoo-esb-common_1.0.0.SNAPSHOT.jar (org.osgi.framework.BundleException: Unresolved constraint in bundle com.boohoo.boohoo-esb-common [25]: Unable to resolve 25.0: missing requirement [25.0] osgi.wiring.package; (&(osgi.wiring.package=org.osgi.service.blueprint)(version>=1.0.0)(!(version>=2.0.0))))
org.osgi.framework.BundleException: Unresolved constraint in bundle com.boohoo.boohoo-esb-common [25]: Unable to resolve 25.0: missing requirement [25.0] osgi.wiring.package; (&(osgi.wiring.package=org.osgi.service.blueprint)(version>=1.0.0)(!(version>=2.0.0)))
at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3826)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191)
at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295)
at java.lang.Thread.run(Thread.java:662)
I've attached a simple example which should hopefully show what i mean.
Am i going about this in the right way? or am i not getting how to use pax-exam...
Your understanding is correct (you must provision all bundles you bundle-under-test requires), your execution is not :) You are still missing bundles. Apparently your bundle boohoo-esb-common requires a Blueprint Container.