[jboss-jira] [JBoss JIRA] (WFLY-9231) Wildfly wildfly-ejb3 - 10.1.0.Final EJBComponentDescription - not useful exception when class for mdb not found

Nuno Godinho de Matos (JIRA) issues at jboss.org
Wed Aug 16 08:53:00 EDT 2017


Nuno Godinho de Matos created WFLY-9231:
-------------------------------------------

             Summary: 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.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


More information about the jboss-jira mailing list