Details
-
Bug
-
Resolution: Done
-
Minor
-
10.1.0.Final
-
None
Description
While opening a WAR project on eclipse, for some unkown reason, the project / jboss tooling integration was not working properly.
In particular, when deploying a small sample application there was an Mdb class that was not getting copied over to the deploymnet folder.
e.g.
C:\dev\Widlfly10\wildfly-10.1.0.Final\user_projects\domains\standalone-orcl\deployments\wildfly-jta-commit-reproducebug.war\WEB-INF\classes\entrypoint\mdb
The above folder was empty.
The deployment would fail because the Mdb class was not withing that folder.
Now the fix for this problem was to close and re-open the project.
Ater which whatever glitch was going on eclipse got resolved and the deployment process started working properly.
With that said, this issue is about the exception that wildfly was firing during the deployment:
Namely:
2017-08-16 14:08:00,203 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."wildfly-jta-commit-reproducebug.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."wildfly-jta-commit-reproducebug.war".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment "wildfly-jta-commit-reproducebug.war"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
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:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.IllegalArgumentException: WFLYEE0078: componentClassName is null
at org.jboss.as.ee.component.ComponentDescription.<init>(ComponentDescription.java:114)
at org.jboss.as.ejb3.component.EJBComponentDescription.<init>(EJBComponentDescription.java:269)
at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponentDescription.<init>(MessageDrivenComponentDescription.java:96)
at org.jboss.as.ejb3.deployment.processors.MessageDrivenComponentDescriptionFactory.processMessageDrivenBeanMetaData(MessageDrivenComponentDescriptionFactory.java:244)
at org.jboss.as.ejb3.deployment.processors.MessageDrivenComponentDescriptionFactory.processBeanMetaData(MessageDrivenComponentDescriptionFactory.java:88)
at org.jboss.as.ejb3.deployment.processors.AnnotatedEJBComponentDescriptionDeploymentUnitProcessor.processBeanMetaData(AnnotatedEJBComponentDescriptionDeploymentUnitProcessor.java:64)
at org.jboss.as.ejb3.deployment.processors.AbstractDeploymentUnitProcessor.processDeploymentDescriptor(AbstractDeploymentUnitProcessor.java:138)
at org.jboss.as.ejb3.deployment.processors.AbstractDeploymentUnitProcessor.deploy(AbstractDeploymentUnitProcessor.java:79)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
... 5 more
The above exception is not very useful, because it does not say what component is the point of origin for the above exception.
Before I could go investigate the folder in the deployment dir, I thought there must be something wrong in the project (there wasn't).
So I had to wonder what component was bugy.
It was necessary to add to the project the following dependency:
<dependency>
<groupId>org.wildfly</groupId>
<artifactId>wildfly-ejb3</artifactId>
<version>10.1.0.Final</version>
<scope>provided</scope>
</dependency>
Debug the class:
org.jboss.as.ejb3.component.EJBComponentDescription
public EJBComponentDescription(final String componentName, final String componentClassName, final EjbJarDescription ejbJarDescription, final ServiceName deploymentUnitServiceName, final EnterpriseBeanMetaData descriptorData) {
super(componentName, componentClassName, ejbJarDescription.getEEModuleDescription(), deploymentUnitServiceName);
To figure out the compnent name that was the cause of the issue.
Then I finally added the ejb-class extra metadata to the jboss-ejb3.xml.
<message-driven>
<ejb-name>ReproduceBugMdb</ejb-name>
<!-- Sometimes neecessary. -->
<ejb-class>entrypoint.mdb.ReproduceBugMdb</ejb-class>
<resource-ref>
<res-ref-name>JmsXA</res-ref-name>
<res-type>javax.jms.ConnectionFactory</res-type>
<lookup-name>java:/JmsXA</lookup-name>
</resource-ref>
<activation-config>
<activation-config-property>
<activation-config-property-name>maxSession</activation-config-property-name>
<activation-config-property-value>1</activation-config-property-value>
</activation-config-property>
<activation-config-property>
<activation-config-property-name>destinationLookup</activation-config-property-name>
<activation-config-property-value>java:/queue/ReproduceBugQueue</activation-config-property-value>
</activation-config-property>
</activation-config>
</message-driven>
And only then could I get the "class not found exception" that lead me to go take a peek at the deployment folder and see that the folder was empty of any classes.
Which lead me to close and open the project.
I believe that the firing up an exception that reports that component class is null does not help anybody.
The exception should give as much context as possible to help the user identify the point of origing of the problem.
In this case, it should at least refer the mdb whose class could not be figured out during deployment.
Kindest regards.
