Currently I try, for my first time, to use Wildfly with MongoDB and Hibernate OGM. When I deploy my Project to Wildfly, the following error occurs:
"{ \"WFLYCTL0080: Failed services\" => {\"jboss.deployment.unit.\\\"{MYAPP}.war\\\".STRUCTURE\" => \"org.jboss.msc.service.StartException in service jboss.deployment.unit.\\\"{MYAPP}.war\\\".STRUCTURE: WFLYSRV0153: Failed to process phase STRUCTURE of deployment \\\"{MYAPP}.war\\\"
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYSRV0168: Error loading jboss-deployment-structure.xml from {MYUSERDIR}/wildfly10/standalone/deployments/{MYAPP}.war/WEB-INF/jboss-deployment-structure.xml
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[2,1]
Message: Unexpected element '{http://www.jboss.com/xml/ns/javaee}jboss-web'\"},
\"WFLYCTL0412: Required services that are not installed:\" => [\"jboss.deployment.unit.\\\"{MYAPP}.war\\\".STRUCTURE\"],
\"WFLYCTL0180: Services with missing/unavailable dependencies\" => undefined }"
My jboss-deployment-structure.xml looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
<deployment>
<dependencies>
<module name="org.hibernate" slot="ogm" services="import" />
<module name="org.hibernate.ogm.mongodb" slot="main" services="import" />
</dependencies>
</deployment>
</jboss-deployment-structure>
This Jboss Document mentions to add Modules (which I did) to the Wildfly Folder and add an Entry to the Manifest.mf File which I created manually.
Does anybody have an idea, what to try next?
I would also appreciate a Recommendation for a good Tutorial.
Sidenotes:
NetBeans 8.2
Wildfly 10
MacOS
MongoDB on Ubuntu 16.04 VM
I googled a lot
The Tutorial I basically used
I'm trying to subscribe to GC notifications using GarbageCollectionNotificationInfo. The notifications work, but when I try use this mechanism inside Wildfly 8.2, I get a java.lang.NoClassDefFoundError:
java.lang.NoClassDefFoundError: com/sun/management/GarbageCollectionNotificationInfo
2017-02-06 08:40:09,156 ERROR [stderr] (Service Thread) at com.vonage.metrics.GCNotificationListener.handleNotification(GCNotificationListener.java:28)
2017-02-06 08:40:09,156 ERROR [stderr] (Service Thread) at sun.management.NotificationEmitterSupport.sendNotification(NotificationEmitterSupport.java:156)
2017-02-06 08:40:09,157 ERROR [stderr] (Service Thread) at sun.management.GarbageCollectorImpl.createGCNotification(GarbageCollectorImpl.java:147)
I found that in some cases you need to include dependencies in Jboss/Wildfly: https://docs.jboss.org/author/display/WFLY8/Class+Loading+in+WildFly
Do I need to somehow include the com.sun.* packages?
I've recently encountered the same issue, only with WildFly 10.1.0.Final.
The solution is to explicitly include com.sun.management classes using something like this in your jboss-deployment-structure.xml:
<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
<deployment>
<dependencies>
<system>
<paths>
<path name="com/sun/management"/>
</paths>
</system>
</dependencies>
</deployment>
</jboss-deployment-structure>
I am trying to upgrade my application from JBoss 7 to WildFly10, and I am getting a warning:
[0m[33m13:53:36,641 WARN [org.jboss.as.dependency.private] (MSC service thread 1-6)
WFLYSRV0018: Deployment "deployment.mywar.war" is using a private module
("org.jboss.as.jmx:main") which may be changed or removed in future versions
without notice.
The module is mentioned in jboss-deployment-structure.xml as follows:
<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure >
<deployment>
<dependencies>
<module name="org.jboss.as.jmx"/>
</dependencies>
</deployment>
</jboss-deployment-structure>
how is called the new module for jmx? I tried to replace that with org.jboss.remoting-jmx but then I got
Invocation of init method failed;
nested exception is javax.management.JMRuntimeException:
Failed to load MBeanServerBuilder class org.jboss.as.jmx.PluggableMBeanServerBuilder:
java.lang.ClassNotFoundException: org.jboss.as.jmx.PluggableMBeanServerBuilder
according to WildFly forum it means nothing, see quote (source)
You got warning message as you are using internal "non-public" modules
from application server. Which just tells you that you should be
careful with this.
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 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.