Dan,
It sounds like you want to write a class that extends BasicHandler. The
invoke() method is passed a MessageContext instance. From that you call
getCurrentMessage(), which gives you access to SOAPBody, SOAPEnvelope,
SOAPHeader, and SOAPPart. You can also access most if not all of the
HTTP request headers by using the MessageContext.getProperty() method.
You can see an example of this in the source of HTTPAuthHandler. If you
do not want to write a BasicHandler, you can use the MessageContext
static method getCurrentContext() which uses a ThreadLocal to associate
the MessageContext with your thread.
On your second set of questions, there are a lot of ways to solve the
problem depending on the requirements, ie can you do a fresh deploy or
do you need to be able to do this type of debugging against a production
box. I normally put URLs of external services in a properties file
outside of the deployed archive that is specific to the environment:
Dev, QA, User Acceptance, Production, etc. That allows me migrate the
archive unchanged all the way from Dev to Production. How you load the
properties file and how you have your business logic access depends on
your platform. I am partial to Spring Framework and IOC. Hope that helps.
Fred
D.Kreft wrote:
Is it possible to retrieve header SOAP header information under Axis1?
There's only one e-mail in the archives that seems appropriate, but it
was never answered
(http://marc.theaimsgroup.com/?l=axis-user&m=116072386027359&w=2). I
know this can be done under Axis2, but I'm not in a position at
present to make that switch. Pointers to example source code or
existing documentation would be much appreciated.
Another question I should probably ask, just as a sanity-checking
measure, is whether it's appropriate to do what I'm thinking about
doing. My primary web service needs to talk to one or more "helper"
web services, and from time to time it might be useful or even
necessary to force my primary service to consult a non-default
"helper" service when debugging problems or testing new features. My
thought was to pass along an override URL for the "helper" service in
the SOAP header. Does this make sense? It sure seems better than
adding additional override arguments to all of my service methods!
-dan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
