Resolving WildFly XML Input Factory Errors

Encountering errors in application servers like WildFly can be a common hurdle for Java developers. Among the various issues, javax.xml.stream.FactoryConfigurationError related to XMLInputFactory is a particularly cryptic one that often surfaces during deployment or application startup. This error, as exemplified in the stack trace below, indicates a problem in instantiating the XML input factory, hindering XML processing within your WildFly environment.

Exception in thread “main” javax.xml.stream.FactoryConfigurationError: Provider com.sun.xml.internal.stream.XMLInputFactoryImpl could not be instantiated: java.lang.reflect.InvocationTargetException at java.xml/javax.xml.stream.FactoryFinder.newInstance(FactoryFinder.java:201) at java.xml/javax.xml.stream.FactoryFinder.newInstance(FactoryFinder.java:148) at java.xml/javax.xml.stream.FactoryFinder.find(FactoryFinder.java:326) at java.xml/javax.xml.stream.FactoryFinder.find(FactoryFinder.java:223) at java.xml/javax.xml.stream.XMLInputFactory.newInstance(XMLInputFactory.java:166) at __redirected.__XMLInputFactory.(__XMLInputFactory.java:66) at __redirected.__JAXPRedirected.initAll(__JAXPRedirected.java:77) at org.jboss.modules.Module$1.run(Module.java:132) at org.jboss.modules.Module$1.run(Module.java:119) at java.base/java.security.AccessController.doPrivileged(AccessController.java:318) at org.jboss.modules.Module.(Module.java:119) at org.jboss.modules.Main.main(Main.java:385) Caused by: java.lang.reflect.InvocationTargetException at java.base/jdk.internal.reflect.DirectConstructorHandleAccessor.newInstance(DirectConstructorHandleAccessor.java:79) at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499) at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:483) at java.xml/javax.xml.stream.FactoryFinder.newInstance(FactoryFinder.java:190) … 11 more Caused by: javax.xml.parsers.FactoryConfigurationError: Provider __redirected.__SAXParserFactory could not be instantiated: java.lang.reflect.InvocationTargetException at java.xml/javax.xml.parsers.FactoryFinder.newInstance(FactoryFinder.java:199) at java.xml/javax.xml.parsers.FactoryFinder.newInstance(FactoryFinder.java:147) at java.xml/javax.xml.parsers.FactoryFinder.find(FactoryFinder.java:227) at java.xml/javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java:181) at java.xml/jdk.xml.internal.JdkXmlUtils.getSAXFactory(JdkXmlUtils.java:351) at java.xml/jdk.xml.internal.JdkXmlUtils.(JdkXmlUtils.java:88) at java.xml/com.sun.org.apache.xerces.internal.impl.PropertyManager.initConfigurableReaderProperties(PropertyManager.java:144) at java.xml/com.sun.org.apache.xerces.internal.impl.PropertyManager.(PropertyManager.java:78) at java.xml/com.sun.xml.internal.stream.XMLInputFactoryImpl.(XMLInputFactoryImpl.java:51) at java.base/jdk.internal.reflect.DirectConstructorHandleAccessor.newInstance(DirectConstructorHandleAccessor.java:67) … 14 more Caused by: java.lang.reflect.InvocationTargetException at java.base/jdk.internal.reflect.DirectConstructorHandleAccessor.newInstance(DirectConstructorHandleAccessor.java:79) at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499) at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:483) at java.xml/javax.xml.parsers.FactoryFinder.newInstance(FactoryFinder.java:188) … 23 more Caused by: java.lang.IllegalAccessError: class __redirected.__SAXParserFactory cannot access class com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl (in module java.xml) because module java.xml does not export com.sun.org.apache.xerces.internal.jaxp to unnamed module @7dc5e7b4 at java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:394) at java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674) at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:492) at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:483) at __redirected.__SAXParserFactory.(__SAXParserFactory.java:106) at java.base/jdk.internal.reflect.DirectConstructorHandleAccessor.newInstance(DirectConstructorHandleAccessor.java:67) … 26 more

This guide aims to demystify this error, explain its root cause in the context of WildFly, and provide effective solutions to resolve it, ensuring your applications run smoothly.

Understanding the FactoryConfigurationError

The FactoryConfigurationError in Java generally arises when the system is unable to locate or instantiate a factory class needed for XML processing. In this specific scenario, the error message points towards issues with com.sun.xml.internal.stream.XMLInputFactoryImpl and __redirected.__SAXParserFactory. These are classes involved in handling XML input and parsing.

The stack trace clearly indicates a chain of exceptions, with the ultimate cause being java.lang.IllegalAccessError. This IllegalAccessError is crucial for understanding the problem in modern Java environments, especially those running on Java 9 and later, and within module-based application servers like WildFly.

