EAP deployment stalls and throws warning when validating beans.xml

Solution Verified - Updated 7 Aug 2024

Environment

Red Hat JBoss Enterprise Application Platform (EAP)
- 6.x
- 7.x

Issue

We have a war file, which has our web service, as part of the ear file, and the deployment hangs on parsing the beans.xml as shown below in my server.log:

        11:56:03,408 DEBUG [org.jboss.weld] (MSC service thread 1-8) Found beans.xml: "/content/example-ear.ear/example.war/WEB-INF/beans.xml"
        ...
        11:59:13,230 WARN  [org.jboss.weld.Bootstrap] (MSC service thread 1-8) WELD-001208 Warning when validating vfs:/content/example-ear.ear/example.war/WEB-INF/beans.xml@7 against xsd. schema_reference.4: Failed to read schema document 'http://www.springframework.org/schema/beans/spring-beans.xsd', because 1) could not find the document; 2) the document could not be read; 3) the root element of the document is not <xsd:schema>.

Our application deployment slows down significantly validating its beans.xml; the thread dump shows the following:

"MSC service thread 1-2" prio=10 tid=0x0000000008533800 nid=0x5f2 runnable [0x00002b43ff56f000]
   java.lang.Thread.State: RUNNABLE
	at java.net.PlainSocketImpl.socketConnect(Native Method)
	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
	- locked <0x00000000f753ed98> (a java.net.SocksSocketImpl)
	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391)
	at java.net.Socket.connect(Socket.java:579)
	at java.net.Socket.connect(Socket.java:528)
	at sun.net.NetworkClient.doConnect(NetworkClient.java:180)
	at sun.net.www.http.HttpClient.openServer(HttpClient.java:378)
	at sun.net.www.http.HttpClient.openServer(HttpClient.java:473)
	- locked <0x00000000f753ed10> (a sun.net.www.http.HttpClient)
	at sun.net.www.http.HttpClient.<init>(HttpClient.java:203)
	at sun.net.www.http.HttpClient.New(HttpClient.java:290)
	at sun.net.www.http.HttpClient.New(HttpClient.java:306)
	at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:995)
	at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:931)
	at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:849)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1299)
	- locked <0x00000000f753e328> (a sun.net.www.protocol.http.HttpURLConnection)
	at org.apache.xerces.impl.XMLEntityManager.setupCurrentEntity(Unknown Source)
	at org.apache.xerces.impl.XMLVersionDetector.determineDocVersion(Unknown Source)
	at org.apache.xerces.impl.xs.opti.SchemaParsingConfig.parse(Unknown Source)
	at org.apache.xerces.impl.xs.opti.SchemaParsingConfig.parse(Unknown Source)
	at org.apache.xerces.impl.xs.opti.SchemaDOMParser.parse(Unknown Source)
	at org.apache.xerces.impl.xs.traversers.XSDHandler.getSchemaDocument(Unknown Source)
	at org.apache.xerces.impl.xs.traversers.XSDHandler.parseSchema(Unknown Source)
	at org.apache.xerces.impl.xs.XMLSchemaLoader.loadSchema(Unknown Source)
	at org.apache.xerces.impl.xs.XMLSchemaValidator.findSchemaGrammar(Unknown Source)
	at org.apache.xerces.impl.xs.XMLSchemaValidator.handleStartElement(Unknown Source)
	at org.apache.xerces.impl.xs.XMLSchemaValidator.emptyElement(Unknown Source)
	at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
	at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
	at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
	at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
	at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
	at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
	at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
	at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
	at org.apache.xerces.jaxp.SAXParserImpl.parse(Unknown Source)
	at org.jboss.as.weld.deployment.BeansXmlParser.parse(BeansXmlParser.java:95)
	at org.jboss.as.weld.deployment.processors.BeansXmlProcessor.parseBeansXml(BeansXmlProcessor.java:134)
	at org.jboss.as.weld.deployment.processors.BeansXmlProcessor.deploy(BeansXmlProcessor.java:98)
	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:116)
	- locked <0x00000000e0872930> (a org.jboss.as.server.deployment.DeploymentUnitPhaseService)
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
	at java.lang.Thread.run(Thread.java:722)

Resolution

Rename the beans.xml to another name such as spring-beans.xml or applicationContext.xml, since J2EE 6 includes the Contexts and Dependency Injection (CDI) framework which looks for beans.xml configuration files.
If not using CDI/Weld, disable/remove the weld subsystem as a workaround to avoid any such parsing/validation slowdown. To do this, create a file named jboss-deployment-structure.xml with the following content and place it in WEB-INF directory of your WAR deployment:

<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
    <deployment>
        <exclude-subsystems>
            <subsystem name="weld" />
        </exclude-subsystems>
    </deployment>
</jboss-deployment-structure>

If you are using EAR, remember to place this file in META-INF directory and exclude the weld subsystem for the sub-deployment you want to disable it.
As a workaround, disable the 'beans.xml' validation by setting the System Property in your JVM options:

  -Dorg.jboss.weld.xml.disableValidating=true

Root Cause

The beans.xml is a Spring Framework configuration file, however J2EE 6 expects it to be a CDI configuration file.
Weld will try to validate this xml, connecting to the xsd host to do so. If that host is unreachable (due to firewall, DMZ, etc.), deployment can stall for some time on the connection attempt.

SBR

Product(s)

Red Hat JBoss Enterprise Application Platform

Components

Category

Troubleshoot

Tags

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.