I checked the code. Since you have an absolute path, there should be no
getRealPath() conversion. If the files are in the right place, it seems
to me this should work.
Did you deploy a war or did you explode the war yourself?
Scott Nichol
- Original Message -
From: "Scott Nichol" <[EMA
My guess: the file names in web.xml and soap.xml passed through
getRealPath, so try leaving off the start of the file path
(/export/enterprise-docs/riskmast/). So, in web.xml, configFile would
be "config/local/soap.xml" and in soap.xml filename would be
"rmsoapsvc/WEB-INF/jsp/DeployedServices.ds"
Title: axis
I am having problems
with deploy descriptors . The config manger is not bieng able to locate it
registry file and is looking at wrong place.
Here is the
-
soap.xml file
(/export/enterprise-docs/riskmast/config/local/soap.xml)
web.xml file of the
webap
Although the client displays the error, the error actually occurs on the
server. You *may* be able to get around the problem by increasing the
JVM max heap size for your servlet container, but only if your payloads
are small enough to fit into that amount of memory. Of course, if the
server is ab
If you do ctx.setGzip(true) on the client, it will do gzip on the
payload the client is sending. The server will automatically uncompress
it. With the gzip=true in the deployment descriptor, the server will
gzip the payload it sends to the client, assuming the client has sent
Accept-Encoding: gzi
Thanks Scott,
I had a look at StatefulEJBProvider and it has code that will do the trick.
cheers, Joe.
- Original Message -
From: Scott Nichol <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, December 09, 2002 8:04 PM
Subject: Re: Serializing EJB Handle
> I don't know about pa
I may get a little of track here, but bear with me, I'm just trying to
be sure everything is straight in my mind.
The issue I always think of when sending binary data within an XML
document is that the document will typically (always, in the case of
Apache SOAP) use UTF-8 encoding. Within that en
Thank you Scott
In fact I recompiled and it worked :
it means that the HTTPReceive.class does not correspond to the
HTTPReceive.src
which had expressely the instruction :
response.setContentType("text/xml"); // Need this to prevent Apache SOAP
from gacking
Even with Tomcat 4.0.4 the Content-Type