JDK-4626527 : JRE exposes JAXP private implementation at classpath
  • Type: Bug
  • Component: xml
  • Sub-Component: jaxp
  • Affected Version: 1.4.0_01
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2002-01-22
  • Updated: 2012-04-25
  • Resolved: 2002-11-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.2 mantisFixed
Description
JRE bundles abstract JAXP APIs including its implementation. Problem is that implementation is de facto at classpath. It causes problems when a user using JAXP rules plugs in its own implementation. It may clash with the implementation included with JRE 1.4.
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis FIXED IN: mantis INTEGRATED IN: mantis mantis-b08
14-06-2004
SUGGESTED FIX Rewrite platform default JAXP factories so they will load implementation using a private classloader. Then the implementation becomes invisible and can coexist with new versions plugged in by user. Another workaround at client side: The implementation user pluged can use isolator classloader, hidding the implementation at classpath.
11-06-2004
PUBLIC COMMENTS JAXP plugin compatability issue. == This problem would be fixed as part of Package renaming we are doing as part of Mantis ( J2SDK 1.4.2 ), for apache classes i.e changing org.apache.<product> to com.sun.org.apache.<product>.internal here product can be "xalan" , "xpath" or "xml" Users using the packages from apache would be having the package name as "org.apache.<product>", so there won't be any conflict because of class names. ###@###.### 2002-11-12
12-11-2002
EVALUATION This bug is not reproducable. I did the following: 1)Used Xerces2 in _classpath_ enviroment variable,Users own implementation for which the bug is filled. 2)Didn't specified user implementation (xerces,jar) in classpath then it use's the deafult parser _crimson_ bundled in rt.jar. With both settings, it worked fine. I also tried by overwriting the default classpath with the option *java -classpath blah blah*. It worked fine. I tried to reproduce the problem with JDK1.4 RC and with latest buid b_92 on Windows2000 and Solaris 2.8. But could not reproduce it. ###@###.### 2002-02-01 You cannot reprocude if you use parsers from different vendors. Try to compile Crimson (do some modification into it) ant then put this version at classpath. Classes from rt.jar are loaded instead. Another example is new jre/lib/endorsed directory usage. JAXP suggest to place parsers there but it then clashs with Xerces version at classpath. Some details can be found at http://www.netbeans.org/issues/show_bug.cgi?id=19682. There gets visible uncompatible parser version in endorsed instead one at classpath. ###@###.### 2002-10-29 I forgot to reopen :-(.
29-10-2002