xml-xalan-j-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henry Zongaro <zong...@ca.ibm.com>
Subject Re: Migration impact to Xalan-Java Version 2.7.0 from older version
Date Fri, 20 Jun 2008 13:36:34 GMT
Hi, Aniruddha.

Aniruddha- <jadhao.aniruddha@gmail.com> wrote on 2008-06-19 07:35:03 AM:
> We are planning to migrate from xalan older version to new that is  2.7 
> But as I added new xalan.jar in class path of the project in eclipse,
> suddenly project started showing errors of "could not resolve"
> -XSLTProcessor

Which version of Xalan are you migrating from?  The XSLTProcessor class 
was deprecated in Xalan-J 2.2.0 and was eventually removed from the binary 
distribution.  It did exist in the source repository right through to the 
Xalan-J 2.5.2 timeframe, and it was possible to build the class as part of 
a Xalan-J 1.0 compatibility jar.

That particular class existed before the JAXP Transform API came into 
existence; once the Transform API became available, XSLTProcessor was 
redundant.  See [1] for more information on the transform API.

> -MutableNodeListImpl
> -NodeListImpl
> More over I learnt that org.apache.xalan.xpath package structure itself 
> been changed in new xalan.jar.

I don't really know the history of the MutableNodeListImpl and 
NodeListImpl classes, nor do I know much about the structure of the 
org.apache.xalan.xpath package.  I do know that some classes in 
org.apache.xalan.xpath were preserved in the source repository until the 
Xalan-J 2.5.2 timeframe, and as with XSLTProcessor, it was possible to 
build them as part of a Xalan-J 1.0 compatibility jar.  Perhaps somebody 
else can say what become of MutableNodeListImpl and NodeListImpl.

> Can any one please kindly address my following ques..
> -didnt apache-xalan group thought of backword compatibility before 
> the dir struicture?

Certainly some consideration was given to this kind of backward 
compatibility.  As I mentioned, some compatibility classes were made 
available for several years after they were removed from the standard 
binary distributions.  Since then, the project has adopted the formal 
policy described in [2].  The policy divides the classes of the Xalan-J 
into three categories:  the public, experimental and private APIs.  The 
public APIs are those that users can rely upon in the long-term, but even 
there there's always the possibility for incompatible evolutionary 

> -are there any alternative classes that will replace the above listed
> classes?
> -what steps do I need to take to accomodate my applicaion with new
> xalan.jar?

As I mentioned, [1] will describe how to eliminate your dependence on the 
XSLTProcessor class.  As for MutableNodeListImpl and NodeListImpl, I think 
I'd need to see examples of how you're using them in order to make any 
useful suggestions about alternatives.


[1] http://xml.apache.org/xalan-j/trax.html
[2] http://xml.apache.org/xalan-j/public_apis.html
Henry Zongaro
XML Transformation & Query Development
IBM Toronto Lab   T/L 313-6044;  Phone +1 905 413-6044

View raw message