Develop Reference

Jboss 6.4 Infinispan 8.2 and JGroups - ClassNotFoundException

I need some features from Infinispan 8+. Therefore I have updated my company app pom.xml with the newest Infinispan pom.
It was quite straightforward, but the app uses jgroups (or its default config in default-configs/default-jgroups-udp.xml - this location is different from previous versions of infinispan). The default versions have some parameters (and the XSD from Jgroups version 3.6) - so I also bumped jgroups to 3.6.8.Final as it looks like it is the intended version (and the version that does not complain about unknown parameters in default config in infinispan 8.2)
so the pom is the following:
<dependency>
<groupId>org.jgroups</groupId>
<artifactId>jgroups</artifactId>
<version>3.6.8.Final</version>
</dependency>
<dependency>
<groupId>org.infinispan</groupId>
<artifactId>infinispan-core</artifactId>
<version>8.2.0.Final</version>
</dependency>
Anyway - this application starts with no problems using spring-boot with Jetty. I am pretty sure it would start on any application server.
But then I have no choice but to run it on JBoss 6.4.
There I got an exception involving some jboss.as classes (this is kind of unexpected) during the deployment:
Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.remoting.transport.jgroups.JGroupsTransport.start() on object of type JGroupsTransport
at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:172)
at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:859)
at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:628)
at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:617)
at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:542)
at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:234)
... 141 more
Caused by: java.lang.ExceptionInInitializerError
at org.jgroups.conf.XmlConfigurator.<clinit>(XmlConfigurator.java:35)
at org.jgroups.conf.ConfiguratorFactory.getStackConfigurator(ConfiguratorFactory.java:62)
at org.jgroups.JChannel.<init>(JChannel.java:129)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:419)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannel(JGroupsTransport.java:320)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannelAndRPCDispatcher(JGroupsTransport.java:366)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:190)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
... 146 more
Caused by: java.lang.RuntimeException: java.lang.ClassNotFoundException: org.jboss.as.clustering.jgroups.LogFactory from [Module "deployment.mymodule-5.0.0.0-SNAPSHOT.ear.appName.war:main" from Service Module Loader]
at org.jgroups.logging.LogFactory.<clinit>(LogFactory.java:31)
... 158 more
Caused by: java.lang.ClassNotFoundException: org.jboss.as.clustering.jgroups.LogFactory from [Module "deployment.mymodule-5.0.0.0-SNAPSHOT.ear.appName.war:main" from Service Module Loader]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at org.jgroups.logging.LogFactory.<clinit>(LogFactory.java:28)
... 158 more
My guess is that org.jgroups.logging.LogFactory somehow discovers that is is running on a Jboss and tries to use org.jboss.as.clustering.jgroups.LogFactory but this version of Jboss does not have one. (the server directory EAP-6.4.0\modules\system\layers\base\org\jgroups\main contains jgroups version 3.2.X).
Is there any walkaround to use this jgroups version (and so Infinispan 8.2) in Jboss 6.4?
This is (the application) an ear file so I can manipulate jboss-deployment-structure.xml file, but so far I only came with excluding Jboss original jgroups, and this did not help.
<exclusions>
<module name="org.jgroups"/>
</exclusions>

This is currently bug with Infinispan 8 + EAP 6.4 combination. The reason is exactly as #Flavius says in comments. Currently there is discussion where to fix it, but it'll mostly likely be fixed in EAP 6.4. I'm sure it will be done soon.
I can only offer you a working workarounds.
Use WildFly - the issue is not present there anymore
Little nasty workaround, but it works:
Call System.clearProperty("jgroups.logging.log_factory_class"); in the deployment
Include JBoss Logging of version specified in infinispan-bom in your deployment (e.g. add jboss-logging Maven dependency in your pom.xml)
Provide jboss-deployment-structure.xml to your deployment, which excludes the server's JBoss logging, see below:
<jboss-deployment-structure>
<deployment>
<exclusions>
<module name="org.jboss.logging" />
</exclusions>
</deployment>
</jboss-deployment-structure>

Another possibility if none of the above workarounds work (for instance the app uses other log mechanisms) is to implement an own
http://www.jgroups.org/javadoc/org/jgroups/logging/CustomLogFactory.html
The log factory must return a log instance, implementing it for any other logger is straightforward with methods trace/error/debug etc.
Then this logger class can be set with System.setProperty("jgroups.logging.log_factory_class","my.company.logging.MyJgroupsLog");

How to share JPA data model between 2 EAR in JBoss "Wildfly"

