Ответ 1
У меня был bean, аннотированный с @Singleton и @Stateless, который вызвал эту ошибку. Мой код был, конечно, неправильным, но сообщение и сообщения, подобные этому, на некоторое время привели меня к неправильному пути.
Я не создал имя spring bean с TimerServiceDispatcher
в своем приложении. Но исключение JBoss
throw из-за TimerServiceDispatcher
уже определено в этом модуле.
Я не знаю, в чем проблема. Что мне не хватает? Что мне нужно сделать?
Мое приложение использует Seam 2.3, spring 3.0 и JPA 2.0. Я не использую 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 развертывания-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>
Структура рельефа
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
У меня был bean, аннотированный с @Singleton и @Stateless, который вызвал эту ошибку. Мой код был, конечно, неправильным, но сообщение и сообщения, подобные этому, на некоторое время привели меня к неправильному пути.
Я знаю ответ на этот вопрос. Провел недели с поддержкой JBoss на этом из-за моей упрямства. Они планируют предоставить исправление или, по крайней мере, улучшить обмен сообщениями с выпуском EAP 6.2.x.
Проблема возникает с препроцессорами EJB Annotation, которые берут вашу войну, и библиотеки компилируются в нее и просматривают их для аннотаций EJB. Некоторые файлы Jar могут иметь запись в манифесте для "Classpath:.". (или что-то еще, но с "." как одна из записей). Это заставляет препроцессор аннотации идиотично обрабатывать все файлы jar в web-inf lib снова. Наконец, он будет связан с файлом jar с аннотацией EJB в нем, которую он уже видел, потому что он уже обрабатывался ранее - это заставляет его жаловаться на "Компонент, названный xxx уже определен".
Таким образом, самая неприятная часть здесь заключается в том, что, вероятно, какой-то старый файл jar, который вам даже не волнует, содержит эту ненужную запись манифеста Classpath - и заставляет JBoss рекурсировать сам по себе.
Запуск целей Maven:
wildfly:undeploy
clean
wildfly:deploy
помог в нашем случае:
[ERROR] Вызвано: java.lang.IllegalArgumentException: WFLYEE0040: В этом модуле уже определен компонент с именем 'xxx'}}
У меня была такая же проблема, но для меня ни одна из предлагаемых решений не помогла.
Я заметил, что EJB JAR
присутствовал twice
(newest version and older version
) в WEB.WAR.
Это связано с тем, что операция maven
clean в родительском проекте в eclipse не каскадировалась на дочерние проекты.
Я исправил это, выполнив простой "mvn clean"
на child project
.
Проблема заключается не в том, что вы создаете TimeServiceDispatcher
, это классовая часть структуры шва org.jboss.seam.async.TimerServiceDispatcher
, ее класс sem fw.
Теперь об ошибке.
Такая ошибка возникает при наличии конфликтов в библиотеках, предоставляемых приложением и сервером. Это очень распространено с JBoss 7.1 и очень расстраивает.
Вам нужно знать
Теперь для библиотек, которые находятся с обеих сторон проверить версию
Если версия приложения и JBoss одинаковы, то удалите эту банку из приложения (предположительно) (иначе вы можете настроить в файле deployment-structure.xml, который использовать)
если версия приложения jar и jboss различна, в этом случае вам нужно будет настроить дескриптор развертывания, который выбрать.
При копировании и создании новых компонентов я забыл обновить значение, которое принимает аннотация @Stateless(value)
в новых компонентах. Это означало, что у меня было два компонента с тем же именем, и я получил эту ошибку. Надеюсь, это поможет кому-то.
Удаление @Singleton исправило эту ошибку для меня. Не знаю почему.
У меня была такая же проблема в IntelliJ. Причина заключалась в том, что IntelliJ создал WAR файл с моими классами как в WEB-INF/classes AND, так и в качестве отдельного файла Jar в WEB-INF/lib.
Мне потребовалось некоторое время, чтобы узнать, почему IntelliJ сделал это.
Причина заключается в диалоге Файл → Структура проекта → Артефакты:
После удаления компиляционного файла 'vertrag-ui-war' ошибка больше не возникала. Постскриптум Я понятия не имею, почему IntelliJ сделал эту настройку - я окончательно не задал этого.