]
Nuno Godinho de Matos commented on WFLY-9231:
---------------------------------------------
Having a proper exception with more metadata would really be useful.
I am now configuring a relatively big projec to be deployed against wildfly.
And as I am trying to automate the generation of the jboss-ejb3.xml from a
weblogic-ejb.xml, one thing that is different in wildfly is that we are forced to declare
destinationLookup for every mdb.
e.g. while producing metadata such as follows
{code}
<message-driven>
<ejb-name>SomeMdb</ejb-name>
<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/SomeMdbQueue</activation-config-property-value>
</activation-config-property>
</activation-config>
</message-driven>
{code}
During deployment I came again against this component class is null.
I go to debug and I see an specific mdb in there in the component name.
The deployment folder of wildfly was OK with the class this time.
So I check the annotations on the MdB and and see that the ejbName on the annotation was
the same name as the queue.
The Ejb has a copy paste mistake, essentially, and the component class for the component
name could not be figured out.
If I am not told what component in the xml file is buggy, I cannot fix my deployment
issue.
And it is way to easy to have configuration errors in the jboss-ejb3.xml.
This issue really slows down development time.
Kindest regards.
Wildfly wildfly-ejb3 - 10.1.0.Final EJBComponentDescription - not
useful exception when class for mdb not found
---------------------------------------------------------------------------------------------------------------
Key: WFLY-9231
URL:
https://issues.jboss.org/browse/WFLY-9231
Project: WildFly
Issue Type: Bug
Components: EJB
Affects Versions: 10.1.0.Final
Environment: windows 7, but it is immaterial
Reporter: Nuno Godinho de Matos
Priority: Minor
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:
{panel}
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
{panel}
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:
{panel}
<dependency>
<groupId>org.wildfly</groupId>
<artifactId>wildfly-ejb3</artifactId>
<version>10.1.0.Final</version>
<scope>provided</scope>
</dependency>
{panel}
Debug the class:
org.jboss.as.ejb3.component.EJBComponentDescription
{panel}
public EJBComponentDescription(final String componentName, final String
componentClassName, final EjbJarDescription ejbJarDescription, final ServiceName
deploymentUnitServiceName, final EnterpriseBeanMetaData descriptorData) {
super(componentName, componentClassName,
ejbJarDescription.getEEModuleDescription(), deploymentUnitServiceName);
{panel}
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.
{panel}
<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>
{panel}
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.