Perhaps this is a similar issue to the one I've encountered in https://issues.apache.org/jira/browse/KARAF-3973 ? In my case it's not a KAR, but does involve bundles in the deploy folder, and started happening after upgrade to 4.0.x on a fresh karaf installation. In your case, does it recover after Karaf is restarted (without cleaning the data dir, i.e. karaf.clean.all = false)? Do your bundles restart/refresh/diag normally?
On 11/22/2015 04:32 PM, rsteppac wrote: > Some more info... > > The way I have tested the deployment is to set "karaf.clean.all = true" in > the system.properties file of Karaf. Then I repeatedly start and stop Karaf > with the same KAR artifact in the deploy folder. In some configurations the > outcome of the initial deployment during the start of Karaf has an impact on > subsequent re-deployments by removing the KAR artifact from the deploy > folder and then putting it back (see below). > > There are actually two things I have changed in the more recent past: > > - upgrade to Karaf 4.0.x from 3.0.3 > - "fixed" the webservice setup > > The first item entails an upgrade to Java 8 (from 7), Jetty 9 (from 8), > Camel 2.16.0 (from 2.15.2). > The second attempts to fix my project setup of the web-service bundles. > Previously the bundles were built with the directive > <DynamicImport-Package>*</DynamicImport-Package>. They also contained > META-INF SPI entries for the SOAP factory, SOAP message factory, and SAAJ > meta factory, setting all three to the JDK implementation > (com.sun.xml.internal.messaging.saaj.soap.ver1_1.xxx). This I replaced with > a dependency to org.apache.servicemix.bundles.saaj-impl which provides SPI > entries for its own implementation. The dynamic import I replaced with a > concrete list of imported packages: > > javax.xml.soap; > version=1.3, > com.sun.xml.messaging.saaj.soap; > version=1.3.25, > org.apache.xalan.processor; > version=2.7.2, > org.springframework.ws.wsdl.wsdl11; > version=2.1.4.RELEASE, > org.springframework.ws.soap.saaj; > version=2.1.4.RELEASE, > org.springframework.ws.soap.server; > version=2.1.4.RELEASE, > org.springframework.ws.server.endpoint.adapter; > version=2.1.4.RELEASE, > org.springframework.ws.soap.server.endpoint; > version=2.1.4.RELEASE, > > org.springframework.ws.soap.server.endpoint.adapter.method; > version=2.1.4.RELEASE, > org.apache.xpath.jaxp, > ch.vivates.ams.ws.patient.schema, > * > > As far as I can tell this creates bundles that can be deployed successfully > as part of their respective feature on the Karaf command line. However, it > appears to be the main culprit for the issues documented above when deployed > as part of a KAR artifact. More so in Karaf 4.0.3 than in Karaf 3.0.5. > > Using a minimal KAR containing only one web-service feature and the data > access feature and ... > > Karaf 3.0.5 with dynamic import: > No exceptions during deployment at Karaf start. 1 in 3 Karaf boots yield a > SOAP fault "Can't transform a Source of type > javax.xml.transform.stax.StAXSource" as a client response. If the deployment > is successful during Karaf start, then it seems I can deploy/un-deploy the > KAR file as often as I want with the same result (fail or success). > > Karaf 3.0.5 with SAAJ impl import: > No exceptions during deployment at Karaf start, but low chance of success. > Only about 1 in 10 Karaf starts do NOT yield "Can't transform a Source of > type javax.xml.transform.stax.StAXSource". If the deployment is successful > during Karaf start, then it seems I can deploy/un-deploy the KAR file as > often as I want with the same result (fail or success). > > Karaf 4.0.3 with dynamic import: > No exceptions during deployment at Karaf start and very high chance of > success. About 1 in 10 deployments yield "Can't transform a Source of type > javax.xml.transform.stax.StAXSource" as a client response. > If the deployment is successful during Karaf start, then it seems I can > deploy/un-deploy the KAR file as often as I want with the same result (fail > or success). The re-deployment yields the InstanceAlreadyExistsException > documented above. > > Karaf 4.0.3 with SAAJ impl import: > Very low chance of successful deployment at Karaf boot time. Re-deploying > the KAR after a successful deployment at Karaf start fails just as likely as > during Karaf start. > > > Bottom line is, it appears I have the choice between different levels of > randomness, but no reliable deployment. As this is very fundamental > functionality that appears to not work properly, I am wondering if I am > doing something fundamentally wrong here? > > > > -- > View this message in context: > http://karaf.922171.n3.nabble.com/KAR-deployment-in-Karaf-4-0-3-fails-with-varying-errors-tp4043649p4043652.html > Sent from the Karaf - User mailing list archive at Nabble.com. >
