I have the following error:
in text :
Error executing command: Error restarting bundles:
Unable to start bundle 278: Uses constraint violation. Unable to resolve resource demo-persistence-jpa [demo-persistence-jpa [278](R 278.0)] because it is exposed to package 'javax.persistence' from resources javax.persistence [javax.persistence [248](R 248.0)] and org.apache.geronimo.specs.geronimo-jpa_2.0_spec [org.apache.geronimo.specs.geronimo-jpa_2.0_spec [266](R 266.0)] via two dependency chains.
Chain 1:
demo-persistence-jpa [demo-persistence-jpa [278](R 278.0)]
import: (&(osgi.wiring.package=javax.persistence)(version>=2.1.0))
|
export: osgi.wiring.package: javax.persistence
javax.persistence [javax.persistence [248](R 248.0)]
Chain 2:
demo-persistence-jpa [demo-persistence-jpa [278](R 278.0)]
import: (osgi.wiring.package=org.hibernate.proxy)
|
export: osgi.wiring.package=org.hibernate.proxy; uses:=javax.persistence
com.springsource.org.hibernate [com.springsource.org.hibernate [230](R 230.0)]
import: (&(osgi.wiring.package=javax.persistence)(version>=1.0.0)(!(version>=2.0.0)))
|
export: osgi.wiring.package: javax.persistence
org.apache.geronimo.specs.geronimo-jpa_2.0_spec [org.apache.geronimo.specs.geronimo-jpa_2.0_spec [266](R 266.0)] Unresolved requirements: [[demo-persistence-jpa [278](R 278.0)] osgi.wiring.package; (osgi.wiring.package=org.hibernate.proxy)]
as you can see the problem is my bundle demo-persistence-jpa imports the package `javax.persistence which is available via two chains, this I understand
what I don't understand :
My bundle imports within the range version>=2.1.0
org.hibernate.proxy imports within the range (version>=1.0.0)(!(version>=2.0.0))), so there should be no problem
My bundle imports org.hibernate.proxy
so there should be no problem, as the version required by my bundle is not the same as the one required by org.hibernate.proxy
or am I mistaken ?
The problem is
demo-persistence-jpa needs both javax.persistence and org.hibernate.proxy.
hibernate bundle exports org.hibernate.proxy
hibernate bundle states it uses:=javax.persistence
for the resolver this means that whoever uses packages from hibernate bundle has to be wired to the exact same bundle/classloader providing javax.persistence that hibernate bundle is wired to.
If the runtime din't ensure that and each was wired to different bundles/classloders you would get ClassCastException the moment something from hibernate bundle returns you an object from javax.persistence because it will be coming from different classloader.
In the case above, the resolver can no ensure that because hibernate bundle needs javax.persistence version to be lower than 2.0 and demo-persistence-jpa needs the version to be higher than 2.1!
The solution is to either :
use newer version of hibernate (assuming there is one) that works with javax.persistence >= 2.1
make demo-persistence-jpa import javax.persistence < 2.1
I think the problem is that you have two bundles providing the spec in two different versions. This will not work. You have to make sure you can get along with just one jpa spec bundle.
How do you install hibernate and your own bundle? If you use the Apache karaf feature for hibernate it should work.
Related
What OSGi bundle should I install for javax.json package for RS services?
I've got an error:
Caused by: java.lang.NoClassDefFoundError: javax/json/JsonException
at org.eclipse.persistence.internal.oxm.record.SAXUnmarshaller.getNewXMLReader(SAXUnmarshaller.java:209)
at org.eclipse.persistence.internal.oxm.record.SAXUnmarshaller.getXMLReader(SAXUnmarshaller.java:197)
at org.eclipse.persistence.internal.oxm.record.SAXUnmarshaller.unmarshal(SAXUnmarshaller.java:452)
at org.eclipse.persistence.internal.oxm.record.SAXUnmarshaller.unmarshal(SAXUnmarshaller.java:400)
at org.eclipse.persistence.internal.oxm.record.SAXUnmarshaller.unmarshal(SAXUnmarshaller.java:741)
at org.eclipse.persistence.internal.oxm.XMLUnmarshaller.unmarshal(XMLUnmarshaller.java:649)
at org.eclipse.persistence.jaxb.JAXBUnmarshaller.unmarshal(JAXBUnmarshaller.java:349)
at org.eclipse.persistence.jaxb.rs.MOXyJsonProvider.readFrom(MOXyJsonProvider.java:668)
The JSON bundle I've installed:
JSR 353 (JSON Processing) Default Providerorg.glassfish.javax.json
Symbolic Name org.glassfish.javax.json
Version 1.0.4
Bundle Location initial#reference:file:plugins/org.glassfish.javax.json_1.0.4.jar
The MOXy bundle:
EclipseLink MOXyorg.eclipse.persistence.moxy
Symbolic Name org.eclipse.persistence.moxy
Version 2.6.4.v20160829-44060b6
Bundle Location initial#reference:file:plugins/org.eclipse.persistence.moxy_2.6.4.v20160829-44060b6.jar
with import:
javax.json; resolution:=optional
It looks like everything should work fine, but it isn't. MoXy don't get the javax.json dependencies. What's wrong? Wrong version of bundle? Wrong loading order? What do I need to do to bring them to work?
It seems to be a general problem with how Equinox is resolving optional package imports.
The MoXy bundle was loaded before the JSon bundle, so the javax.json package was not available then. Because the reference was optional, it was 'resolved' as 'not provided', and Equinox has not re-resolved them after importing the json bundle.
The solution:
1) Influence the install order.
or
2) Set start level for Moxy to higher value then JSon.
I am trying to deploy a simple OSGI bundle (hello world) in glassfish 4.1.1 but I got the following error:
Infos: org.osgi.framework.BundleException:
Unresolved constraint in bundle com.mycompany.MavenHelloServiceImpl [324]:
Unable to resolve 324.0: missing requirement [324.0]
osgi.wiring.package; (osgi.wiring.package=com.mycompany.mavenhelloserviceapi)
at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3974)
I don't know how to fix the missing package , I already defined "com.mycompany.mavenhelloserviceapi" as a dependency in the bundle MavenHelloServiceImpl and it is present in the dependencies folder in the bundle MavenHelloServiceImpl
Any idea how to fix this error ?!
Having com.mycompany.mavenhelloserviceapi as a dependency in your pom.xml is not enough : the pom is about compile-time dependencies. you see here an issue about a runtime dependency missing.
You should install com.mycompany.mavenhelloserviceapi in your container.
You should modify the project that contains com.mycompany.mavenhelloserviceapi as a bundle project and explicitly export this package. now deploy this bundle alongwith your hello world bundle.
Alternatively ,you can use Pax Wrap to deploy the jar that contains com.mycompany.mavenhelloserviceapi to glassfish without modifying the project.
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.
Hi I am not able to access content of my project, I have uploaded all the packages which are required to access content from CQ. Only thing I can see is
org.apache.sling.api.resource,version=[2.3,3) -- Cannot be resolved
Can this be the reason for exception and if yes please let me know how to resolve it.
CQ version 5.6
The error message means that the OSGi framework is unable to supply a version >= 2.3 and < 3 of the org.apache.sling.api.resource Java package for a bundle B that wants to import it.
As a result, bundle B cannot be activated, and parts of your system won't work.
Looking at the webconsole (under /system/console by default in Sling and CQ) you can see that this package is provided by the org.apache.sling.api bundle, so either you have an old version of that bundle in your system, or you have installed incompatible bundles that require a newer version of that package.
You can add the missing package by explicilty importring it. Accecess the pom.xml file in the core folder of your project core/pom.xml and list the dependency under Import-Package
<configuration>
<bnd><![CDATA[
Import-Package:
javax.annotation;version=0.0.0,
org.apache.sling.api.servlets;version="[2.3,3)",*
]]></bnd>
</configuration>
Check version of org.apache.sling.api.resource in package-info.class file in org.apache.sling.api.resource package in uber-jar.
You might have version between 2.3 and 3. Try installing lower version uber-jar that has package version <2.3
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.