[jira] Created: (SM-1007) Classloading: jboss-deployer: Linkage Error
Classloading: jboss-deployer: Linkage Error --- Key: SM-1007 URL: https://issues.apache.org/activemq/browse/SM-1007 Project: ServiceMix Issue Type: Bug Affects Versions: 3.1 Environment: JBoss 4.0.2 Reporter: Rabi Attachments: patch.txt I encountered some linkage error while deploying some assemblys in Jboss. Upon investigating i found out that xml-apis is not included in the deployer sar and is referenced from the bootloader. There are multiple libraries in jboss environment that contain this class including the Java 5 rt.jar Upon adding the following jars to the .sar and making them part of org.servicemix:loader-repository=JBIContainer loader repo , I could resolve the issue 1. xml-apis 2.xalan 3. xercesImpl I am not sure if this is the right way. I understand they are initially planned to be shared. Anyway I am attaching the patch to the chages to by pom.xml (removed exclusions for the above jars) java.lang.LinkageError: loader constraint violation: loader (instance of bootloader) previously initiated loading for a different type with name javax/xml/namespace/QName at javax.xml.xpath.XPathConstants.clinit(XPathConstants.java:53) at org.apache.servicemix.expression.JAXPStringXPathExpression.evaluateXPath(JAXPStringXPathExpression.java:39) at org.apache.servicemix.expression.JAXPXPathExpression.evaluate(JAXPXPathExpression.java:98) at org.apache.servicemix.ftp.FtpReceiverEndpoint.configureFromMessage(FtpReceiverEndpoint.java:265) at org.apache.servicemix.ftp.FtpReceiverEndpoint.processInOnly(FtpReceiverEndpoint.java:298) at org.apache.servicemix.common.endpoints.ProviderEndpoint.process(ProviderEndpoint.java:100) at org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(AsyncBaseLifeCycle.java:489) at org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(AsyncBaseLifeCycle.java:441) at org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(BaseLifeCycle.java:46) at org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:593) at org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:174) at org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.java:176) at org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.java:134) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
JMS reliability : AUTO_ACKNOWLEDGE vs. CLIENT_ACKNOWLEDGE
Hi folks, in my ongoing effort to not lose messages I've made another change to servicemix-jms : It seems to me that three of the four processors (standard/multiplexing consumer/provider combinations) can be trivially switched to CLIENT_ACKNOWLEDGE without any performance hit at all (they can all do the receive() and acknowledge() in one synchronous flow), so I've done so. I'm not using the MultiplexingConsumerProcessor, and it is the one complex case. This Issue : https://issues.apache.org/activemq/browse/SM-555 requests that it be added as an option, but perhaps it makes sense in these cases to just switch over to CLIENT_ACKNOWLEDGE? Let me know what you think. -Sam -- View this message in context: http://www.nabble.com/JMS-reliability-%3A-AUTO_ACKNOWLEDGE-vs.-CLIENT_ACKNOWLEDGE-tf4105152s12049.html#a11674691 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
