WSA35 and XSLT Class not found problem

[Sandy Mustard]

While testing a port of our application from WSAE 3.0.2.1 to WSAE 3.5, I
uncovered a XSL transformation problem. I received the following
traceback while attempting to display the output from my servlet.

[00.08.19 01:45:04:515 EDT] 9fa98512 ServletInstan X Uncaught service()
exception root cause {0}: {1}
"List"
java.lang.NoClassDefFoundError: org/apache/xerces/parsers/DOMParser
at java.lang.Class.forName1(Native Method)
at java.lang.Class.forName(Class.java:137)
at
org.apache.xalan.xslt.XSLTEngineImpl.<init>(XSLTEngineImpl.java:360)
at
org.apache.xalan.xslt.XSLTProcessorFactory.getProcessor(XSLTProcessorFactory.java:79)
at my._XSLParserWrapper.applyTransformation(_XSLParserWrapper.java:34)
at
my._XSLParserWrapper._applyTransformation(_XSLParserWrapper.java:21)
at my.servlet.BasicServletParams.output(BasicServletParams.java:146)
at my.servlet.BasicServlet.handleHttpRequest(BasicServlet.java:110)
at my.servlet.BasicServlet.doGet(BasicServlet.java:129)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:534)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:639)

Where would the org.apache.xerces.parsers.DOMParser be? In 3.0.2.1 and
in 3.5 we compiled with lotusxsl.jar in our classpath.

Sandy Mustard

[Ken Hygh]

Sandy,
I don't see it anywhere in the 3.5 stuff. Where did you get it to call?

Ken

[Sandy Mustard]

Here is the code for _XSLParserWrapper. As you can see, it just calls
for a new XSLProcessor() and this is where it fails according to the
traceback.

import com.lotus.xsl.*;
import java.io.*;
import org.xml.sax.SAXException;

public class _XSLParserWrapper
{
public _XSLParserWrapper() {}
public void applyTransformation(String xml, String xsl,
XSLTResultTarget target)
{
XSLProcessor xslp = new XSLProcessor(); // <-------
XSLTInputSource xmlsrc = new XSLTInputSource(new
ByteArrayUnputStream(xsl.getBytes()));
XSLTInputSource xslsrc = new XSLTInputSource(xsl);
xslp,process(xmlsrc, xslsrc, target);
}

// try/catches removed for clarity.

However, looking at the sources for XALAN 1.2. I find that
XSLProcessorFactory() returns a new XSLTEngineImpl which looks at the
Constants class and uses "org.apache.xalan.xpath.dtm.DTMLiaison". Where
does Xerces come into play?

Sandy

[Paige Vinall]

Xalan is the XSLT code (XML Style Language Transformation). Xerces is the XML parser. Xalan
uses Xerces to parse the XSLT templates, since XSL is valid XML. Both are available from
www.apache.org. Note that the Xalan download also includes xerces.jar so you only need to
download Xalan to get both pieces. But I don't know if this will solve your problem.

Paige Vinall

[Sandy Mustard]

This does not solve the problem.

If you look in websphere\appserver\lib you will see lotusxsl.jar,
xalan.jar and xml4j.jar. I assume websphere is still using xml4j for
its XML parser. There is no xerces.jar provided by websphere.

If i am able to compile my servlet/EJB with what is in the
websphere\appserver\lib directory, wouldn't it seem that it should be
able to run in websphere?

This may indicate a problem in that IBM has not provided everything
needed in its distribution.

Sandy Mustard

[Ken Hygh]

One comment below,
Ken

Sandy Mustard wrote:

> This does not solve the problem.
>
> If you look in websphere\appserver\lib you will see lotusxsl.jar,
> xalan.jar and xml4j.jar. I assume websphere is still using xml4j for
> its XML parser. There is no xerces.jar provided by websphere.
>
> If i am able to compile my servlet/EJB with what is in the
> websphere\appserver\lib directory, wouldn't it seem that it should be
> able to run in websphere?

Not necessarily. Notice in the trace that the code is loading the class at runtime (forName()), so
it would compile fine whether the named class exists or not.

[Sandy Mustard]

Granted if the code calls forName() it may not have everything at
execution time but it will still compile.

My complaint is that this call is in code provided by IBM and the class
is not available. It indicates either a product packaging problem and
that their testing of WAS functionality prior to shipment is incomplete.

I, of course, sent this problem in via the trial version support line
and they responded that this was outside of the scope of the trial
support.

Anyway, if I get my own copy of the latest versions of xalan.jar,
xerces.jar and xml4j.jar and place them at the head of the class path,
will it work? Will WAS blow up with these latest versions? I guess I
will try this tonight.

Sandy Mustard

[Sarav]

Hi Sandy,

I had the same error that you were experiencing and was following this discussion thread with some
interest.
I finaly have solved the problem and this is what I found out/did :

The lotusxsl.jsr file shipped with WAS3.5 is 73KB. I found another lotusxsl.jar in my WebSphere
Studio\lib directory that was of a different size. I replaced the old one with this. I had the following
jars in my classpath:
1. xml4j.jar
2. xerces.jar
3. xalan.jar
4. lotusxsl.jar

Pl Check this out and let me ( us) know if it works. Good Luck !
Sarav

[Hans Geurts]

Sandy, were you able to solve this problem?

regards,
Hans
"Sandy Mustard" <mus...@attglobal.net> wrote in message
news:399E4316...@attglobal.net...

[Sandy Mustard]

Yes, problem solved.

Thanks for everyone's help.

Sandy

[John T. Bell]

Could you elaborate? I know the problem was solved, but how? We would all
like to know.

Sandy Mustard wrote in message <3A454CC4...@cinci.rr.com>...