United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-4626527 JRE exposes JAXP private implementation at classpath
JDK-4626527 : JRE exposes JAXP private implementation at classpath

Details
Type:
Bug
Submit Date:
2002-01-22
Status:
Resolved
Updated Date:
2012-04-25
Project Name:
JDK
Resolved Date:
2002-11-18
Component:
xml
OS:
linux
Sub-Component:
jaxp
CPU:
x86
Priority:
P2
Resolution:
Fixed
Affected Versions:
1.4.0_01
Fixed Versions:
1.4.2 (mantis)

Related Reports
Backport:

Sub Tasks

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
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 :-(.
                                     
2002-10-29
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
                                     
2002-11-12
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.
                                     
2004-06-11
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
mantis

FIXED IN:
mantis

INTEGRATED IN:
mantis
mantis-b08


                                     
2004-06-14



Hardware and Software, Engineered to Work Together