Mule ESB - La LIB remplace-t-elle une bibliothèque d'applications

Question

J'ai utilisé Mule Studio 3.2.1 pour développer une application mulette. Dans cette application, j'ai utilisé org.springframework.ws.client.core.webserviceTemplate pour envoyer une demande Webservice à une autre application. J'ai utilisé la configuration suivante

 <bean id="myWsTemplate"  clsass="org.springframework.ws.client.core.WebServiceTemplate">
    <constructor-arg ref="messageFactory" />
    <property name="defaultUri" value="${my.soap.endpoint}" />
    <property name="interceptors">
        <list>
            <ref bean="acqSecurityInterceptor" />
        </list>
    </property> 

 <bean id="acqSecurityInterceptor" class="org.springframework.ws.soap.security.wss4j.Wss4jSecurityInterceptor">
    <property name="validationActions" value="NoSecurity"/>
    <property name="securementActions" value="NoSecurity" />
</bean>

J'ai utilisé la dépendance maven de

    <dependency>
        <groupId>org.springframework.ws</groupId>
        <artifactId>spring-ws-security</artifactId>
        <version>2.1.0.RELEASE</version>
    </dependency>

Ceci utilise WSS4J-1.6.5.jar comme une dépendance. Maintenant, lorsque je déploie l'application dans Mule 3.2.0, il lance l'erreur suivante

  PropertyAccessException 1: org.springframework.beans.MethodInvocationException: Property 'validationActions' threw exception; nested exception is java.lang.NoSuchMethodError: org.apache.ws.security.util.WSSecurityUtil.decodeAction(Ljava/lang/String;Ljava/util/List;)I
  PropertyAccessException 2: org.springframework.beans.MethodInvocationException: Property 'securementActions' threw exception; nested exception is java.lang.NoSuchMethodError: org.apache.ws.security.util.WSSecurityUtil.decodeAction(Ljava/lang/String;Ljava/util/List;)I

Maintenant, le répertoire lib / opt de Mule 3.2.0 est livré avec WSS4J-1.5.8-OSGI.JAR pour laquelle la signature de la méthode sur WSSECURUINTUTIL est publique Static Int Decodaction (action de cordes, actions vectorielles) tandis que celui qui a été tenté est Décodaction (Ljava / Lang / String; Ljava / Util / Liste;) qui est présent dans WSS4J.1.6.5

Ma question est même si mon application a le WSS4J-1.6.5.jar, pourquoi le chargeur de classe tente toujours d'utiliser celui de Mule / Lib / Opt. Si celui-ci dans l'application ne remplace pas de priorité de priorité? Si ce n'est pas un moyen de faire fonctionner de cette façon

Answer 1

OK à l'aide de la configuration suivante dans mule-deploy.properties a aidé loader.override= -org.apache.ws.security.util.wssecurityUtil refaire http://www.mulesoft.org/documentation/display/mule3utilisateur/ Classloader + Control + in + Mule

mais toujours des problèmes de jars à venir dans le studio mulet en tant que plugins, puis essayant de déployer dans un mulet autonome.Créera une liste assortie de tels problèmes dans un autre fil.