We have a working JBoss v8 "Wildfly" deployment like this:
App-ear.ear
|_App-model.jar
|_App-ejb.jar
|_App-web.war
This deployment comes with a persistence.xml inside the App-model.jar. Now I want to deploy a second EAR with a different WAR module that I can re-deploy independent from the original application. Therefor I've created a second EAR like this:
Second-ear.ear
|_Second-web.war
The second application has a classpath dependency to App-model.jar during development in Eclipse (setup as Maven projects) and builds just fine. To make that dependency available during runtime I've edited Second-ear.ear/META-INF/jboss-deployment-structure.xml like this:
<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
<deployment>
<dependencies>
<module name="deployment.App-ear.ear.App-model.jar" />
</dependencies>
</deployment>
</jboss-deployment-structure>
But the JBoss AS fails to load the persistence with the following error:
2015-08-19 09:13:36,903 ERROR [] [ # ] [] [MSC service thread 1-5] [fail] MSC000001: Failed to start service jboss.deployment.unit."Second-ear.ear".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."Second-ear.ear".WeldStartService: Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_25]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_25]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_25]
Caused by: java.lang.IllegalArgumentException: JBAS016069: Error injecting persistence unit into CDI managed bean. Can't find a persistence unit named MyPersistenceUnitName in deployment Second-ear.ear
at org.jboss.as.weld.services.bootstrap.WeldJpaInjectionServices.getScopedPUName(WeldJpaInjectionServices.java:110)
at org.jboss.as.weld.services.bootstrap.WeldJpaInjectionServices.registerPersistenceUnitInjectionPoint(WeldJpaInjectionServices.java:90)
at org.jboss.weld.injection.ResourceInjectionFactory$PersistenceUnitResourceInjectionProcessor.getResourceReferenceFactory(ResourceInjectionFactory.java:279)
at org.jboss.weld.injection.ResourceInjectionFactory$PersistenceUnitResourceInjectionProcessor.getResourceReferenceFactory(ResourceInjectionFactory.java:267)
at org.jboss.weld.injection.ResourceInjectionFactory$ResourceInjectionProcessor.createFieldResourceInjection(ResourceInjectionFactory.java:207)
at org.jboss.weld.injection.ResourceInjectionFactory$ResourceInjectionProcessor.createResourceInjections(ResourceInjectionFactory.java:182)
at org.jboss.weld.injection.ResourceInjectionFactory.discoverType(ResourceInjectionFactory.java:405)
at org.jboss.weld.injection.ResourceInjectionFactory.getResourceInjections(ResourceInjectionFactory.java:92)
at org.jboss.weld.injection.producer.ResourceInjector.<init>(ResourceInjector.java:59)
at org.jboss.weld.injection.producer.ResourceInjector.of(ResourceInjector.java:49)
at org.jboss.weld.injection.producer.BeanInjectionTarget.<init>(BeanInjectionTarget.java:62)
at org.jboss.weld.injection.producer.BeanInjectionTarget.createDefault(BeanInjectionTarget.java:46)
at org.jboss.weld.manager.InjectionTargetFactoryImpl.chooseInjectionTarget(InjectionTargetFactoryImpl.java:128)
at org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:87)
at org.jboss.weld.bean.ManagedBean.<init>(ManagedBean.java:91)
at org.jboss.weld.bean.ManagedBean.of(ManagedBean.java:71)
at org.jboss.weld.bootstrap.AbstractBeanDeployer.createManagedBean(AbstractBeanDeployer.java:264)
at org.jboss.weld.bootstrap.BeanDeployer.createClassBean(BeanDeployer.java:228)
at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$2.doWork(ConcurrentBeanDeployer.java:78)
at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$2.doWork(ConcurrentBeanDeployer.java:75)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_25]
... 3 more
The CDI Bean that's trying to use that persistence unit injects an EntityManager produced by the original App-model.jar:
#Named("test")
public class Test {
#Inject
#MyModelDB // Qualifier
private EntityManager em = null;
// A simple test of the datamodel...
public Long numberOfProjects() {
if (this.em != null) {
return ((BigDecimal) this.em.createNativeQuery("select count(*) from e_bo_projects").getSingleResult()).longValue();
}
return -1L;
}
}
How can I solve this problem?

I've successfully deployed my two EARs now... thanks for your comments to my original question. My initial approach with 2 EAR including the same data-model JAR works, if the persistence.xml doesn't include the JNDI binding. Thanks #Franck! The mentioned jboss-deployment-structure.xml does no longer refer to my other EAR.
So now my deployment looks like this:
App-ear.ear
|_App-model.jar
|_App-ejb.jar
|_App-web.war
Second-ear.ear
|_App-model.jar
|_Second-web.war
This works for both applications and I've successfully accessed the database in both cases.

Guava 15 lib in jboss as 7.2

My webapp using guava-15.jar lib, but in start jboss as 7.2 results exception:
17:26:57,330 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC00001: Failed to start service jboss.deployment.unit."ROOT.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."ROOT.war".WeldStartService: Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1767) [jboss-msc-1.0.4.GA.jar:1.0.4.GA]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) [rt.jar:1.6.0_45]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) [rt.jar:1.6.0_45]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_45]
Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [Set] with qualifiers [#Default] at injection point [[parameter 1] of [constructor] #Inject com.google.common.util.concurrent.ServiceManager(Set)]
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:311)
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:280)
at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:143)
at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:163)
at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:382)
at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:367)
at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:379)
at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:64)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.4.GA.jar:1.0.4.GA]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.4.GA.jar:1.0.4.GA]
... 3 more
But if remove library my application works.

