Hi guys i am getting the below error while using feture install in karaf
org.apache.karaf.features.internal.util.MultiException: Error
at org.apache.karaf.features.internal.download.impl.MavenDownloadManager$MavenDownloader.<init>(MavenDownloadManager.java:84)[9:org.apache.karaf.features.core:4.0.3]
at org.apache.karaf.features.internal.download.impl.MavenDownloadManager.createDownloader(MavenDownloadManager.java:72)[9:org.apache.karaf.features.core:4.0.3]
at org.apache.karaf.features.internal.region.Subsystem.downloadBundles(Subsystem.java:358)[9:org.apache.karaf.features.core:4.0.3]
at org.apache.karaf.features.internal.region.Subsystem.downloadBundles(Subsystem.java:355)[9:org.apache.karaf.features.core:4.0.3]
at org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:191)[9:org.apache.karaf.features.core:4.0.3]
at org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:263)[9:org.apache.karaf.features.core:4.0.3]
at org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1079)[9:org.apache.karaf.features.core:4.0.3]
at org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:975)[9:org.apache.karaf.features.core:4.0.3]
at java.util.concurrent.FutureTask.run(FutureTask.java:262)[:1.7.0_79]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)[:1.7.0_79]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)[:1.7.0_79]
at java.lang.Thread.run(Thread.java:745)[:1.7.0_79]
Caused by: java.lang.Exception: Unable to create resource for bundle mvn:org.dt.dummy/Diff-Blueprint/0.0.1-SNAPSHOT
at org.apache.karaf.features.internal.region.Subsystem.createResource(Subsystem.java:567)[9:org.apache.karaf.features.core:4.0.3]
at org.apache.karaf.features.internal.region.Subsystem$1.downloaded(Subsystem.java:376)[9:org.apache.karaf.features.core:4.0.3]
at org.apache.karaf.features.internal.download.impl.MavenDownloadManager$MavenDownloader$1.operationComplete(MavenDownloadManager.java:133)[9:org.apache.karaf.features.core:4.0.3]
at org.apache.karaf.features.internal.download.impl.MavenDownloadManager$MavenDownloader$1.operationComplete(MavenDownloadManager.java:127)[9:org.apache.karaf.features.core:4.0.3]
at org.apache.karaf.features.internal.download.impl.DefaultFuture.notifyListener(DefaultFuture.java:344)[9:org.apache.karaf.features.core:4.0.3]
at org.apache.karaf.features.internal.download.impl.DefaultFuture.notifyListeners(DefaultFuture.java:329)[9:org.apache.karaf.features.core:4.0.3]
at org.apache.karaf.features.internal.download.impl.DefaultFuture.setValue(DefaultFuture.java:255)[9:org.apache.karaf.features.core:4.0.3]
at org.apache.karaf.features.internal.download.impl.AbstractDownloadTask.setFile(AbstractDownloadTask.java:61)[9:org.apache.karaf.features.core:4.0.3]
at org.apache.karaf.features.internal.download.impl.AbstractRetryableDownloadTask.run(AbstractRetryableDownloadTask.java:59)[9:org.apache.karaf.features.core:4.0.3]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)[:1.7.0_79]
at java.util.concurrent.FutureTask.run(FutureTask.java:262)[:1.7.0_79]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)[:1.7.0_79]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)[:1.7.0_79]
... 3 more
Caused by: org.osgi.framework.BundleException: Unable to build resource for mvn:org.dt.dummy/Diff-Blueprint/0.0.1-SNAPSHOT: Unsupported 'Bundle-ManifestVersion' value: 1
at org.apache.karaf.features.internal.resolver.ResourceBuilder.build(ResourceBuilder.java:80)[9:org.apache.karaf.features.core:4.0.3]
at org.apache.karaf.features.internal.resolver.ResourceBuilder.build(ResourceBuilder.java:69)[9:org.apache.karaf.features.core:4.0.3]
at org.apache.karaf.features.internal.region.Subsystem.createResource(Subsystem.java:565)[9:org.apache.karaf.features.core:4.0.3]
... 15 more
Caused by: org.osgi.framework.BundleException: Unsupported 'Bundle-ManifestVersion' value: 1
at org.apache.karaf.features.internal.resolver.ResourceBuilder.doBuild(ResourceBuilder.java:88)[9:org.apache.karaf.features.core:4.0.3]
at org.apache.karaf.features.internal.resolver.ResourceBuilder.build(ResourceBuilder.java:78)[9:org.apache.karaf.features.core:4.0.3]
... 17 more
feature.xml
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<features xmlns="http://karaf.apache.org/xmlns/features/v1.3.0" name="Diff-Blueprint">
<feature name="Diff-Blueprint" description="Diff-Blueprint" version="0.0.1.SNAPSHOT">
<feature prerequisite="true" dependency="false">wrap</feature>
<bundle>mvn:org.dt.dummy/Diff-Blueprint/0.0.1-SNAPSHOT</bundle>
<bundle>wrap:mvn:osgi/osgi/3.0.1</bundle>
<bundle>wrap:mvn:javax.xml/xml/3.1.0</bundle>
<bundle>wrap:mvn:xmlunit/xmlunit/1.6</bundle>
<bundle>wrap:mvn:junit/junit/4.11</bundle>
<bundle>wrap:mvn:org.hamcrest/hamcrest-core/1.3</bundle>
<bundle>mvn:com.googlecode.json-simple/json-simple/1.1.1</bundle>
<bundle>wrap:mvn:de.odysseus.staxon/staxon-jackson/1.2</bundle>
<bundle>mvn:com.fasterxml.jackson.core/jackson-core/2.0.6</bundle>
<bundle>wrap:mvn:de.odysseus.staxon/staxon/1.2</bundle>
<bundle>mvn:log4j/log4j/1.2.17</bundle>
<bundle>mvn:org.codehaus.jackson/jackson-mapper-asl/1.9.13</bundle>
<bundle>mvn:org.codehaus.jackson/jackson-core-asl/1.9.13</bundle>
<bundle>wrap:mvn:org.unitils/unitils/2.4</bundle>
<bundle>wrap:mvn:commons-logging/commons-logging/1.1</bundle>
<bundle>wrap:mvn:commons-dbcp/commons-dbcp/1.2.2</bundle>
<bundle>wrap:mvn:commons-pool/commons-pool/1.3</bundle>
<bundle>wrap:mvn:commons-lang/commons-lang/2.3</bundle>
<bundle>wrap:mvn:commons-collections/commons-collections/3.2</bundle>
<bundle>wrap:mvn:ognl/ognl/2.6.9</bundle>
<bundle>wrap:mvn:ant/ant/1.6.5</bundle>
</feature>
</features>
Appreciate that I am resurrecting an old thread here, but to elaborate on #Charity's answer, for anybody who discovers this at a later date (as I did)...
The problem is that we are trying to deploy a non-OSGi compliant bundle, to the container. The solution is to "wrap" the bundle that is causing you problems, by using the Wrap protocol described in the OPS4J Wiki.
JAR Example
A simple example using Maven is shown below:
wrap:mvn:commons-logging/commons-logging/1.1
Note that we have to prefix the bundle with "wrap:", and that is all. See the wiki for more complex examples which override settings defined in the manifest.
WAR Example
Deploy a non-OSGi compliant WAR file in much the same way, using the "webbundle" URI handler instead:
webbundle:mvn:com.example/example-web-app/1.0/war
I have found a solution if we wrap the jars which throw Bundle-ManifestVersion: 1 then this will work
Evidently the Diff-Blueprint bundle has Bundle-ManifestVersion: 1 as a MANIFEST.MF header. This indicates that it predates OSGi Release 4.0, which was released in 2005, so it's unsurprising that a modern version of Karaf does not support it.
So you will have to look into the tool that produced that bundle.
Try to edit MANIFEST.MF file of problematic bundle, just change Bundle-ManifestVersion with value of 2 instead of 1.
Related
I've built an application bundled in an OSGi JAR package and now I'm trying to create a KAR file to easy deployment to Apache Karaf 4.0.8.
When I drop the KAR file there's a warning message complaining that it's impossible to resolve camel-spring due to the missing org.springframework.beans requirement.
2017-01-18 19:07:12,239 | WARN | raf-4.0.8/deploy | KarServiceImpl | 36 -
org.apache.karaf.kar.core - 4.0.8 | Unable to install Kar feature
interfacturas-kar/1.0.0.SNAPSHOT
org.osgi.service.resolver.ResolutionException: Unable to resolve root:
missing requirement [root] osgi.identity;
osgi.identity=interfacturas-kar;
type=karaf.feature;
version="[1.0.0.SNAPSHOT,1.0.0.SNAPSHOT]";
filter:="(&(osgi.identity=interfacturas-kar)
(type=karaf.feature(version>=1.0.0.SNAPSHOT)
(version<=1.0.0.SNAPSHOT))"
[caused by: Unable to resolve interfacturas-kar/1.0.0.SNAPSHOT:
missing requirement [interfacturas-kar/1.0.0.SNAPSHOT] osgi.identity;
osgi.identity=org.apache.camel.camel-spring;
type=osgi.bundle;
version="[2.17.0.redhat-630187,2.17.0.redhat-630187]";
resolution:=mandatory
[caused by: Unable to resolve org.apache.camel.camel-spring/2.17.0.redhat-630187:
missing requirement [org.apache.camel.camel-spring/2.17.0.redhat-630187]
osgi.wiring.package;
filter:="(&(osgi.wiring.package=org.springframework.beans)
(version>=3.2.0)(!(version>=4.0.0)))"]]
I cannot figure why this is happening! The kar file does contain spring-beans JAR file of an appropriate version:
$ unzip -l interfacturas-kar-1.0.0-SNAPSHOT.kar
...
614354 2017-01-11 19:07 repository/org/springframework/spring-beans/3.2.16.RELEASE/spring-beans-3.2.16.RELEASE.jar
...
The KAR file and its associated feature XML file is completely generated by karaf-maven-plugin, and it also lists the spring-beans dependency:
<bundle>wrap:mvn:org.springframework/spring-beans/3.2.16.RELEASE</bundle>
along with other spring related resources.
Any has some idea how to fix this? Or why is it happening?
BTW, camel-spring actually comes as a dependency of camel-cxf; I'm using blueprint for defining the routes.
We are facing one issue about EhCache and Spring, when we point XSD file in ehcache.xml to http://ehcache.org/ehcache.xsd, everything is ok, our application can startup correct.
But our server can't access external website, so we changed XSD location to local as below, but the application can't startup with following exception (already copy ehcache.xsd to classes folder, same as ehcache.xml).
I have googled many solution, but it still can't be fixed. I need your help about this. Thank you very much.
Spring: 3.1.0
EhCache: 2.4.2
Server: Tomcat 6.0
Java : 1.6
Config:
<ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="ehcache.xsd"
updateCheck="false" monitoring="autodetect" dynamicConfig="true">
Exception:
2012-11-07 16:54:42,003 WARN [org.springframework.beans.factory.xml.XmlBeanDefinitionReader] - <Ignored XML validation warning>
org.xml.sax.SAXParseException: schema_reference.4: Failed to read schema document 'ehcache.xsd', because 1) could not find the document; 2) the document could not be read; 3) the root element of the document is not <xsd:schema>.
at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:195)
at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.warning(ErrorHandlerWrapper.java:96)
at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:380)
at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:318)
at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.findSchemaGrammar(XMLSchemaValidator.java:2440)
... more
2012-11-07 16:54:42,007 ERROR [org.springframework.web.context.ContextLoader] - <Context initialization failed>
org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 3 in XML document from ServletContext resource [/WEB-INF/classes/META-INF/ehcache.xml] is invalid; nested exception is org.xml.sax.SAXParseException: cvc-elt.1: Cannot find the declaration of element 'ehcache'.
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:396)
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:334)
... more
Caused by: org.xml.sax.SAXParseException: cvc-elt.1: Cannot find the declaration of element 'ehcache'.
at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:195)
at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:131)
... more
Download ehcache.xsd, put it to the same folder where is your config xml file.
modify the xml head like below, notice the classpath prefix:
<ehcache
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="classpath:ehcache.xsd">
This will work in the development and production environment.
usually I set xsi:noNamespaceSchemaLocation="http://ehcache.org/ehcache.xsd", But this can't work in a offline environment.
My Workaround is add this xsd file to absolute path, such as: c:/ehcache.xsd and point to this location in ehcache.xml.
Hope this will help someone who facing the same issue.
Still looking forward to find out other solution.
Thanks.
In my case just downloading the file from http://ehcache.org/ehcache.xsd into src/main/resources solves the problem
cd src/main/resources
wget http://ehcache.org/ehcache.xsd
I have the following maven dependency in my pom file:
<!-- depends on slf4j-api, log4j -->
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.6.4</version>
</dependency>
When I deploy the project into tomcat, I am getting the error message:
SEVERE: Exception sending context destroyed event to listener instance of class org.springframework.web.context.ContextLoaderListener
java.lang.ExceptionInInitializerError
at org.springframework.web.context.ContextLoaderListener.contextDestroyed(ContextLoaderListener.java:80)
at org.apache.catalina.core.StandardContext.listenerStop(StandardContext.java:4819)
at org.apache.catalina.core.StandardContext.stopInternal(StandardContext.java:5466)
at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:232)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:160)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:895)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:871)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:615)
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:958)
at org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1599)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.IllegalStateException: org.slf4j.LoggerFactory could not be successfully initialized. See also http://www.slf4j.org/codes.html#unsuccessfulInit
at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:288)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:252)
at org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:155)
at org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:131)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:685)
at org.springframework.web.context.ContextCleanupListener.<clinit>(ContextCleanupListener.java:43)
... 16 more
When I look at the deployed war file, I see in the war file the following jars (among others):
slf4j-api-1.6.4.jar
slf4j-log4j12-1.6.4.jar
The strange thing is, that I don't see there any log4j.jar (even though it's a dependency of slf4j-log4j12-1.6.4.jar
Questions:
Why was log4j.jar not packed in the war file?
What does the error message mean and how to solve it?
I had this issue due to a bad jar file in the repository. Deleting the entire log4j directory in the Maven repository fixed it once I did Maven > Update Dependencies and it re-downloaded them.
The simple thing is, cause you didn't give it as dependency in your pom, cause slf4j is a logging facade which means you have to give the real implementation with it. The error message gives you a hint to the explanation of the cause of this error.
I got this error too and I actually had the log4j.jar in my war file.
But it turned out to be a classloader issue in my case: I had a jar in my shared/lib which tried to log with slf4j but that classloader did not have the log4j available.
It seems as if you need to downgrade your project to slf4j 1.4.2 to work with the log4j available in your tomcat. They are binary incompatible. You would also hang on to the provided afterwards, so you dont include them double.
The alternative is to get the other project to include the libraries themselves and remove from tomcat common. I know of no other exclusion mechanism on the tomcat.
For reference, and probably not helpful, I currently deploy on weblogic and it has a deployment specification that allows one to exclude server common classes and use bundled classes instead, such as the below snippet (with reference)
when running my osgi application
i am getting following error:
!ENTRY com.mypackage.commons 4 0 2011-07-06 15:52:21.841
!MESSAGE
!STACK 0
org.osgi.framework.BundleException: The bundle could not be resolved. Reason: Package uses conflict: Import-Package: org.springframework.mail.javamail; version="0.0.0"
at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolverError(AbstractBundle.java:1313)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureException(AbstractBundle.java:1297)
at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:319)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:370)
at org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1068)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:557)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:464)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:248)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:445)
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:220)
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:330)
please advise.
problem solved by using latest version of org.springframework.context.support dependency.
More information is necessary to diagnose the problem. First I recommend running on Apache Felix rather than Equinox – even if only temporarily – because it has better diagnostics for uses-constraints problems. Also try reading my blog posts: http://njbartlett.name/2011/02/09/uses-constraints.html and http://njbartlett.name/2011/03/31/uses-constraints-in-felix.html
I'm trying to upgrade from JBoss 4.2.1 to JBoss 6. In JBoss 4.2.1, we are manually deploying our application as an exploded war and everything works beautifully.
I'm running into problems because the application that I am trying to deploy uses versions of 3rd party libraries that are older than the ones that JBoss 6 now includes by default. The result of this is that I'm getting classloader conflicts all over the place and the application won't even start.
At present, I have tried using the JBoss Classloading Documentation as well as the scanty bits of documentation for jboss-classloading.xml and haven't had any success.
Has anyone out there managed to do this successfully? If you have, how did you do it?
I've included a stack trace below in case it offers any useful information.
Caused by: java.lang.Error: Error visiting "/C:/jboss6/server/default/deploy/app.war/WEB-INF/lib/jaxb-xjc-2.1.12.jar/1.0/com/sun/codemodel/JConditional.class"
at org.jboss.classloading.plugins.vfs.VFSResourceVisitor.visit(VFSResourceVisitor.java:268) [jboss-classloading-vfs.jar:2.2.0.Alpha9]
at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:407) [jboss-vfs.jar:3.0.0.CR5]
at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:409) [jboss-vfs.jar:3.0.0.CR5]
at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:409) [jboss-vfs.jar:3.0.0.CR5]
at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:409) [jboss-vfs.jar:3.0.0.CR5]
at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:409) [jboss-vfs.jar:3.0.0.CR5]
at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:395) [jboss-vfs.jar:3.0.0.CR5]
at org.jboss.classloading.plugins.vfs.VFSResourceVisitor.visit(VFSResourceVisitor.java:102) [jboss-classloading-vfs.jar:2.2.0.Alpha9]
at org.jboss.deployers.vfs.plugins.classloader.VFSDeploymentClassLoaderPolicyModule.visit(VFSDeploymentClassLoaderPolicyModule.java:181) [:2.2.0.Alpha8]
at org.jboss.scanning.plugins.DeploymentUnitScanner.scan(DeploymentUnitScanner.java:111) [:1.0.0.Alpha7]
at org.jboss.scanning.spi.helpers.UrlScanner.scan(UrlScanner.java:96) [:1.0.0.Alpha7]
at org.jboss.scanning.deployers.ScanningDeployer.deploy(ScanningDeployer.java:90) [:1.0.0.Alpha7]
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:179) [:2.2.0.Alpha8]
... 41 more
Have you tried "java2ParentDelegation=false"? Also you might find the below two useful
jboss classloading usecases
jee-j2ee-classloading-standard
Some links on fixing JAXB and JBOSS issues
http://kishantha.blogspot.com/2010/03/fixing-jaxb-linkageerror-in-jboss-with.html
https://issues.jboss.org/browse/JBWS-1931
http://community.jboss.org/wiki/LinkageErrorWithJBoss5Java6
http://community.jboss.org/message/568820
We use the following in ear-deployer-jboss-beans.xml
<bean name="EARClassLoaderDeployer" class="org.jboss.deployment.EarClassLoaderDeployer">
<property name="isolated">true</property>
</bean>