Hi Eduardo:

Thanks for taking the first stab at the question. You already provided most of the details. Let me add few more details in Q&A
format.

1) Why we did package renaming of JAXP implementation jars ( xercesImpl.jar &
xalan.jar ) and xmlsec.jar as part of JWSDP 1.4?

JAXP implementation of Java WSDP 1.4 uses Xerces as the parser and Xalan as the
Transformer. Xalan is also used as as part of J2SE 1.4 for providing XML
Transformation functionality that is exposed through standard JAXP API. Xerces and Xalan are the Apache projects that are getting developed at Apache.
Sun engineers along with IBM and other Apache commiters work on these projects. i) One of the more frequently asked question in different mailining lists is
how to override/upgrade Xalan that is part of J2SE 1.4.X. Users are trying to do this either to have any
new bugfix or for getting any additional functionality that is added in later
versions of Xalan at Apache. As we used same "org.apache" package name for Xalan in J2SE 1.4.X and as the ClassLoader
mechanism of Java gives preference to the classes loaded from the JDK VM itself,
Xalan classes in JDK would be picked up ahead of any xalan.jar that is in the
CLASSPATH ( irrespective of where this is in CLASSPATH ). The only way for users to override Xalan classes in JDK 1.4.X is to use Java
endorsed mechanism. Java endorsed mechanism is not a well understood concept and
using this also opens up some security holes. By doing package renaming for the JAXP implementation classes, users can
place these package renamed jars in CLASSPATH and get the updated
functinality/bugfixes without the need to use Java Endorsed mechanism.

ii) Because of incompatibilities between the different versions of Xerces and
Xalan with what we used in JWSDP, when user puts the different( older or updated
) versions of Xerces or Xalan jars ( in some cases non-intentionally ) in the
CLASSPATH ( or uses Java endorsed mechanism to use these jars ), then that is
breaking the functionality of some of JWSDP components. Doing the package
renaming of Xerces and Xalan classes and explicitly using these package renamed
classes in different JWSDP components we isolated the JWSDP components from the
upgrades of Xerces and Xalan by user.

iii) Package renaming of Xerces and Xalan would allow users to use the updated
Xerces and Xalan from Apache ( if they choose) without interfering the
functionality provided by JWSDP components.

Because of the above 3 reasons we did rename "org.apache.<subPackage>.*" package
name to "com.sun.org.apache.<subPackage>.*" while using Xerces and Xalan as part
of JWSDP.

Following the same lead, we also renamed the classes in "xmlsec.jar", which are
used by XWSS ( XML and WebServices Security ) component of JWSDP 1.4.

2) What do developers need to do if they explicitly import or use the fully
qualified name for "org.apache.*" pacakges ( or classes ) while using Xerces,
Xalan or xmlsec.jar?

Users can APPEND the non-package renamed jar files at the end of their
CLASSPATH. This should be sufficient for using these applications. Note: You need to make sure that package-renamed jars comes before these
non-package renamed jars, if you still want to use the classes in
package-renamed jars in cases where standard JAXP API is used.

3) Do I need to have any Xerces or Xalan jars available ( in CLASSPATH) at
Compile time if I use only standard JAXP API?

NO. You don't need to put xercesImpl.jar or xalan.jar in CLASSPATH if you use
only standard JAXP API. You may need to have "dom.jar" and "sax.jar" in CLASSPATH though.

4) If I am running standalone Java application using JWSDP 1.4 technologies such
as SAAJ, do I need to have the JAXP implementation classes from JWSDP 1.4 in
CLASSPATH? Is it not sufficient to use JAXP from JDK 1.4.X.

As explained in question 1 above, SAAJ and other JWSDP 1.4 components explicitly
uses the package renamed JAXP implementation classes that are part of JWSDP 1.4.
So you need to make these JAXP implementation jar files ( xercesImpl.jar &
xalan.jar in JWSDP 1.4) available in CLASSPATH for running your application.

We can put these Q&A as part of the FAQ.

Farrukh: Please let me know if you think it is better to clarify anything else
as part of the FAQ?

Regards -Ramesh