|Subject:||Re: Migration from JWSDP 1.3 to JWSDP 1.4|
|From:||Farrukh Najmi (Farr...@Sun.COM)|
|Date:||Jul 1, 2004 1:02:42 pm|
Thanks Ramesh for the detailed answers. I think they would make excellent fodder for the FAQ and the rationale makes good sense.
Ramesh Babu Mandava wrote:
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
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
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?
Maybe ramesh could help you with the specifics? We should capture the response somewhere in the JWSDP web site.
Farrukh Najmi wrote:
Eduardo Pelegri-Llopart wrote:
The situation with JAXP is probably the clearest. JAXP is the JCP-standard for XML processing. If developers program against
API their applications will work regardless of how JAXP is implemented. On the other hand, some developers want to
include dependencies on Xerces or Xalan and sometimes on a
version of Xerces or Xalan.
The previous arrangement - using the packages from ASF - was not
satisfactory. We had developers who unintentionally were adding dependencies on Xerces and Xalan, and, on the other side, those
really wanted a specific version of Xerces and Xalan had to do
loader magic to avoid conflicts with our packages. The new arrangement works better: most people just use JAXP, but those
care can easily include the version of Xerces and Xalan that
My project is in the category that wants to just use JAXP and
APIs where ever possible.
So if I want to use standard JAXP API with the implementation
by JWSDP 1.4, I assume that my client needs the jaxp-api.jar at
time, while the JWSDP 1.4 impl of jaxp-api.jar requires the jars
the jwsdp-1.4/jaxp/lib/endorsed dir.
Are there any docs showing best practices of how projects that
re-distributing JWSDP 1.4 components set up the compile and run
A similar arrangement happens with the XML security classes.
would like is to have the "standard" / supported APIs be good
In this case it would be the JSR 105 / 106 APIs from the JCP
moving along nicely, but 106 is not, sorry - we have limited
to accelerate that), plus that XWS APIs (XWS is not a JCP
but when the APIs go final it will be a Sun-supported API). If
APIs are not good enough for your task we want to know, to see
can be improved. Alternatively, you can include the ASF classes
wire in a dependency on that implementation in your application.
Those are your options, although we would prefer to see people
standard APIs as that gives more flexiblilty with the
Hope this helps,
This was very helpful indeed. Thanks.
Farrukh Najmi wrote:
I have just started migrating the open source freebXML Registry project (see link in signature) from JWSDP 1.3 to JWSDP 1.4. I am finding that the xmlsec.jar file has been modified such
package names are now pre-fixed by com.sun.
This is causing the existing code to break at compile time. I
similar phenomena with several other jars from JWSDP 1.4.
Can someone shed some light on the issue?
-How are existing code bases supposed to migrate to JWSDP 1.4?
-If I revert back my xmlsec.jar to the standard Apache
assume that JWSDP 1.4 jars would not work - correct?
What are my options? Thanks.
-- Regards, Farrukh
-------------------------------------------------------- Going to Java One 2004 June 28 - July 1?
Come see the newly released freebXML Registry 3.0 at pod 1220 in the Java One Pavilion: