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>
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.
My problem is that i have an ejb which internally uses freemarker tool to generate a HTML page, built and deployed to JBoss EAP 6.4.10. When i try to access this functionality (which generates HTML code using freemarker tool), jboss throwing below errors:
java.lang.LinkageError: Failed to link freemarker/core/TemplateElement
Caused by: java.lang.NoClassDefFoundError: javax/swing/tree/TreeNode
I added freemarker jar in my jboss modules and it's module.xml looks like this:
<module xmlns="urn:jboss:module:1.1" name="org.freemarker">
<resources>
<resource-root path="freemarker-2.3.25.jar"/>
</resources>
<dependencies>
</dependencies>
</module>
Finally it is found out that the error is due to missing dependency 'javax.api' in freemaker's module.xml file, after adding this dependency in module.xml as below the problem has resolved.
<module xmlns="urn:jboss:module:1.1" name="org.freemarker">
<resources>
<resource-root path="freemarker-2.3.25.jar"/>
</resources>
<dependencies>
<module name="javax.api"/>
</dependencies>
The Google App Engine has this same problem, that some classes that are mandatory in Java SE aren't present there. So try to use org.freemarker:freemarker-gae instead of plain org.freemarker:freemarker.
What kind of platform is that anyway, why's that class missing? Is it Google App Engine?
Update: Certainly JBoss EAP's class loader doesn't export the javax.swing package from some reason (see comments). While using freemarker-gae works that around, then you have to be careful to exclude the non-gae FreeMarker-s coming from elsewhere as transitive Maven (or Gradle, etc.) dependencies. So it would be more maintainable to fix the JBoss modules configuration instead. I saw some start JBoss EAP with -Djboss.modules.system.pkgs=javax.swing, though if Swing is available for other modules in the same JVM, then there must be a more elegant solution, such as adding something to deployment-structure.xml, or if you define your own JBoss modules then to its module.xml. Maybe you should check which standard module exports the swing packages ("javax.api"?), and try to declare that module as a dependency.
I'm deploying an EAR application built with Maven which has the following dependency in one of the modules:
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-entitymanager</artifactId>
<version>5.1.0.Final</version>
</dependency>
When I try to deploy the application in a Glassfish Server 4.1 I get the following error:
Fatal: java.lang.NoSuchMethodError: org.jboss.logging.Logger.debugf(Ljava/lang/String;I)V
at org.hibernate.internal.NamedQueryRepository.checkNamedQueries(NamedQueryRepository.java:149)
I made some research to solve this problem and made the following attempts:
First Attempt
I found this question and used the script in this article to clean the Glassfish's osgi-cache, as suggested in the question and in this issue of the Glassfish/Payara Github repository. Restarted the server. Same error.
Second Attempt
I found this question and tried the suggestion of the first answer, like this: looking at the dependency tree, I see that hibernate-entitymanager has the following dependency:
<dependency>
<groupId>org.jboss.logging</groupId>
<artifactId>jboss-logging</artifactId>
<version>3.3.0.Final</version>
<scope>compile</scope>
</dependency>
So I searched at my Server installation and found the jboss-logging.jar. The installed version was 3.1.0-GA (I'm not sure right now, but surely it was a previous version of the dependency). I downloaded jboss-logging-3.3.0.Final.jar from the Maven Central Repository and replaced the one in my Server installation. Restarted the server. Same error.
Third Attempt
Some comments in the previous post (and others) suggested to add a property org.jboss.logging.provider=slf4j as I'm using these dependencies for logging:
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.21</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.7.21</version>
<scope>test</scope>
</dependency>
I found some .properties files in the /glassfish/domains/domain1/config/ folder but none of them contains such a property and I don't know in which file to add that property. I also made some search in the Admin Console but I didn't found where to add properties. The only logging configuration I found was to configure logging levels.
After that I found where to put some JVM options for the Glassfish Server in the Admin Console and added -Dorg.jboss.logging.provider=slf4j as an option but did not work for me (even more, I had to reboot my computer to get Glassfish in ground zero)
Fourth Attempt
Before all this I had a problem and made another question in StackOverflow. Guided by this comment in that post I changed the project configuration but nothing happened (I solved that problem with a little change in my dependencies, answer still pending)
After all the attempts, I'm running out of ideas and the problem remains. I don't know what could be the problem. Any guide, help or answer will be really appreciated. If anybody needs more details about the situation just let me know.
Thanks in advance for your collaboration.
EDIT 1
I was searching and found this article which says something similar to what I did and adds a provided dependency for jboss-logging like this:
<dependency>
<groupId>org.jboss.logging</groupId>
<artifactId>jboss-logging</artifactId>
<version>3.3.0.Final</version>
<scope>provided</scope>
</dependency>
But the error remains. Apparently it's something with the Server but I can't figure out what. I'm using GlassFish Server Open Source Edition 4.1 (build 13)
I was using JBoss server 7.1 to deploy my project. In my case this error was due to the fact that the I was using jboss-logging-3.3.0.Final.jar in my project but the JBoss 7 had a jboss-logging-3.1.0.GA.jar (/opt/jboss-as-7.1.1.Final/modules/org/jboss/logging/main/) by default. So, may be this was due to the jar conflict or method was not present in the jboss-logging-3.1.0.GA.jar, I am not sure. But replacing the jboss-logging-3.1.0.GA.jar with jboss-logging-3.3.0.Final.jar and change mapping in module.xml (at the same above mentioned location) as follows
<module xmlns="urn:jboss:module:1.1" name="org.jboss.logging">
<resources>
<resource-root path="jboss-logging-3.3.0.Final.jar"/>
<!-- Insert resources here -->
</resources>
<dependencies>
<module name="org.jboss.logmanager"/>
</dependencies>
</module>
And the error was gone. Hope it helps.
This is because GlassFish ships with an earlier version of JBoss Logging and this is being picked up by your application hence the NoSuchMethod error. The version of JBoss Logging shipped with GlassFish 4.1 does not have the method defined. You can try and replace the version of jboss-logging in the modules directory of glassfish this may or may not work but it looks like you tried and failed with this approach.
Another option is to upgrade to the latest Payara 4.1.1.162 which ships with JBoss Logging 3.3.0.Final.
Block Glassfish for using its own lib when project lib is provided
Just create a glassfish-web.xml file in the WEB-INF directory. The contents of the file are shown below:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE glassfish-web-app PUBLIC "-//GlassFish.org//DTD GlassFish Application Server 3.1 Servlet 3.0//EN" "http://glassfish.org/dtds/glassfish-web-app_3_0-1.dtd">
<glassfish-web-app>
<class-loader delegate="false"/>
</glassfish-web-app>
This ensures that glassfish does not load it's internal libraries, but libraries from your project.
I'm migrating an application from Glassfish 2.1 to Jboss eap 6.0.1. Now I deploy my app in Jboss correctly but it doesn't work. I have made debug and I saw the problem. When the code arrives to this line:
OutputFormat format = OutputFormat(doc);
It fails. I made a new watch of "OutputFormat(doc)" and in the value appears this: Unknown type "org.apache.xml.serialize.OutputFormat"<
This class is inside xerces library. This library is installed as a module in my jboss. I have tried many things:
1.- Exclude jboss library and included the library in my war. Not deploy.
2.- Include my library (no JBoss' library) as a new module and, in the manifest, add this line: Dependencies: myModuleName. It deploys, but it doesn't work.
3.- The before "solution", and exclude jboss library. Not deploy.
This ocurred when the code arrives at the following line, and I have tried the same solutions:
XPathAPI.selectSingleNode( xmlTempDoc,"//a" )
The error at this time is: Unknown type "org.apache.xpath.XPathAPI"
This packages are in xercesImpl-2.9.1 and xalan-2.7.1 libraries respectively.
Can you help me, please?
Thanks,
Regards.
Try to exclude the default xalan and xerces libraries that come packaged witn JBoss EAP by adding jboss-deployment-structure.xml under /WEB-INF with below content:
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
<deployment>
<exclusions>
<module name="org.apache.xalan" />
<module name="org.apache.xerces" />
</exclusions>
</deployment>
</jboss-deployment-structure>
Then include yours in some path such as /lib folder.
I did not create the spring bean name with TimerServiceDispatcher in my application. But, the JBoss throw exception because of TimerServiceDispatcher is already defined in this module.
I don't know what is the problem. What I am missing? What I need to do?
My application use Seam 2.3, Spring 3.0 and JPA 2.0. I don't use EJB.
11:29:01,531 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015876: Starting deployment of "MRBS.war"
11:29:04,217 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC00001: Failed to start service jboss.deployment.unit."MRBS.war".PARSE: org.jboss.msc.service.StartExcept
ion in service jboss.deployment.unit."MRBS.war".PARSE: Failed to process phase PARSE of deployment "MRBS.war"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:119) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) [rt.jar:1.6.0_23]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [rt.jar:1.6.0_23]
at java.lang.Thread.run(Unknown Source) [rt.jar:1.6.0_23]
Caused by: java.lang.IllegalArgumentException: JBAS011046: A component named 'TimerServiceDispatcher' is already defined in this module
at org.jboss.as.ee.component.EEModuleDescription.addComponent(EEModuleDescription.java:137)
at org.jboss.as.ejb3.deployment.processors.EJBComponentDescriptionFactory.addComponent(EJBComponentDescriptionFactory.java:60)
at org.jboss.as.ejb3.deployment.processors.SessionBeanComponentDescriptionFactory.processSessionBeans(SessionBeanComponentDescriptionFactory.java:157)
at org.jboss.as.ejb3.deployment.processors.SessionBeanComponentDescriptionFactory.processAnnotations(SessionBeanComponentDescriptionFactory.java:86)
at org.jboss.as.ejb3.deployment.processors.AnnotatedEJBComponentDescriptionDeploymentUnitProcessor.processAnnotations(AnnotatedEJBComponentDescriptionDeploymentUnitProcessor.java:
58)
at org.jboss.as.ejb3.deployment.processors.AbstractDeploymentUnitProcessor.deploy(AbstractDeploymentUnitProcessor.java:81)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:113) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
... 5 more
11:29:04,230 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS015870: Deploy of deployment "MRBS.war" was rolled back with failure message {"JBAS014671: Failed servi
ces" => {"jboss.deployment.unit.\"MRBS.war\".PARSE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"MRBS.war\".PARSE: Failed to process phase PARSE of d
eployment \"MRBS.war\""}}
11:29:04,292 INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) JBAS015877: Stopped deployment MRBS.war in 61ms
11:29:04,294 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 2) JBAS014774: Service status report
JBAS014777: Services which failed to start: service jboss.deployment.unit."MRBS.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."MRBS.war".
PARSE: Failed to process phase PARSE of deployment "MRBS.war"
jboss-deployment-structure.xml
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.0">
<deployment>
<dependencies>
<module name="org.hibernate" export="true"/>
<module name="javax.faces.api" export="true" />
<module name="com.sun.jsf-impl" export="true"/>
<module name="org.dom4j" export="true"/>
<module name="org.hibernate.validator" export="true"/>
</dependencies>
<exclusions>
<module name="org.apache.log4j" />
</exclusions>
</deployment>
</jboss-deployment-structure>
Deplyment Structure
MRBS.war
-index.html
+web-page-pakage
+META-INF
+WEB-INF
+classes
+lib
aopalliance.jar
commons-beanutils.jar
commons-codec.jar
commons-lang-2.5.jar
drools-compiler.jar
drools-core.jar
drools-decisiontables.jar
drools-templates.jar
eclipselink.jar
el-api.jar
guava.jar
guice.jar
hibernate-ehcache.jar
httpclient.jar
httpcore.jar
javax.persistence_2.0.1.v201006031150.jar
jboss-el.jar
jboss-seam-debug.jar
jboss-seam-excel.jar
jboss-seam-ioc.jar
jboss-seam-mail.jar
jboss-seam-pdf.jar
jboss-seam-ui.jar
jboss-seam.jar
junit-4.8.1.jar
log4j-1.2.14.jar
mysql-connector-java-5.1.6-bin.jar
primefaces-3.3.1.jar
sac.jar
spring-aop.jar
spring-asm.jar
spring-beans.jar
spring-context.jar
spring-core.jar
spring-expression.jar
spring-jdbc.jar
spring-orm.jar
spring-tx.jar
spring-web.jar
urlrewritefilter.jar
xercesImpl.jar
xml-apis.jar
-components.xml
-faces-config.xml
-jboss-deployment-structure.xml
-pages.xml
-web.xml
I had a bean annotated with #Singleton and #Stateless that triggered this error. My code was of course wrong but the message and posts like this lead me down the wrong path for a while.
I know the answer to this one. Spent weeks with JBoss Support on it due to my stubborness. They plan on providing fix or at least better messaging with EAP 6.2.x release.
The problem arises with the EJB Annotation preprocessors - which take your war, and the libs compiled into it and scans them for EJB annotations. Some Jar files can have an entry in the Manifest for "Classpath: ." (or whatever but with '.' as one of the entries). This causes the annotation preprocessor to idiotically process all the jar files in the web-inf lib again. Finally it will get around to a jar file with an EJB annotation in it that it has already seen, because it was already processed earlier - this causes it to complain with "A component Named xxx is already defined".
So the most frustrating part here is that it's probably some old jar file that you don't even care about that has this unnecessary Classpath manifest entry in it - and causes JBoss to recurse on itself.
I had the same problem but for me none of the suggested solutions helped.
I noticed that the EJB JAR was present twice (newest version and older version) in the WEB.WAR.
This was because the maven clean operation on the parent project in eclipse didn't cascade to the child projects.
I fixed it by doing a simple "mvn clean" on the child project.
I had the same problem in IntelliJ. The reason was that IntelliJ created a WAR file with my classes both in WEB-INF/classes AND as a separate Jar file in WEB-INF/lib.
It took me some time to find out why IntelliJ did this.
The reason lay in the dialogue File -> Project Structure -> Artifacts:
After removing the 'vertrag-ui-war' compile output, the error did not occur anymore.
P.S. I have no idea why IntelliJ made this setting - I definitively did not set this.
Running the Maven goals:
wildfly:undeploy
clean
wildfly:deploy
helped in our case:
[ERROR] Caused by: java.lang.IllegalArgumentException: WFLYEE0040: A component named 'xxx' is already defined in this module"}}
Removing #Singleton fixed this error for me. No idea why though.
The problem is not that you dint create TimeServiceDispatcher it is a class part of seam framework org.jboss.seam.async.TimerServiceDispatcher , its a seam fw class.
Now about the error.
These kind of error occur when there are conflicts in libraries provided with application and by server. Its seriously very common with JBoss 7.1 and very frustrating as well.
You need to know
What all Libraries and there version are u packaging inside your application ?
what all of above libraries and version are provided by JBoss 7.1
Now for libraries that are on both side
check for version
if version of application and JBoss is same , then remove that jar from Application (suggested) (else you can configure in the deployment-structure.xml which one to use)
if version of application jar and jboss is different, in that case , you will need to configure in deployment descriptor which one to pick.
While copy pasting and creating new components, I forgot to update the value that the #Stateless(value) annotation accept in the new components. This meant I had two components with the same name and I got this error. Hope it helps someone.
It can be caused by a previous version of the jar being deployed instead of the correct one. It was solved when I deleted all the contents of the target folder.
The answers helped me locate the root cause of my issue.
I am using Arquillian and I was adding to the Web archive a class through the
JavaArchive ja = ShrinkWrap.create(JavaArchive.class, "myejb.jar")
.addPackages(true, "a.package.name")
and as a maven dependency
File[] files = Maven.resolver()
.addDependencies(
MavenDependencies.createDependency("G:A:V", ScopeType.COMPILE, false),
Hence the previously described error.
I left only the maven dependency and the error disappeared.