JAXP compatibility issues due to different Websphere 7 iterations

Websphere 7 Small version of the difference caused by JAXP compatibility issues

 

Java, EE, Web, XML, Xerces, Websphere , Application Server, JAXP

 

Developers who develop Java EE applications have met more or less incompatible issues, summing up, the most likely compatibility is nothing more than the log (common logging, log4j) and XML parsing (jaxp/xerces), Because these two components are so common that almost all enterprise-class components rely directly or indirectly on them, compatibility issues inevitably arise when our web application relies too much on something. Many Web applications can run normally on Tomcat and JBoss, but cannot be used on one, mostly because there are different versions of dependencies in the classpath, and different components rely on different versions, causing problems. I would like to say a few words about the recent colleagues to solve the problem of compatibility issues, for everyone to solve similar problems in providing some ideas:

phenomenon: The same application, the war package does not make changes, on the WAS7.0.0.9 can be normal, but on the 7.0.0.12 to cause application startup error, the exception is a certain JAXP class (as if node) missing a method definition.

Place of Doubt: A minor version of is also incompatible, which was not previously seen before, when the Tomcat application was ported to was, and because was also provided JAXP-related packages, the package version was too low to be compatible, initially by changing IBM The jaxp.properties below the JRE resolves that the JAXP implementation changes to the implementation that we need, but this time the file changes regardless, or the same error occurs.

suspect point: still suspect that there are two different versions of JAXP in the production environment, but the implementation is already specified, why is there a problem? Moreover, there were only a few minor changes in the version of was, so why would there be such a big problem? Another point, was just installed, did not make any changes to it, and eventually locked the suspect point on the war package we provided.

process: Looking for a problematic class in the development environment, and sure enough to find two versions of JAXP, one of which has the interface, one without that interface, they were named: Xml-apis.jar, Xmlapis.jar, but it's actually a JAXP interface package that developers automatically add through Maven as a result of introducing third-party components. Remove the lower version of the package, and then deploy, the problem is resolved.

Follow-up: If the package is removed causing problems with other components of the third party, there is no way to replace that Third-party component version so that it is compatible with our current JAXP.

Original: when there are multiple versions of classes in the Classpath, the first load of which class is unpredictable, for different JRE, file structure and so on may not be the same, in this case, 7.0.0.9 loaded with a high version of the class, The lower version of the class is loaded on the 7.0.0.12, causing the problem.