org.apache.xalan.processor.TransformerFactoryImpl Not Found

APPLIES TO:

Oracle WebLogic Server - Version 10.3.6 and later
Information in this document applies to any platform.

SYMPTOMS

After successfully deploying an application to the domain and bringing it to ACTIVE mode, subsequent changes in the admin console fail with the following error:

The prepare phase of the configuration update failed with an exception:
  at weblogic.management.provider.internal.RuntimeAccessDeploymentReceiverService.updateDeploymentContext(RuntimeAccessDeploymentReceiverService.java:670)
.....
Caused by: javax.xml.transform.TransformerFactoryConfigurationError: Provider org.apache.xalan.processor.TransformerFactoryImpl not found

CAUSE

The deployed application changes a system property like so:

javax.xml.transform.TransformerFactory=org.apache.xalan.processor.TransformerFactoryImpl

At some point in the application code, a call is made to -- see http://docs.oracle.com/javase/7/docs/api/java/lang/System.html#setProperty%28java.lang.String,%20java.lang.String%29 for the Java SE 7 documentation on this method. So in this case, it would take the system property named "javax.xml.transform.TransformerFactory" and assign the value "org.apache.xalan.processor.TransformerFactoryImpl" to it. applies across the entire JVM, not just within the application, and that's why it ends up impacting the console app as well.System.setProperty(String key, String value)System.setProperty

The application has the xalan jar file in its lib directory, so it's able to deploy and activate without any problems, and it works fine. However, that changes the value for this property for the entire system, not just for the application. The console app doesn't have access to the Apache-specific Xalan class and that's why it throws the error that it cannot find it.

Generally speaking, any methods in the Java package will apply to the entire JVM, and they can cause problems if they change the state or properties of the entire JVM. Another example of the same problem is calling -- this will exit not only the current application, but the entire application server as well.SystemSystem.exit()

SOLUTION

Refactor your code so that you do not call . If the property is set only within the context of the application rather than JVM-wide, you won't see this problem.System.setProperty()

It is possible to work around the problem by adding the jar file containing the missing classes to the DOMAIN_HOME/lib directory. The DOMAIN_HOME/lib directory uses a special classloader which is a child of the system classloader and a parent of the application classloader. So classes in jar files in that directory are not available to the system as a whole, but are available to any applications running in that system, including both your applications and the WLS console application. However, there is a risk that you may break other apps in the system (like the console app) if they rely on a particular setting for the system property that the application is changing.

Therefore, the best solution is to avoid setting a property which applies to the entire JVM rather than to the application where it is actually needed. Refactoring the application code to avoid using will solve the issue.System.setProperty()

Please note that anytime that the application code is changed, it has to be redeployed, and any time a system property has been changed, that system property remains in effect until changed again or until a reboot. So a reboot is advisable when changing system properties to return to a clean environment.