I am trying to migrate a aplication running on wildfly 8.2 to jboss 7.2, using slf4j as logging framework. However when I try to deploy in JBoss, I get the following error:
Caused by: java.lang.LinkageError: Failed to link
org/jboss/logging/Logger$Level (Module
\"deployment.backend-2.1.2.war\" from Service Module Loader): loader
constraint violation: loader (instance of
org/jboss/modules/ModuleClassLoader) previously initiated loading for
a different type with name \"org/jboss/logging/Logger$Level\""}}}
Current jboss-deployment-structure:
<exclusions>
<module name="org.apache.log4j" />
<module name="org.slf4j" />
<module name='org.slf4j.impl' />
<module name="org.apache.commons.logging" />
<module name="org.log4j" />
<module name="org.jboss.logging" />
</exclusions>
I couldn't find any solution to solve this error, running mvn dependency:tree, org.jboss.logging was imported from Hibernate 4.3.11.Final, then my pom with hibernate now looks :
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-entitymanager</artifactId>
<version>${hibernate.version}</version>
<exclusions>
<exclusion>
<groupId>org.jboss.logging</groupId>
<artifactId>jboss-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
But the same error persists.
This issue is related to the fact that in your configuration file: standalone.xml, you had created or imported the same logger twice, the level also should not repeat.
Caused by: java.lang.LinkageError: Failed to link org/jboss/logging/Logger$Level (Module \"deployment.backend-2.1.2.war\" from Service Module Loader): loader constraint violation: loader (instance of org/jboss/modules/ModuleClassLoader) previously initiated loading for a different type with name \"org/jboss/logging/Logger$Level\""}}}
Furthermore, be careful with the flag use-parent-handlers on the logger configuration, which will dictate if the logger info should be used by the parent handler. More information here
Related
I have come across a rather curious issue with wildfly classloading. I have a java-ee webapp, structured as follows:
some.ear
+- some.war
+- EJBs.jar
both the war and the jar require some spring classes to function properly. I defined a spring module containing the relevant classes. Within jboss-deployment-structure I have a section as follows:
<jboss-deployment-structure>
<deployment>
<dependencies>
...
<module name="org.springframework.spring-web"/>
...
</dependencies>
</deployment>
After launching my webapp, I get a ClassNotFoundException when deploying the war-archive.
If I add an additional section
<sub-deployment name="some.war">
<dependencies>
...
<module name="org.springframework.spring-web"/>
...
</dependencies>
</sub-deployment>
it works.
My understanding is, that every module from the main-deployment section should also be visible in all sub-deployments.
Can anyone shed some light on this issue?
Each sub-deployment would need it's own set of module dependencies. If you were to include the module libraries in the EAR/lib directory instead of creating a module then you'd not need to add the module dependency for each sub-deployment.
I am using Bouncycastle (bcmail, bcprov, bcpkix) 1.57 in combination with Jboss EAP 6.4 (jboss-AS 7.5) and Java 1.8.
I get a Linkage error with the following stacktrace:
Caused by: java.lang.LinkageError:
loader constraint violation: when resolving method "org.bouncycastle.mail.smime.SMIMESignedGenerator.generate(Ljavax/mail/internet/MimeBodyPart;)Ljavax/mail/internet/MimeMultipart;"
the class loader (instance of org/jboss/modules/ModuleClassLoader) of the current class, de/deutschepost/paket/mkp/transformation/SMIMEPreparator,
and the class loader (instance of org/jboss/modules/ModuleClassLoader) for the method's defining class, org/bouncycastle/mail/smime/SMIMESignedGenerator,
have different Class objects for the type javax/mail/internet/MimeBodyPart used in the signature
As far as my understanding goes there must be a duplicate or a conflict in library versions somewhere in the hierarchy, but unfortunately I can't find any.
Here is the list of all the dependencies that are present in the classpath at runtime:
activation-1.1.jar
activemq-broker-5.11.0.jar
activemq-client-5.11.0.jar
activemq-jms-pool-5.11.0.jar
activemq-openwire-legacy-5.11.0.jar
activemq-pool-5.11.0.jar
antlr-2.7.7.jar
aqapi-11.2.0.3-1.jar
asm-5.0.4.jar
aspectjrt-1.6.1.jar
aspectjweaver-1.8.9.jar
c3p0-0.9.5.2.jar
camel-core-2.18.4.jar
camel-cxf-2.18.4.jar
camel-cxf-transport-2.18.4.jar
camel-ftp-2.18.4.jar
camel-http-2.18.4.jar
camel-http-common-2.18.4.jar
camel-jaxb-2.18.4.jar
camel-jetty-2.18.4.jar
camel-jetty9-2.18.4.jar
camel-jetty-common-2.18.4.jar
camel-jms-2.18.4.jar
camel-mail-2.18.4.jar
camel-mail-patch-2.10-senacor-3-SNAPSHOT.jar
camel-ognl-2.18.4.jar
camel-quartz2-2.18.4.jar
camel-spring-2.18.4.jar
cglib-nodep-2.1_3.jar
classmate-1.3.0.jar
commons-codec-1.4.jar
commons-collections-3.2.1.jar
commons-httpclient-3.1.jar
commons-io-1.4.jar
commons-lang-2.4.jar
commons-lang3-3.3.2.jar
commons-logging-1.0.4.jar
commons-net-3.3.jar
commons-pool-1.5.6.jar
core-7.0.0-SNAPSHOT.jar
cryptacular-1.0.jar
cxf-core-3.1.12.jar
cxf-rt-bindings-soap-3.1.12.jar
cxf-rt-bindings-xml-3.1.12.jar
cxf-rt-databinding-jaxb-3.1.12.jar
cxf-rt-frontend-jaxrs-3.1.12.jar
cxf-rt-frontend-jaxws-3.1.12.jar
cxf-rt-frontend-simple-3.1.12.jar
cxf-rt-rs-client-3.1.11.jar
cxf-rt-rs-security-oauth-3.1.11.jar
cxf-rt-security-3.1.12.jar
cxf-rt-security-saml-3.1.12.jar
cxf-rt-transports-http-3.1.12.jar
cxf-rt-ws-addr-3.1.12.jar
cxf-rt-wsdl-3.1.12.jar
cxf-rt-ws-policy-3.1.12.jar
cxf-rt-ws-security-3.1.12.jar
dms-11.2.0.3-1.jar
dom4j-1.6.1.jar
dsn-1.5.5.jar
ehcache-2.10.3.jar
ehcache-core-2.5.7.jar
geronimo-j2ee-management_1.1_spec-1.0.1.jar
geronimo-jms_1.1_spec-1.1.1.jar
geronimo-jta_1.0.1B_spec-1.0.1.jar
gson-2.7.jar
guava-18.0.jar
h2-1.3.173.jar
hamcrest-all-1.3.jar
hamcrest-core-1.3.jar
hawtbuf-1.11.jar
hibernate-c3p0-5.2.10.Final.jar
hibernate-commons-annotations-5.0.1.Final.jar
hibernate-core-5.2.10.Final.jar
hibernate-ehcache-5.2.10.Final.jar
hibernate-envers-5.2.10.Final.jar
hibernate-jpa-2.1-api-1.0.0.Final.jar
hibernate-validator-4.2.0.Final.jar
httpclient-4.5.3.jar
httpcore-4.4.6.jar
httpmime-4.5.3.jar
itext-2.1.7.jar
jandex-2.0.3.Final.jar
jasypt-1.9.2.jar
javassist-3.20.0-GA.jar
java-support-7.1.1.jar
javax.annotation-api-1.2.jar
javax.inject-1.jar
javax.mail-1.5.5.jar
javax.mail-api-1.5.5.jar
javax.servlet-api-3.1.0.jar
javax.ws.rs-api-2.0.1.jar
jaxb2-basics-runtime-0.6.3.jar
jaxb-api-2.2.11.jar
jaxb-core-2.2.11.jar
jaxb-impl-2.2.11.jar
jboss-logging-3.3.0.Final.jar
jboss-transaction-api_1.2_spec-1.0.1.Final.jar
jettison-1.3.7.jar
jetty-client-9.2.21.v20170120.jar
jetty-continuation-9.2.21.v20170120.jar
jetty-http-9.2.21.v20170120.jar
jetty-io-9.2.21.v20170120.jar
jetty-jmx-9.2.21.v20170120.jar
jetty-security-9.2.21.v20170120.jar
jetty-server-9.2.21.v20170120.jar
jetty-servlet-9.2.21.v20170120.jar
jetty-servlets-9.2.21.v20170120.jar
jetty-util-9.2.21.v20170120.jar
jms-1.1.jar
joda-time-2.3.jar
jsch-0.1.54.jar
jsmpp-2.1.0.jar
json-simple-1.1.1.jar
jsr250-api-1.0.jar
jta-1.1.jar
jutf7-1.0.0.jar
mchange-commons-java-0.2.11.jar
neethi-3.0.3.jar
netty-all-4.0.26.Final.jar
oauth-20100527.jar
oauth-provider-20100527.jar
ognl-3.1.10.jar
ojdbc6-11.2.0.4.0.jar
opensaml-core-3.1.1.jar
opensaml-profile-api-3.1.1.jar
opensaml-saml-api-3.1.1.jar
opensaml-saml-impl-3.1.1.jar
opensaml-security-api-3.1.1.jar
opensaml-security-impl-3.1.1.jar
opensaml-soap-api-3.1.1.jar
opensaml-xacml-api-3.1.1.jar
opensaml-xacml-impl-3.1.1.jar
opensaml-xacml-saml-api-3.1.1.jar
opensaml-xacml-saml-impl-3.1.1.jar
opensaml-xmlsec-api-3.1.1.jar
opensaml-xmlsec-impl-3.1.1.jar
optivo-3.0.0-SNAPSHOT.jar
oro-2.0.8.jar
pushy-0.4.3.jar
quartz-2.2.3.jar
slf4j-api-1.7.5.jar
spring-aop-4.3.8.RELEASE.jar
spring-aspects-4.3.8.RELEASE.jar
spring-beans-4.3.8.RELEASE.jar
spring-context-4.3.8.RELEASE.jar
spring-context-support-4.3.8.RELEASE.jar
spring-core-4.3.8.RELEASE.jar
spring-data-jdbc-core-1.0.0.RELEASE.jar
spring-data-oracle-1.0.0.RELEASE.jar
spring-expression-4.3.8.RELEASE.jar
spring-jdbc-4.3.8.RELEASE.jar
spring-jms-4.3.8.RELEASE.jar
spring-messaging-4.3.8.RELEASE.jar
spring-orm-4.3.8.RELEASE.jar
spring-retry-1.0.0.RELEASE.jar
spring-tx-4.3.8.RELEASE.jar
spring-web-4.3.8.RELEASE.jar
stax2-api-3.1.4.jar
stax-api-1.0.1.jar
ucp-11.2.0.4.0.jar
validation-api-1.0.0.GA.jar
velocity-1.6.2.jar
woodstox-core-asl-4.4.1.jar
wsdl4j-1.6.3.jar
wss4j-bindings-2.1.10.jar
wss4j-policy-2.1.10.jar
wss4j-ws-security-common-2.1.10.jar
wss4j-ws-security-dom-2.1.10.jar
wss4j-ws-security-policy-stax-2.1.10.jar
wss4j-ws-security-stax-2.1.10.jar
xbean-spring-3.5.jar
xml-apis-1.3.04.jar
xmlpull-1.1.3.1.jar
xml-resolver-1.2.jar
xmlschema-core-2.2.2.jar
xmlsec-2.0.8.jar
xpp3_min-1.1.4c.jar
xstream-1.4.5.jar
xstream-hibernate-1.4.5.jar
Apart from these I have an explicit dependency to Bouncycastle module (I added the module myself in jboss modules). The configuration file module.xml is as follows:
<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.1" name="org.bouncycastle">
<resources>
<resource-root path="bcmail-jdk15on-1.57.jar"/>
<resource-root path="bcprov-jdk15on-1.57.jar"/>
<resource-root path="bcpkix-jdk15on-1.57.jar"/>
</resources>
<dependencies>
<module name="javax.api"/>
<module name="org.jboss.logging"/>
<module name="org.jboss.modules"/>
<module name="javax.activation.api" />
<module name="javax.mail.api"/>
</dependencies>
</module>
I would be glad if anyone can help me out here.
Thanks.
This issue is due to presence of multiple javax-mail versionsin the project classpath.Removing all the different versions for this dependency and keeping just one would resolve the issue.By default you could try using javax.mail.api-1.4.5 which is shipped with EAP 6.4
I am trying to deploy an application in Wildfly 10 but I get the following error:
/usr/lib/jvm/jdk1.8.0_121/bin/java -classpath /opt/jetbrains/idea-IU-163.13906.18/lib/idea_rt.jar:/opt/jetbrains/idea-IU-163.13906.18/lib/util.jar -Dfile.encoding=UTF-8 com.intellij.rt.execution.CommandLineWrapper /tmp/classpath com.intellij.javaee.oss.process.JavaeeProcess 42364 com.intellij.javaee.oss.jboss.agent.JBoss71Agent
[2017-10-05 12:50:04,818] Artifact Gradle : com.solveralynx.wildrunner.api : skin.war: Server is not connected. Deploy is not available.
[2017-10-05 12:50:04,818] Artifact Gradle : com.solveralynx.wildrunner.api : drcs-development.war: Server is not connected. Deploy is not available.
Oct 05, 2017 12:50:04 PM org.xnio.Xnio <clinit>
INFO: XNIO version 3.4.0.Final
Oct 05, 2017 12:50:04 PM org.xnio.nio.NioXnio <clinit>
INFO: XNIO NIO Implementation Version 3.4.0.Final
Oct 05, 2017 12:50:04 PM org.jboss.remoting3.EndpointImpl <clinit>
INFO: JBoss Remoting version 4.0.21.Final
[2017-10-05 12:50:05,133] Artifact Gradle : com.solveralynx.wildrunner.api : skin.war: Artifact is being deployed, please wait...
[2017-10-05 12:50:05,133] Artifact Gradle : com.solveralynx.wildrunner.api : drcs-development.war: Artifact is being deployed, please wait...
Connected to server
Connected to the target VM, address: 'localhost:44287', transport: 'socket'
[2017-10-05 12:50:08,064] Artifact Gradle : com.solveralynx.wildrunner.api : skin.war: Artifact is deployed successfully
[2017-10-05 12:50:08,064] Artifact Gradle : com.solveralynx.wildrunner.api : skin.war: Deploy took 2,931 milliseconds
[2017-10-05 12:50:15,349] Artifact Gradle : com.solveralynx.wildrunner.api : drcs-development.war: Error during artifact deployment. See server log for details.
[2017-10-05 12:50:15,350] Artifact Gradle : com.solveralynx.wildrunner.api : drcs-development.war: java.lang.Exception: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"drcs-development.war\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"drcs-development.war\".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment \"drcs-development.war\"
Caused by: java.lang.NoClassDefFoundError: Failed to link com/solveralynx/wildrunner_api/drcs/business_impl/ejb/jobs/GBMeteringDataJobEJB (Module \"deployment.drcs-development.war:main\" from Service Module Loader): com/solveralynx/wildrunner_api/drcs/business_api/ejb/jobs/MeteringDataJobLocal"},"WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"drcs-development.war\".POST_MODULE"],"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined}
My wildfly deployment structure looks like this:
<jboss-deployment-structure>
<!-- Make sub deployments isolated by default, so they cannot see each others classes without a Class-Path entry -->
<ear-subdeployments-isolated>false</ear-subdeployments-isolated>
<!-- This corresponds to the top level deployment. For a war this is the war's module, for an ear -->
<!-- This is the top level ear module, which contains all the classes in the EAR's lib folder -->
<deployment>
<!-- Exclusions allow you to prevent the server from automatically adding some dependencies -->
<exclusions>
<!--<module name="com.google.guava" slot="main"/>-->
</exclusions>
<!-- This allows you to define additional dependencies, it is the same as using the Dependencies: manifest attribute -->
<dependencies>
<module name="javax.faces.api" slot="main" export="true"/>
<module name="com.sun.jsf-impl" slot="main" export="true"/>
<module name="com.google.gwt.user" slot="main" export="true"/>
<module name="com.google.gwt.servlet" slot="main" export="true"/>
<module name="org.dom4j" slot="main" export="true"/>
<module name="org.apache.xalan" slot="main"/>
</dependencies>
<!-- These add additional classes to the module. In this case it is the same as including the jar in the EAR's lib directory -->
<resources>
</resources>
</deployment>
<sub-deployment name="web.war">
<exclusions>
<module name="javax.faces.api" slot="1.2"/>
<module name="com.sun.jsf-impl" slot="1.2"/>
</exclusions>
<dependencies>
<module name="javax.faces.api" slot="main"/>
<module name="com.sun.jsf-impl" slot="main"/>
<module name="com.google.gwt.user" slot="main"/>
<module name="com.google.gwt.servlet" slot="main"/>
<module name="org.dom4j" slot="main"/>
<module name="org.jboss.xnio" slot="main"/>
</dependencies>
</sub-deployment>
<sub-deployment name="business-impl.jar">
<dependencies>
<module name="org.jboss.xnio" slot="main"/>
<module name="com.microsoft.sqlserver" slot="main"/>
</dependencies>
</sub-deployment>
</jboss-deployment-structure>
I don't know what causes this error to happen. I'm thinking that I have to change POST_MODULE phase into something different.
Thank you in advance.
How can I log to console / server.log from within a jboss module?
Say that I have a class:
public class MyClass {
private static final Logger logger = LoggerFactory.getLogger(MyClass.class);
private boolean done = false;
public void doSomething() {
logger.info("Look ma, I'm logging!");
done = true;
}
public boolean isDone() {
return done;
}
}
If I want to log from a deployed artifact (e.g., MyWebProject.war), all I have to do is:
Compile against slf4j-api
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.7</version>
<scope>provided</scope>
</dependency>
Deploy
./jboss-cli.sh -c "deploy MyWebProject.war"
Profit
2015-10-19 11:04:02,445 INFO [com.myCompany.MyClass] (default task-13) Look ma, I'm logging!
But for the life of mine, I can't manage to do the same from within a jboss module.
Example: If MyWebProject.war uses MyModule.jar, and MyModule.jar is deployed as a jboss module:
${jbossHome}/modules/com/mycompany/mymodule/main
|____ MyModule.jar
|____ module.xml
Module.xml
<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.1" name="com.mycompany.mymodule">
<resources>
<resource-root path="MyModule.jar" />
</resources>
<dependencies>
<module name="org.slf4j" />
</dependencies>
</module>
If I move MyClass into MyModule.jar and use it from MyWebProject.war I can see the side effects (e.g., isDone() == true) but nothing is written to server.log.
What am I missing? Do I need any other module dependencies but slf4j?
For further reference, my problem had nothing to do with logging. The above recipe works as expected. In fact I've suffered because of a red herring: my original module.xml was never really used. I was actually loading a old class with the same name in another module. This old version of the class had no logging and should not be there to begin with.
Anyway, I think that the root cause of my problem (besides my lack of attention) was a small bug in jboss-cli.
I was deploying mymodule with the following command:
module add --name=com.mycompany.mymodule \
--resources=MyModule.jar \
--dependencies=org.slf4j \
--main-class=com.mycompany.mymodule.Main
This command was generating a module.xml like this:
<?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.1" name="com.mycompany.mymodule">
<main-class value="com.mycompany.mymodule.Main"/>
<resources>
<resource-root path="MyModule.jar"/>
</resources>
<dependencies>
<module name="org.slf4j"/>
</dependencies>
</module>
When I've finally managed to get my web project to try to load mymodule it failed with a stack trace such as:
18:45:59,999 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.module.service."deployment.MyWebProject.war".main: org.jboss.msc.service.StartException in service jboss.module.service."deployment.MyWebProject.war".main: WFLYSRV0179: Failed to load module: deployment.MyWebProject.war.war:main
at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:91)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.jboss.modules.ModuleLoadException: Error loading module from C:\opt\server\wildfly-9.0.1.Final\modules\com\mycompany\mymodule\main\module.xml
at org.jboss.modules.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:150)
at org.jboss.modules.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:127)
at org.jboss.modules.LocalModuleFinder$1.run(LocalModuleFinder.java:150)
at org.jboss.modules.LocalModuleFinder$1.run(LocalModuleFinder.java:144)
at java.security.AccessController.doPrivileged(Native Method)
at org.jboss.modules.LocalModuleFinder.findModule(LocalModuleFinder.java:144)
at org.jboss.modules.ModuleLoader.findModule(ModuleLoader.java:452)
at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:355)
at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:302)
at org.jboss.modules.ModuleLoader.preloadExportedModule(ModuleLoader.java:313)
at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:326)
at org.jboss.as.server.moduleservice.ServiceModuleLoader.preloadModule(ServiceModuleLoader.java:149)
at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:234)
at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:74)
... 5 more
Caused by: org.jboss.modules.xml.XmlPullParserException: Unexpected content of type 'element start' named 'main-class', text is: '<main-class value="com.mycompany.mymodule.Main"/>' (position: START_TAG seen ...n-class value="com.mycompany.mymodule.Main"/>... #5:54)
at org.jboss.modules.ModuleXmlParser.unexpectedContent(ModuleXmlParser.java:179)
at org.jboss.modules.ModuleXmlParser.parseMainClass(ModuleXmlParser.java:620)
at org.jboss.modules.ModuleXmlParser.parseModuleContents(ModuleXmlParser.java:445)
at org.jboss.modules.ModuleXmlParser.parseDocument(ModuleXmlParser.java:261)
at org.jboss.modules.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:148)
... 18 more
Taking a look at module-1_1.xsd I've found out that the main-class element was expecting a name attribute instead of a value attribute. So I've manually changed the module.xml to:
<main-class name="com.mycompany.mymodule.Main"/>
After I've restarted WildFly and redeployed my web project everything worked as expected.
I have a simple piece of code instantiating a JBoss Hot Rod client and this is deployed in an .ear file on Jboss 7
System.out.println("Attempting to RemoteCacheManager at: "+ipAddress);
Configuration conf = new
ConfigurationBuilder().addServer().host(ipAddress).port(11222).build();
RemoteCacheManager manager = new RemoteCacheManager(conf);
RemoteCache defaultCache = manager.getCache();
System.out.println("SUCCESS OUT: Connected to RemoteCacheManager at: "+ipAddress);
logger.info("SUCCESS: Connected to RemoteCacheManager at {}",ipAddress);
However when I deploy the app it cannot find the the class/method RemoteCacheManager
Caused by: java.lang.NoSuchMethodError: org.infinispan.client.hotrod.RemoteCacheManager.<init>(Lorg/infinispan/client/hotrod/configuration/Configuration;)V
My App has a structure like this
--ear
---lib
---infinispan-client-hotrod-6.0.2-FINAL.jar
--- other .jars
---META-INF
---MANIFEST.MF
---myservice.jar
---mysrvice.war
This is caused because I include the latest hot rod client as a maven dependency but an older version is available as a module. How can I tell Jboss to exclude the older implementation in its module
Thanks
the issue in this case was not as I thought. The issue was JBoss already included an older version of hot rod as a module and hence the "java.lang.NoSuchMethodError"
The solution, to exclude a module and provide a new implementation via new maven dependency is to use the jboss-deployment-structure.xml. Place this file in ear>src>main>META-INF>application
I am being extra careful below by excluding from main deployment and subdeployment and left it here for illustration purposes. I will remove one entry later...
<?xml version="1.0"?>
<exclusions>
<module name="org.infinispan.client.hotrod"/>
</exclusions>
<sub-deployment name="myservice-ejb-1.0.1-SNAPSHOT.jar">
<!-- This corresponds to the module for a web deployment -->
<!-- it can use all the same tags as the <deployment> entry above -->
<exclusions>
<module name="org.infinispan.client.hotrod"/>
</exclusions>
</sub-deployment>
</deployment>