That is "After and only After" an Exception since I've been told to get it up front is a performance hit we don't want because that would be for each and every call rather than just for an Exception. Makes sense of course but I sure don't see how it can be done AFTER an Exception.
Use case goes like this: Some guys, perhaps bad guys, send us some bad SOAP and the dispatcher chucks out a SaajSoapEnvelopeException. How do I handle this gracefully?
So far what I have is an extension of MessageDispatcherServlet with an override of the doService() method. The web.xml file has been updated to show this Dispatcher for Spring's config. Within this override, surround the call to the super method with a try/catch and you catch the Exception but the problem here is that the stream for the HttpServletRequest is already closed, so you can't get the SOAP from here, AFIK.
Another problem is that I can't get a marshaller to wire in here. I have Java faults generated from our WSDL I would like to use but I think there is a problem with wiring marshallers in a non-endpoint class. Perhaps something about the namespace? I probably need to read up on how these work.
Bottum line: Is it possible to get the SOAP after an Exception or is it possible to predict that there will be an Exception so that I can grab it up front? Also, how can I get a fault marshaller into this Dispatcher or will I have to BS up a text version of the fault?
I'm fairly new to Web Services and what I know so far is mostly CXF. So far, I'm not much impressed with Spring WS. They have a long ways to go yet, IMHO. The fact that I can't get my WSDL from the service due to a known bug having to do with XSD references in WSDL not getting properly renamed to match the bean, is particularly annoying.
Have you tried a EndpointExceptionResolver?
For instance, I have used one to catch and translate authentication exceptions.
You'll probably need an EndpointInterceptor as well to wrap the exception resolver.
Related
I am coding a REST API using Perl/Mojolicious
Sometimes when I want to throw an error, for example "Invalid token" I store the error on a variable called "Object->lastError" and then I render the JSON response with the error message/code.
However it gets tedious to do it that way after a while. I was wondering if there is a better way to do this I was considering just dying and catching the die error with$SIG{__DIE__}
Any suggestions?
Also, I am not using any logger yet but I would like to log those errors
On the question of logging, see: http://search.cpan.org/~garu/MojoX-Log-Log4perl-0.10/lib/MojoX/Log/Log4perl.pm Log4perl is pretty much best practice in the wider Perl world.
Without knowing a lot of deep detail about the application, I far prefer your 'tedious' method which will [hopefully] provide some information on the receiving side of the API, rather than a crash and burn with $SIG{__DIE__}.
Hope that helps, a bit, anyway!
In the old days, when each request to a web application was handled by one thread, it was fairly easy to understand the logs. One could, for example, use a servlet filter to name the thread that was handling a request with some sort of request id. This request id then could be output in the logs. In this world, a simple grep was all it took to collect the log lines for a given request.
In my current position, I'm building web applications with Scala (we're using Scalatra but that isn't specifically relevant to my question). Each request creates a scala.concurrent.Future and is then parked until that future has completed. The important bit here is that the thread that actually handles the business logic is different from the thread that handled the request which is different (I think) from the thread that completes the request and so the context of that request is lost during processing. The business logic can log all it likes but it is hard to associate that logging with the specific request it relates to.
Now from the standpoint of supporting my web services in production, the old approach was great and I'd like to come up with something similar for my asynchronous services. I've been trying to come up with a way to do it but have come up empty. That is, I haven't come up with anything nearly as light weight as the old, name-the-thread model. Does the Stack Overflow crowd have any suggestions?
Thanks
As you have written, assign an id to each request, and pass that to the business logic function. You can also do this with implicit parameter, so your code won't be cluttered.
This should be possible with MDC logging available with SLF4j which uses Thread local storage to store the context of the each request.
Also you will have to create a MDC Context Propagating execution context, to move the context across threads.
This post describes it well:
http://code.hootsuite.com/logging-contextual-info-in-an-asynchronous-scala-application/
Does anyone know if it is possible to write to the response stream in OpenRasta rather than returning an object as a response resource? Alternatively, am I able to implement an HTTP handler but still leverage OpenRasta's URL rewriting?
Thanks
Chris
You can always keep an http handler on the side to do specialized things, but that ties you to asp.net and will prevent your code from being portable on other hosts. If that's something you're ok with, any handler that's registered for a specific route will get executed before openrasta on asp.net.
that said, codecs are the ones writing to the response stream, so provided you have a custom IMediaTypeWriter you can write the resource instance on a stream whichever way you want.
Say for example that you returned an IEnumerable from your handler, as those get deferred executed, you can just start the enumeration of those in your custom codec without any problem.
I want to modify the response that is sent when I am implementing a SOAP server using Zend_Soap_Server. I want to change the response that will be sent back because I am implementing the SOAP server for a client application that was written to work with another system but now I need to make it work with our system. The client application is expecting the XML response to be in a certain way. So what I want to do is that I dont want the handle method to put together its own XML response, I want to do it myself. Can this be done?
Thanks
I suspect there is some kind of output buffering trick you could use to do this, but a better solution might be to investigate the deeper cause of why the client is rejecting your XML and, in so doing, you may find a much more elegant solution.
For starters, you should probably read this very helpful article:
http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/
You should then investigate Zend_Soap_AutoDiscover->setOperationBodyStyle() and Zend_Soap_AutoDiscover->setOperationBodyStyle() to see if changing the encoding style or binding style solves the problem.
I have a SOAP WS which I access through PHP's SoapClient (wrapped with Zend Framework's Soap Client). The webservice runs through https, and the calls take quite some time (a few minutes each).
I am making 4 calls, one after another through the same instance of SoapClient. However, after some time running, and at a random point (not allways on the same method call) I see the following error:
Warning: SoapClient::__doRequest(): SSL: Broken pipe in pathtomyfile
I still have no idea why this happened, but I've got some extra insight and a workaround.
The issue arises when, after a SOAP call that took really long to run, I try to use the same connection for another request. The first one will succeed, but upon the new call, the error raises.
This means, that as long as you don't NEED the connection to be same (which is usually the case on SOAP web services), you can just reset the connection between calls. Not the most efficient use of resources, but will work flawlessly.
I found that adding the
'keep_alive' => false
option to
new SoapClient($url, $options)
solved the issue for me.
There is a related bug report here but very little documentation about it apart from that: https://bugs.php.net/bug.php?id=60329