Hi, Aniruddha. Aniruddha- <[EMAIL PROTECTED]> 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 has > 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 changing > 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 changes. > -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. Thanks, Henry [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 mailto:[EMAIL PROTECTED]
