Develop Reference

Insert bundle into osgi failed

Dear all:
I write a sample plugin and i want insert this bundle into my controller. But error occurs when i start it in the OSGI, it show:
gogo: BundleException: The bundle "org.opendaylight.controller.ping.plugin_0.4.0.SNAPSHOT [98]" could not be resolved. Reason: Missing Constraint: Import-Package: org.opendaylight.controller.sal.binding.api; version="[1.1.0,2.0.0)"
Referring from this post page, I think that I've got a newer version of a plug-in without its dependencies.
The error shows that the minimum version number of org.opendaylight.controller.sal.binding.api is 1.1.0, and mine version is 1.0-1 as i lookup in my directory of controller/opendaylight/distribution/opendaylight/target/distribution.opendaylight-osgipackage/opendaylight/plugins.
My question is how to switch the version from 1.0-1 to 1.1, i can find the 1.1 version of sal.binding.api in my directory: ~/.m2/repository/org/opendaylight/controller/sal-binding-api/1.1-SNAPSHOT.
As i look into my pom.xml, i foud my dependency is 1.1:
<dependency>
<groupId>org.opendaylight.controller</groupId>
<artifactId>sal-binding-api</artifactId>
<version>1.1-SNAPSHOT</version>
</dependency>
I think it's very strange.
Great appreciation for anyone's reply!
Best Regards,
Vinllen

Plugin versions should be in the form 'major.minor.micro.build', where 'major', 'minor' and 'micro' are all numbers, 'build' can be anything. So you should have something like 1.1.0.SNAPSHOT.

I have solved this problem: change the version 1.1 to 1.0-1 in pom.xml. After then , if have any other problems, change the version 1.1 to 1.0-1 with the different jar packet continue.

Unresolved constraint in bundle with Java 8 and Felix

I have an app running under Tomcat 6. The app contains/uses shared library, say Shared.jar. At some point it would copy Shared.jar with unique name, load it as an OSGi bundle into a Felix instance, and start it. In Shared.jar MANIFEST.MF there's
Import-Package: org.osgi.framework,javax.swing,javax.net,javax.net.ssl.
It's all fine with Java < 8, but with Java 8 the app itself starts fine, but starting a bundle fails with exception
Unresolved constraint in bundle [21431]: Unable to resolve 21431.0: missing requirement [21431.0] osgi.wiring.package; (osgi.wiring.package=javax.net)
What's wrong?

You need minimum Karaf 2.4 to support Java 8.
May be you would also need to add import package declaration in your pom.xml
<Import-Package>javax.net.*</Import-Package>
..but that doesn't look like the main issue, because it is working with older versions of JRE.

Guava conflict with Jboss 8 (Wildfly) and Java 8

I'm migrating my applications from Java 7 on JBoss 7.1, to Java 8 and Wildfly (Jboss 8.1).
When I tried starting Wildfly I got an error, the server was up but my app wasn't loaded. Looking on the Caused By I can see a more descriptive problem:
Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type Set with
qualifiers #Default at injection point [BackedAnnotatedParameter]
Parameter 1 of [BackedAnnotatedConstructor] #Inject
com.google.common.util.concurrent.ServiceManager(Set) at
com.google.common.util.concurrent.ServiceManager.(ServiceManager.java:0)
This ServiceManager class belongs to Google Guava. I have tried Guava 17, 16 and 15 and the problem still persists.
Update: I updated the question to give more details thanks to ColinD answer.
In my pom.xml I have:
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>17.0</version>
</dependency>
and the error is related to Guava 15. I took a look at my deployed application directory and saw that my lib directory contains two guava jars: guava-17.0.jar and guava-15.0-cdi1.0.jar.
I removed this strange guava-15.0-cdi1.0 jar file and my server started although my app didn't load. I think this is related to Wildfly dependencies and CDI.
Does anybody know how to resolve this conflict on Wildfly?

ServiceManager hasn't had #Inject or #Singleton on it since Guava 16.0. One way or another, it looks like you have a version of Guava <= 15.0 on your classpath.

Yes, this Sounds like you are packaging guava 15 or so. It definately works with guava 16. I know this because I had the Same problem. I was able to resolute it by packaging a later guava Version with my ears.
May it be that you are declaring a dependency to the guava module of wildfly instead of just packaging a guava lib with your deployment?

Apache CXF Dynamic Client creation

I am trying to use Apache CXF to talk to a unknown web service. I have followed the Dynamic Client example from Apache.
JaxWsDynamicClientFactory factory = JaxWsDynamicClientFactory.newInstance();
Client client = factory.createClient(wsdlURL.toExternalForm(), SERVICE_NAME);
This was working but now i am getting this exception when calling createClient():
java.lang.IllegalStateException: Unable to create schema compiler
Caused by:
javax.xml.bind.JAXBException
- with linked exception:
[java.lang.ClassNotFoundException: com/sun/tools/internal/xjc/api/XJC]
This looks similar to an existing bug. I am using DOSGi singlebundle 1.2 which includes cxf-minimal-2.2.9.jar; meaning the bug should be fixed in the version I'm using. the jaxb-api is included in my Apache CXF distribution which upon inspection contains jaxb-xjc.
Can anybody provide me some insight as to what I'm doing wrong? I swear this used to work.

"java.lang.ClassNotFoundException: com/sun/tools/ " is often occurs if you use JRE in your IDE intead of JDK.
Make sure, you use JDK in IDE (e.g. eclipse)

<dependency>
<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-xjc</artifactId>
<version>2.2.11</version>
</dependency>
resolved problem

Another solution is to include the cxf-rt-core in your Maven dependencies.

Package uses conflict: Import-Package: de.foo.bar; version="0.0.0"

I try to install a bundle in an OSGi environment (FUSE ESB) but do not manage to get it resolved. The error message is:
The bundle could not be resolved. Reason: Package uses conflict: Import-Package: de.foo.bar; version="0.0.0"
My bundle imports the package de.foo.bar.
The bundle which exports the package de.foo.bar does this with a 'uses' directive.
Export-Package = de.foo.bar;uses:="{other packages}";version="2.4.0"
As I understood I have to ensure that my bundle must import all other packages mentioned in the 'uses' directive of the de.foo.bar package (in the right version).
I checked this and also tried several version changes (0.0.0 and the real version numbers) but can not get it to work.
So, what does the error message realy means (maybe I understood it wrong)? What do I have to check?
Thanks for any help
Klaus
System Information:
FUSE ESB 4.2.0 (based on servicemix)
using maven-bundle-plugin 2.1.0 to generate OSGi MANIFEST header

I finally found what was wrong.
My bundle is a Spring Dynamic Module bundle and I did a mistake in the spring bean configuration (use a 'ref' instead a 'value' in a constructor-arg). Normally spring configuration errors are reported as such - I do not know why the current error resulted in the misleading message.
EDIT:
The faulty Spring configuration does not cause the uses conflict. It finally was the import of the package org.apache.log4j which is exported by different bundles (in my FUSE ESB container) and apparently was different wired to the bundles I tried to install.
Trying to solve my problem I found the article Diagnosing OSGi uses conflicts which I found helpfull to understand the problem.