WildFly 8.2.1 Deployment error: NoSuchMethodException: org.objectweb.asm.MethodWriter.visitLabel(org.objectweb.asm.Label)

[stephan_b]

I have seen plenty of posts relating to this particular library conflict, but unfortunately I have not been able to adapt any of the given solutions to something that works for me.

I am relatively new to WildFly, which may be a key reason. Here is my problem:

I have a COTS product (ear) that is deployed on 8.2.1 which works fine. That product configured WildFly somewhat during install-time, and the product contains a webservice listener.

What I am trying to do is deploy a small second war file that also contains a webservice listener, which fails to deploy if the COTS product is deployed as well.

Both deployments work independently of each other, but together they fail. The first deployment works, the second one fails, no matter which deployment goes first.

2018-07-25 13:52:01,071 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."CMSIntegration_-_WildFly.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."CMSIntegration_-_WildFly.war".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment "CMSIntegration_-_WildFly.war"

at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.2.1.Final.jar:8.2.1.Final]

at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]

at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_171]

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_171]

at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_171]

Caused by: javax.xml.ws.WebServiceException: java.lang.reflect.UndeclaredThrowableException

at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:371)

at org.jboss.wsf.stack.cxf.deployment.EndpointImpl.doPublish(EndpointImpl.java:66)

at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:251)

at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:539)

at org.jboss.wsf.stack.cxf.configuration.NonSpringBusHolder.configure(NonSpringBusHolder.java:118)

at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.startDeploymentBus(BusDeploymentAspect.java:136)

at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.start(BusDeploymentAspect.java:68)

at org.jboss.as.webservices.deployers.AspectDeploymentProcessor.deploy(AspectDeploymentProcessor.java:75)

at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.2.1.Final.jar:8.2.1.Final]

... 5 more

Caused by: java.lang.reflect.UndeclaredThrowableException

at com.sun.proxy.$Proxy83.visitLabel(Unknown Source)

at org.apache.cxf.jaxws.WrapperClassGenerator.createWrapperClass(WrapperClassGenerator.java:213)

at org.apache.cxf.jaxws.WrapperClassGenerator.generate(WrapperClassGenerator.java:122)

at org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.generatedWrapperBeanClass(JaxWsServiceFactoryBean.java:683)

at org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.getExtraClass(JaxWsServiceFactoryBean.java:653)

at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:484)

at org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.buildServiceFromClass(JaxWsServiceFactoryBean.java:704)

at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:550)

at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:265)

at org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:215)

at org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:102)

at org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:159)

at org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBean.java:211)

at org.apache.cxf.jaxws.EndpointImpl.getServer(EndpointImpl.java:456)

at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:334)

... 13 more

Caused by: java.lang.NoSuchMethodException: org.objectweb.asm.MethodWriter.visitLabel(org.objectweb.asm.Label)

at java.lang.Class.getMethod(Class.java:1786) [rt.jar:1.8.0_171]

at org.apache.cxf.common.util.ReflectionInvokationHandler.invoke(ReflectionInvokationHandler.java:85)

... 28 more

2018-07-25 13:52:01,086 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"CMSIntegration_-_WildFly.war\".INSTALL" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"CMSIntegration_-_WildFly.war\".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment \"CMSIntegration_-_WildFly.war\"

    Caused by: javax.xml.ws.WebServiceException: java.lang.reflect.UndeclaredThrowableException

    Caused by: java.lang.reflect.UndeclaredThrowableException

    Caused by: java.lang.NoSuchMethodException: org.objectweb.asm.MethodWriter.visitLabel(org.objectweb.asm.Label)"}}

I've tried several things in my jboss-deployment-structure.xml, but this is where my lack of WildFly knowledge probably handicaps me.

The stack trace you see is without any jboss-deployment-structure.xml in place. The only package I can realistically work with is the second custom deployment because it's mine to edit and compile. That deployment doesn't include any ASM jars, which is all the more confusing.

Any ideas?

[jewellgm]

Does the ear contain ASM jars anywhere?  Either in the lib directory, or an embedded war's WEB-INF/lib directory?  If so, you may be able to force the 3rd party ear and your war to use the ASM jars provided by wildfly by creating a global module.  See the following:

Class Loading in WildFly - WildFly 10 - Project Documentation Editor

Look in the "Global Modules" section, and add the dependency for "asm.asm".  You may also be able to have your war depend on that module, but I don't know whether there would still be problems if the deployment order changed.

[stephan_b]

Greg, thank you for your suggestion.

The COTS product did have its own ASM-3.0 jars in the ear/library directory. Once I added the asm.asm <global-modules> section to the <domain:ee> subsystem, both deployments started successfully.

However, I'd like to understand a bit more what this does, and how this may (negatively?) impact the COTS product - if at all.

Can you shed some light on exactly what is happening? In particular, am I now forcing the COTS product to use the WildFly embedded asm, or am I telling WildFly to use the COTS asm jars and push those out to the other deployments?  What is "asm.asm" referring to?

[jewellgm]

I'm glad that it worked for you.  Classloading in wildfly is one of the things that trips people up quite a bit.  The mechanism changed quite a bit between JBoss AS 6 and JBoss AS 7.  The link that I provided to you describes how classloading works in all versions of JBoss AS/wildfly since version 7.  If you are going to continue working with Wildfly, you should get to know that page inside and out -- it will help you to prevent a lot of problems.

Wildfly contains many jars that it utilizes to provide services to deployments, and for its own functionality.  All of these jars are broken up into components, called modules.  The majority of these modules, by default, are not visible to deployments.  This means that deployments can embed jars that wildfly already has, and there won't be any classloading issues.  This also means that deployments can utilize different versions of jars than what wildfly has without conflict.

Problems arise when multiple copies (or versions) of a jar are loaded.  This is what was happening in your case.  One of the modules that is always deployed to dependencies is the web services framework.  This framework has a dependency on the "asm.asm" module.  What I *think* was happening is that the wildfly web service jars were trying to load ASM classes, but were seeing the ones embedded in the 3rd party ear.  I was trying to get wildfly to give the ASM jars that it provides a higher classloading precedence than the ones in the ear.  Normally, this is done by removing the jars from the deployment and adding a dependency via the jboss-deployment-structure.xml or MANIFEST.MF.  Since you don't have that option with the 3rd party software, creating a global module would achieve the same thing.  Global modules are provided to all deployments, without adding explicit dependencies to the deployment.  According to the link I sent you, visible modules have a higher precedence than local resources.  So, the ASM jars embedded within the ear are not being utilized at all.

In this particular case, it's probably safe.  If there is anything in the ear that is dependent on ASM besides the web service itself, you may have issues.  If it is only the web service, though, then chances are this won't cause other problems.  I can't guarantee it, but it's very probable.  Even if you have web service jars embedded in the ear (CXF, metro, etc.), as long as they implement the JAX-WS standard, then the wildfly jars will be given precedence.

In addition to the classloading link from earlier, you can check the following link out.  It describes what modules are, and how to use them, in much greater detail:

JBoss Modules: version 1.x