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.