It's been a while since this post, but in case anyone else comes across this...
This appears to be due to Guava 15.0 being deployed into a CDI 1.0 container.
See this post/fix, especially comment #16 (if using maven). I can't speak to whether they've created this cdi1.0 jar for versions 16 or 17.
Guava 15 cannot be deployed in an environment using CDI 1.0 such as JEE6
For convenience, the Maven dependency:
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>15.0</version>
<classifier>cdi1.0</classifier>
</dependency>

Java .war deployment issues on jboss-as-7.1.1.Final

I am working on a dynamic web project (StudentManagement.war) which relies on an EJB (StudentManagementEJB.jar) for database interfacing. The EJB project has been added to the web project's class path. On deployment, however, the following exceptions are thrown:
22:23:21,275 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC00001: Failed to start service jboss.deployment.unit."StudentManagement.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."StudentManagement.war".POST_MODULE: Failed to process phase POST_MODULE of deployment "StudentManagement.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.runWorker(Unknown Source) [rt.jar:1.7.0_45]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [rt.jar:1.7.0_45]
at java.lang.Thread.run(Unknown Source) [rt.jar:1.7.0_45]
Caused by: java.lang.RuntimeException: Error getting reflective information for class student.management.ManageStudentServlet with ClassLoader ModuleClassLoader for Module "deployment.StudentManagement.war:main" from Service Module Loader
at org.jboss.as.server.deployment.reflect.DeploymentReflectionIndex.getClassIndex(DeploymentReflectionIndex.java:70) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.as.ee.metadata.MethodAnnotationAggregator.runtimeAnnotationInformation(MethodAnnotationAggregator.java:58)
at org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.handleAnnotations(InterceptorAnnotationProcessor.java:85)
at org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.processComponentConfig(InterceptorAnnotationProcessor.java:70)
at org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.deploy(InterceptorAnnotationProcessor.java:55)
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
Caused by: java.lang.NoClassDefFoundError: Lstudent/management/ManageStudentSessionBeanLocal;
at java.lang.Class.getDeclaredFields0(Native Method) [rt.jar:1.7.0_45]
at java.lang.Class.privateGetDeclaredFields(Unknown Source) [rt.jar:1.7.0_45]
at java.lang.Class.getDeclaredFields(Unknown Source) [rt.jar:1.7.0_45]
at org.jboss.as.server.deployment.reflect.ClassReflectionIndex.<init>(ClassReflectionIndex.java:57) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.as.server.deployment.reflect.DeploymentReflectionIndex.getClassIndex(DeploymentReflectionIndex.java:66) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
... 10 more
Caused by: java.lang.ClassNotFoundException: student.management.ManageStudentSessionBeanLocal from [Module "deployment.StudentManagement.war:main" from Service Module Loader]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
... 15 more
This shows that the web module cannot find classes defined within the bean. I've changed my default: %JBOSS_HOME%\standalone\deployments\StudentManagement.war\META-INF\MANIFEST.MF to:
Manifest-Version: 1.0
Class-Path: file:/C:/Utils/jboss-as-7.1.1.Final/jboss-as-7.1.1.Final/standalone/deployments/StudentManagementEJB.jar
In spite of this the exception persists. There are two spaces between Class-Path: and the URI and a space after the end of the URI(../standalone) followed by a new line character.
Is there something wrong in my syntax?
I am using java ee 7, jboss-as-7.1.1.Final and Win 7 x64.

It turns out that the StudentManagementEJB.jar file is not copied into the /lib directory upon deployment. Aside from adding it to the Class-Path, it must also be copied to
%JBOSS_HOME%\standalone\deployments\<ProjectName>.war\WEB-INF\lib
directory(if the project is deployed as .war). In this case ProjectName is StudentManagement.

Do not reference to the deployments-folder (standalone/deployments). The deployed applications are not really deployed there, but copied from there to the data-directory, or they are not even in the deployments-folder, if you use other forms of deployment, e.g. jboss-cli.bat
There are some ways you can solve this.
1) Don't package the EJB separately, but include it into the WAR (the easiest).
2) Create an EAR and package the WAR and EJB-JAR together into the EAR (the classic).
3) Create a module from the interface-classes and reference from EJB.jar and WAR to the module. See e.g. "Dependencies:" in https://docs.jboss.org/author/display/AS71/Class+Loading+in+AS7
4) Reference in the WARs MANIFEST to the EJB-deployment like:
Dependencies:deployment.StudentManagementEJB.jar
From https://docs.jboss.org/author/display/AS71/Class+Loading+in+AS7:
Module names for top level deployments follow the format
deployment.myarchive.war while sub deployments are named like
deployment.myear.ear.mywar.war.
This means that it is possible for a deployment to import classes from
another deployment using the other deployments module name, the
details of how to add an explicit module dependency are explained
below.

A component named 'XXX' is already defined in this module in JBoss 7.1.1

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.