How to read error messages when obr deploy command fails?
Here is an example:
-> obr deploy configuration-exporter
Unsatisfied requirement(s):
---------------------------
(&(package=com.google.common.collect))
RoutingService :: DAO
(&(package=com.sybase365.routingservice))
ARF :: Service Bundle :: Configuration Exporter
(&(package=com.google.common.base))
RoutingService :: DAO
(service=org.osgi.service.event.EventHandler)
Apache Felix EventAdmin
(&(package=com.google.common.base))
ARF :: Service Bundle :: Configuration Exporter
(|(ee=J2SE-1.5))
Guava: Google Core Libraries for Java 1.5
(&(package=com.google.common.collect))
ARF :: Service Bundle :: Configuration Exporter
(service=org.osgi.service.event.EventHandler)
Apache Felix EventAdmin
How to read the above message? What is actually unsatisfied?
I assume that your obr is missing packages:
com.google.common.collect
com.sybase365.routingservice
com.google.common.base
com.google.common.base
com.google.common.collect
and then you probably don't have some services running:
org.osgi.service.event.EventHandler
and you probably don't have the required java-runtime:
J2SE-1.5
I usually take the first missing package - and try to resolve it. If it gets rid of that error, I keep going. If not - then something is wrong with your osgi runtime. Perhaps your are missing some bundles that it needs in order to do the deploy?
Related
I am new to Karaf and Camel and I'm trying to deploy custom camel routes (java) and I'm facing a lot of problems at the time of deploying the camel bundle (.jar) in the hot deploy directory.
What I got so far:
Apache Karaf 4.3.1 running in docker container
Bundle .jar with the java defined route
My idea is to have a /deploy directory mapped to the karaf container so any .jar that's added to that directory is deployed (or maybe build a new image for karaf).
When I tried to add my current bundle to the directory I got the following error message:
20:19:32.490 INFO [fileinstall-/opt/karaf/deploy] Installing bundle org.apache.karaf.examples.karaf-camel-example-java / 4.3.1
20:19:32.535 WARN [fileinstall-/opt/karaf/deploy] Error while starting bundle: file:/opt/karaf/deploy/karaf-camel-example-java-4.3.1.jar
org.osgi.framework.BundleException: Unable to resolve org.apache.karaf.examples.karaf-camel-example-java [111](R 111.0): missing requirement [org.apache.karaf.examples.karaf-camel-example-java [111](R 111.0)] osgi.wiring.package; (&(osgi.wiring.package=org.apache.camel)(version>=3.6.0)(!(version>=4.0.0))) Unresolved requirements: [[org.apache.karaf.examples.karaf-camel-example-java [111](R 111.0)] osgi.wiring.package; (&(osgi.wiring.package=org.apache.camel)(version>=3.6.0)(!(version>=4.0.0)))]
at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4368) ~[?:?]
at org.apache.felix.framework.Felix.startBundle(Felix.java:2281) ~[?:?]
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998) ~[?:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [!/:3.6.8]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [!/:3.6.8]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:520) [!/:3.6.8]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [!/:3.6.8]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [!/:3.6.8]
I think this can be solve with a maven bundle "wrap" but I'm not sure if this is correct, and if so, how should I wrap the bundle?
Thank you for reading :D
A bit late but hope this helps someone as I've fiddled with this setup quite a bit for the past year while exploring OSGi, Karaf, Camel and Docker.
If you want to do local development with karaf you can actually map your maven repository to the container which can make installing bundles and features quite a bit easier.
Example Docker compose for Karaf
Here's a docker-compose for karaf 4.2.11 but you can probably change it to 4.3.1 without any problems. (add :z on volumes if using SELinux)
version: "2.4"
services:
karaf-runtime:
container_name: karaf
image: apache/karaf:4.2.11
ports:
- 8101:8101
- 8181:8181
- 1098:1098
volumes:
- ./karaf/etc:/opt/apache-karaf/etc
- ./karaf/deploy:/opt/apache-karaf/deploy
- karaf-data:/opt/apache-karaf/data
- ~/.m2:/root/.m2
- karaf-history:/root/.karaf
command: [ karaf, server ]
volumes:
karaf-data:
karaf-history:
Just save it to a empty folder somewhere as docker-compose.yml. Create folder named karaf to the folder and then fetch the default configurations from karaf using couple docker commands:
# Start detached karaf container with name karaf
docker run --name karaf -d apache/karaf:4.2.11
# copy files from container to host-system
docker cp karaf:opt/apache-karaf/etc ./karaf/
# stop the container
docker stop karaf
Setting karafs etc folder as shared volume makes it easy to tweak and share the configurations through version control for other developers.
To start Apache karaf with docker compose you can use following commands:
# Start
docker compose up -d
docker-compose up -d
# Stop
docker compose down
docker-compose down
# note: docker compose = newer version of docker-compose command
Creating bundles
Easy way to create bundles is to use one of the official archetypes karaf-bundle-archetype or karaf-blueprint-archetype when creating the project.
For projects using Apache Camel it is generally easier to use karaf-blueprint-archetype. With it you configure the CamelContext in the xml blueprint file found in projects resources/OSGI-INF/blueprint/ folder.
Example:
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">
<bean id="ExampleRoute" class="com.example.ExampleRouteBuilder" />
<camelContext id="ExampleContext" xmlns="http://camel.apache.org/schema/blueprint">
<routeBuilder ref="ExampleRoute" />
</camelContext>
</blueprint>
With ~/.m2:/root/.m2 shared volume you can just package the project using mvn clean install to your local maven repository which you can then use in karaf to install the bundle using bundle:install mvn:groupId/artifactId/version
If you want to use deploy folder you can copy artifacts to container using docker cp ./target/exampleBundle.jar karaf:/opt/apache-karaf/deploy
Adding camel feature to karaf
As for camel you can follow the official guide on how to add camel feature repository and the features you need.
But the steps are basically:
# Add camel feature repo
feature:repo-add camel <version>
# Install camel feature
feature:install camel
# List available camel features for install
feature:list | grep camel
# Install camel features you need
feature:install <feature-name>
Missing requirements
When installing bundles often encounter missing requirement exception that tells you that package that the bundle depends on is missing from karaf which means you'll have to install bundle or feature that exports the said package.
These messages are usually best read starting from the end:
(osgi.wiring.package=org.apache.camel)(version>=3.6.0)(!(version>=4.0.0)
The above tells you that karaf installation doesn't have camel installed. OSGi bundles expect OSGi framework/runtime to satisfy their dependencies which is quite a bit different from say standalone SpringBoot projects.
Shared volumes and new files
When it comes to sharing config files or karaf deploy folder it's good to know that Docker has some issues related to new files in shared volumes. If new file is added/created using host-systems file-system there's chance that karaf will not detect these files or changes made to them.
It's generally better to use docker cp path/to/file/on/host karaf:/path/to/folder/on/container to deploy new files to container even if its shared volume.
otherwise you might have to shell in to the container and make copy of the file in question and
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 make a custom mediator class that used spring jdbc to access data from database. I make a jar from that class and deploy it in WSO2_HOME/repository/components/lib. After that I add the following jar to the same folder : spring-jdbc.jar, spring-tx.jar. But when I tried the custom mediator there is an error "ClassNotFoundException org\springframework\transaction\support\TransactionSynchronization". The problem is I'm pretty sure that "TransactionSynchronization" class is available in the spring-tx.jar. Can anyone help me to solve this problem? :)
One reason may be there are two packages in your class path which has the same 'TransactionSynchronization' class. Can you try the below.
What do you have in your WSO2_HOME/repository/components/dropins directory? Delete all jars inside dropins and restart the server and recheck for the issue.
If the error is still there try deleting spring-tx.jar from WSO2_HOME/repository/components/lib & WSO2_HOME/repository/components/dropins. Then restat the server. Then check whether you are getting the same error or different error?
I am experiencing the same behavior. I have a custom spring mediator that calls out to a database for role based authNZ. I am running esb v 4.7.0.
I downloaded spring-tx-3.1.0.RELEASE.jar from the maven repository and copied it to /usr/local/wso2/wso2esb-4.7.0/repository/components/lib in my environment, then restarted the ESB. When I issue requests to my proxy service, the same class not found exception occurs.
I was examining jar contents today and when I checked the spring-tx jar in /usr/local/wso2/wso2esb-4.7.0/repository/components/lib, the class in present:
jar tf spring-tx-3.1.0.RELEASE.jar | grep TransactionSynchronization
org/springframework/transaction/support/TransactionSynchronization.class
When I do the same in /usr/local/wso2/wso2esb-4.7.0/repository/components/dropins after restart of the esb, the class is not present:
jar tf ../dropins/spring_tx_3.1.0.RELEASE_1.0.0.jar
spring-tx-3.1.0.RELEASE.jar
META-INF/
META-INF/p2.inf
META-INF/MANIFEST.MF
Notice that the spring-tx jar is not included in the OSGi bundle after restart of Synapse.
I will investigate further tomorrow, including building an OSGi bundle that contains the Spring dependencies I need via Eclipse
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.
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.