Title: RE: Multi-Threading issue?
kill -HUP java process pid
-Original Message-
From: François Schiettecatte [EMAIL PROTECTED]@VODAFONE
Sent: Thursday, 15 January 2004 2:39 p.m.
To: [EMAIL PROTECTED]
Subject: Re: Multi-Threading issue?
Santosh
I would be curious (and
Why not just include a version number with the XML feed? Your clients will
know it has changed if the version number increments. If you can't change
the XML schema itself, then the version number could go in a SOAP header,
or any number of other places.
ADK
Here is the client implementation that we use to call a SOAP RPC service
from inside an EJB. Note that we use pure JAXRPC here. The web service
is implemented in Axis and runs inside Weblogic 6.1.
One further note: The axis client stuff re-uses code from the server
implementation. That
It is not necessary to implement a 'Handler'. The class that implements
the SOAP service itself also has access to the MessageContext, from which
you can retrieve the HTTP request and response objects. Just use
MessageContext.getCurrentContext().
Cheers
ADK
In fact the SOAP spec requires the SOAPAction header for SOAP over HTTP.
The header need not contain a value, but it must exist. A constant source
of interoperability issues between SOAP implementations is the value of
this header.
Cheers
ADK
You need to implement your message handling method with one of the 3 or 4
signatures listed in the user guide. (RTFM!) ;-) The allowedMethods is
aimed at RPC style SOAP.
If you wish to have multiple services, but all of them need pre-processing
by some common code, you could try implementing a
You are right that allowedMethods is used in MSG as well as RPC, but its
use in MSG is limited to naming the single method that will handle your
messages - not naming all of the methods then you are allowed to call.
I seem to remember an earlier post on this list which suggested that Axis
was
Hi,
I am trying to run two axis webapps inside Weblogic Server 6.1sp2. One is
the sample webapp that ships with Axis (r1.0). The other is a webapp that
my team has written. Our webapp has several handlers added to the global
requestFlow chain.
The trouble is that when I direct a list request
If I put the appropriate classes in the classes dir of the samples webapp,
the problem goes away, and the config return by the admin client list
command is the correct one for the samples webapp.
This raises the question of why the samples webapp was trying to load my
class, if it wasn't