Root Cause: IllegalAccessError and Java Module System

The core of the problem lies within the Java Module System introduced in Java 9. Modules enforce strong encapsulation, controlling access between different parts of the application and the Java runtime environment. The error message “module java.xml does not export com.sun.org.apache.xerces.internal.jaxp to unnamed module” is the key.

Here’s a breakdown:

• java.xml Module: This is a standard Java module that provides XML processing functionalities.
• com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl: This class, and similar internal JAXP classes, are part of the internal implementation of the java.xml module. By default, these internal implementation classes are not exported by the java.xml module.
• “unnamed module”: This refers to the classpath, where your application code and some libraries might be running if not explicitly placed within a named module.

In essence, your application, running in an “unnamed module” within WildFly, is trying to access internal classes of the java.xml module (com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl) which are not intended for external use and are not exported. This access restriction is enforced by the Java Module System, leading to the IllegalAccessError and subsequently the FactoryConfigurationError.

WildFly Context: Modules and Classloading

WildFly, being a modular application server, leverages the Java Module System extensively. It organizes its functionalities and deployed applications into modules. While this modularity provides benefits like isolation and dependency management, it also means you need to be mindful of module dependencies.

In the context of this XML error, WildFly’s module classloading mechanisms are at play. When your application attempts to use XML processing, it relies on the JAXP (Java API for XML Processing) implementation provided by the underlying Java runtime, which is encapsulated within the java.xml module.

The error occurs because the default module configuration in WildFly, or potentially your application’s deployment configuration, is not explicitly declaring the necessary dependencies to allow access to the internal XML implementation when needed in certain scenarios.

Solutions and Workarounds

To resolve this FactoryConfigurationError in WildFly, you need to explicitly declare a module dependency, allowing your application to properly access the required XML processing classes. The most recommended approach is to configure module dependencies within your deployment descriptor.

1. Explicit Module Dependency in jboss-deployment-structure.xml

The recommended and cleanest solution is to declare a dependency on the java.xml module within your application’s deployment descriptor, jboss-deployment-structure.xml. This file allows you to fine-tune module dependencies for your deployments in WildFly.

If your application doesn’t already have a jboss-deployment-structure.xml, create one in the WEB-INF directory of your WAR file or at the root of your EAR file. Then, add the following configuration:

<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
    <deployment>
        <dependencies>
            <module name="java.xml"/>
        </dependencies>
    </deployment>
</jboss-deployment-structure>

This configuration explicitly tells WildFly that your deployment requires the java.xml module and its exported packages. By adding this dependency, you grant your application the necessary access to the XML processing classes, resolving the IllegalAccessError and the subsequent FactoryConfigurationError.

After adding this file, redeploy your application. WildFly will now ensure that your deployment has the correct module dependency, and the XML input factory should be instantiated without issues.

2. Reviewing Dependencies (Less Common)

In some rare cases, conflicts with other XML libraries included in your application’s dependencies might contribute to such errors. While the IllegalAccessError points strongly towards module visibility, it’s worth briefly reviewing your project’s dependencies.

Ensure you don’t have conflicting or outdated XML processing libraries bundled within your application that might be interfering with WildFly’s default XML handling. In most scenarios related to this specific error, the module dependency solution is the primary fix, rather than dependency conflicts.

Preventative Measures

While resolving the error is crucial, preventing it in the future is even better. Here are a few preventative measures:

• Understand WildFly Modules: Familiarize yourself with WildFly’s modular architecture and how it handles dependencies. Understanding modules is key to avoiding classloading and dependency-related issues.
• Use jboss-deployment-structure.xml Proactively: For applications that rely on Java EE or standard Java APIs, consider proactively using jboss-deployment-structure.xml to declare module dependencies, even if you don’t encounter errors initially. This can prevent unexpected issues in different environments or WildFly versions.
• Test Deployments Thoroughly: Always test your deployments in a WildFly environment that mirrors your production setup as closely as possible. Early detection of such errors in testing phases saves time and prevents production outages.

Conclusion

The javax.xml.stream.FactoryConfigurationError in WildFly, often caused by java.lang.IllegalAccessError, is a manifestation of Java’s module system enforcing access restrictions. By understanding that the root cause is the lack of explicit module dependency on java.xml, you can effectively resolve this issue by configuring jboss-deployment-structure.xml.

By correctly declaring module dependencies and understanding WildFly’s modularity, you can ensure smooth deployments and prevent common classloading errors, leading to more robust and maintainable Java applications on WildFly. Remember to always prioritize clear module dependency declarations for applications running on modular application servers to avoid similar issues related to internal API access in the future.