Crimson is the XML parser that ships with Tomcat. If you've done nothing to
the Tomcat classpath or to the environment to coerce JAXP into loading the
Xerces parser, it is the parser that will be used by Apache SOAP. It is not
clear to me in the Tomcat 4 beta 6 I downloaded which version of Crimson is
included. It is disconcerting to me that the version for "server/lib" is a
different size than the version for "jasper/lib". Normally, I would suggest
trying a particular version of Crimson (1.1.1 works like a charm for me with
Tomcat 3.x and JRun) or trying Xerces instead, but since you said you ran
successfully on NT and Linux, that probably does not make sense.
Scott
----- Original Message -----
From: "David Turner" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, July 26, 2001 1:47 PM
Subject: Re: Parsing error...
> Scott,
>
> Here's a little more info on this issue that I'm running into. I've
tracked
> this down to a line in RPCMessage.unmarshall() method:
>
> Bean paramBean = smr.unmarshall(actualParamEncStyle,
> RPCConstants.Q_ELEM_PARAMETER,
> tempEl, ctx);
>
> As you can see from the stack trace I haven't gone down far enough, but I
wanted
> to point one thing out and that is the second line of the stack trace.
Notice
> the package "org.apache.crimson.tree.ElementNode...". Does this look like
it's
> picking up the ElmentNode class from the wrong package? I may be grasping
at
> straws here, but I wanted your input on this one.
>
> Thanks.
>
>
> java.lang.NullPointerException
> at
> org.apache.crimson.tree.ElementNode.getAttributeNodeNS(ElementNode.java,
> Compiled Code)
> at org.apache.soap.util.xml.DOMUtils.getAttributeNS(DOMUtils.java,
> Compiled Code)
> at
> org.apache.soap.util.xml.DOMUtils.getNamespaceURIFromPrefix(DOMUtils.java,
> Compiled Code)
> at
>
org.apache.soap.encoding.soapenc.SoapEncUtils.getAttributeValue(SoapEncUtils
.java,
> Compiled Code)
> at
>
org.apache.soap.encoding.soapenc.SoapEncUtils.getTypeQName(SoapEncUtils.java
,
> Compiled Code)
> at
>
org.apache.soap.encoding.soapenc.ParameterSerializer.unmarshall(ParameterSer
ializer.java,
> Compiled Code)
> at
>
org.apache.soap.util.xml.XMLJavaMappingRegistry.unmarshall(XMLJavaMappingReg
istry.java,
> Compiled Code)
> at org.apache.soap.rpc.RPCMessage.unmarshall(RPCMessage.java,
Compiled
> Code)
> at
org.apache.soap.rpc.RPCMessage.extractFromEnvelope(RPCMessage.java,
> Compiled Code)
> at org.apache.soap.rpc.Call.extractFromEnvelope(Call.java,
Compiled
> Code)
> at
> org.apache.soap.server.RPCRouter.extractCallFromEnvelope(RPCRouter.java,
> Compiled Code)
> at
> org.apache.soap.server.http.RPCRouterServlet.doPost(RPCRouterServlet.java,
> Compiled Code)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java,
Compiled
> Code)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java,
Compiled
> Code)
> at
>
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
ain.java,
> Compiled Code)
> at
>
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja
va,
> Compiled Code)
> at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java,
> Compiled Code)
> at
>
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja
va,
> Compiled Code)
> at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java,
> Compiled Code)
> at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java,
> Compiled Code)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java,
> Compiled Code)
> at org.apache.catalina.valves.ValveBase.invokeNext(ValveBase.java,
> Compiled Code)
> at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java,
> Compiled Code)
> at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java,
> Compiled Code)
> at
>
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java
,
> Compiled Code)
> at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java,
> Compiled Code)
> at
>
org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java,
> Compiled Code)
> at
> org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java,
> Compiled Code)
> at java.lang.Thread.run(Thread.java:484)
>
>
> Scott Nichol wrote:
>
> > Sorry that I missed the fact your error was trying to deploy the
services,
> > not run them. I'll try installing Tomcat 4 if I get the chance today or
> > tomorrow.
> >
> > Scott
> >
> > ----- Original Message -----
> > From: "David Turner" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Thursday, July 26, 2001 10:01 AM
> > Subject: Re: Parsing error...
> >
> > > Hi Scott,
> > > I'm using tomcat 4.0 on a Tru64 machine. I can't run my stuff or the
> > samples
> > > because the problem I described occurs when deploying the services.
> > >
> > > Scott Nichol wrote:
> > >
> > > > You've done some thorough investigating, but I am curious whether
the
> > > > samples work.
> > > >
> > > > What servlet container are you using? I have access to a Tru64
machine
> > > > running 4.0E (yours looks like 4.0G or so) and could possibly
compare
> > any
> > > > findings regarding the samples if you are running Tomcat.
> > > >
> > > > Scott
> > > >
> > > > ----- Original Message -----
> > > > From: "David Turner" <[EMAIL PROTECTED]>
> > > > To: <[EMAIL PROTECTED]>
> > > > Sent: Wednesday, July 25, 2001 3:36 PM
> > > > Subject: Parsing error...
> > > >
> > > > > I've been battling with a "SOAPException-Parsing error" for quite
some
> > > > > time now when trying to deploy a simple service, and I've resorted
to
> > > > > debugging the SOAP code to search out the problem. I've managed
to
> > get
> > > > > my service up and running on both Windows and Linux, but the one
> > > > > platform that I need it on doesn't work and gives me the above
> > mentioned
> > > > > error.
> > > > >
> > > > > When I issue a uname command on the unix system the following
system
> > > > > info is displayed: (informational only)
> > > > > OSF1 darwin.wi.mit.edu V4.0 1229 alpha alpha
> > > > >
> > > > > I thoroughly check all possible places for any parser conficts,
but
> > > > > didn't find any that I know of.
> > > > >
> > > > > Using TCP Tunnel Monitor I know a good soap envelope was sent, but
> > what
> > > > > I get back is a Internal Server Error with an incomplete SOAP
envelope
> > > > > for the fault. During debugging I found that a
NullPointerException
> > was
> > > > > thrown when trying to extract the Call from the Envelope, which
would
> > > > > account for the Fault being sent back in the first place. Still
> > trying
> > > > > to determine why the NullPointerException was thrown -- need
further
> > > > > debugging on that one.
> > > > >
> > > > > I checked the response in the RPCRouterServlet to see what was
being
> > > > > sent back and it was a complete SOAP envelope that contained the
> > Fault.
> > > > > What I don't get, and is probably the cause of the parsing error,
is
> > the
> > > > > fact the TCPTunnelMonitor is showing an incomplete SOAP envelope.
> > > > > Looking at TCPTunnelMonitor I'm losing data in the response.
> > > > >
> > > > > Has anybody run into this? Any ideas? Need help!
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > David Turner <[EMAIL PROTECTED]>
> > > > > Senior Software Engineer
> > > > > Whitehead Institute/MIT Center for Genome Research
> > > > > One Kendall Square, Bldg. 300
> > > > > Cambridge, MA 02139-1561 USA
> > > > > phone 617-252-1573 / fax 617-252-1902
> > > > >
> > > > >
> > > > >
> > >
> > > --
> > > David Turner <[EMAIL PROTECTED]>
> > > Senior Software Engineer
> > > Whitehead Institute/MIT Center for Genome Research
> > > One Kendall Square, Bldg. 300
> > > Cambridge, MA 02139-1561 USA
> > > phone 617-252-1573 / fax 617-252-1902
> > >
> > >
>
> --
> David Turner <[EMAIL PROTECTED]>
> Senior Software Engineer
> Whitehead Institute/MIT Center for Genome Research
> One Kendall Square, Bldg. 300
> Cambridge, MA 02139-1561 USA
> phone 617-252-1573 / fax 617-252-1902
>
>
>
