Looks like attachments aren't going thru. To be safe though, you can view the source code on the Axis2 site for:
org.apache.axis2.transport.http.AxisServlet -----Original Message----- From: Vinh Nguyen (vinguye2) Sent: Thursday, July 03, 2008 4:00 PM To: [email protected] Subject: RE: Responde with HTTP 500 on purpose Hi, You can send a 500 directly on the HttpServletResponse by: response.sendError(HttpServletResponse.SC_NOT_FOUND); But from within Muse, I don't believe there's a way to get a direct handle on the HttpServletResponse. That's in the core Axis2 SOAP engine which receives all requests and processes the SOAP. So you might have to dig into the Axis2 code. I did a little checking, and I'm not sure if you can easily access the HttpServletResponse in the Axis2 code either. So going the top-down approach, the AxisServlet is defined in the web.xml. The latest Axis2 1.4 source code is attached, although I'm not sure if it has changed much since 1.2. One possible solution is to extend/override the post() method in this class. Catch a custom exception that you would throw from your consumer capability if you fail to persist a notification. When this exception is caught, you can set the 500 code on the response. Then specify this custom servlet in your web.xml instead of the original Axis2. This is not a clean solution though. The better solution is to throw a custom SoapFault from your consumer. The producer will get it and can check the content. This way, you don't have to explicitly depend on HTTP responses, but instead handle SOAP responses like all other SOAP operations. Hope this helps... -Vinh -----Original Message----- From: Rapp, Christian [mailto:[EMAIL PROTECTED] Sent: Thursday, July 03, 2008 10:41 AM To: [email protected] Subject: AW: Responde with HTTP 500 on purpose Hi Chris, As far as I found out this is only working in Axis and not Axis2. In Axis2 this should work: MessageContext inContext = MessageContext.getCurrentMessageContext(); inContext.setProperty(Constants.HTTP_RESPONSE_STATE, HttpServletResponse.SC_INTERNAL_SERVER_ERROR); But this does not work for the Axis2 version that comes with Muse. Therre the Constants class does not know this constant. We somehow need to get access to the HttpServletResponse object. In that I found the status code that is being returned. Always being 200. I am doing more research on this tomorrow. Regards, Christian -----Ursprüngliche Nachricht----- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 3. Juli 2008 17:11 An: [email protected] Betreff: RE: Responde with HTTP 500 on purpose Hi Christian The code responsible for this is somewhere in Axis2 not inside of Muse itself. From a small bit of googling I found this: HttpServletResponse resp = (HttpServletResponse) getCurrentMessageContext() .getProperty(HTTPConstants.MC_HTTP_SERVLETRESPONSE); if (resp != null) { resp.setStatus(status); } I didn't find any obvious Axis2 docs for this kind of behaviour though, or even how the return status codes are decided. cheers, Chris -----Original Message----- From: Rapp, Christian [mailto:[EMAIL PROTECTED] Sent: Thursday, July 03, 2008 4:59 PM To: [email protected] Subject: AW: Responde with HTTP 500 on purpose Hi Chris, Yes, I am using a TopicListener which is a NotificationMessageListener. Currently I am able to send back a SOAP-Fault, but that does not include sending back a HTTP500. It rather returns a HTTP200 which does not help us very much. Is it possible to overwrite the class responsible for setting the HTTP returncode? Because we can not wait until the issue you mentioned has been fixed. Do you have the issue number of the mentioned issue? Regards, Christian -----Ursprüngliche Nachricht----- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 3. Juli 2008 14:47 An: [email protected] Betreff: RE: Responde with HTTP 500 on purpose Hi, Just to be sure are you receiving the message with a NotificationMessageListener? If so you can't actually throw anything back to the environment (there is a current JIRA for this I beleive) the Throwable will just be caught and logged. Using Axis2 directly (1.1 and above) the MessageContext.getCurrentMessageContext should allow you to directly set a soap fault for the reply, thus causing a 500. http://wso2.org/library/106 let us know how you get on cheers, Chris -----Original Message----- From: Rapp, Christian [mailto:[EMAIL PROTECTED] Sent: Thursday, July 03, 2008 1:59 PM To: [email protected] Subject: AW: Responde with HTTP 500 on purpose Hi, Muse runs on top of Axis2. Regards, Christian -----Ursprüngliche Nachricht----- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 3. Juli 2008 13:56 An: [email protected] Betreff: RE: Responde with HTTP 500 on purpose Hi Christian, which environment (isolation layer) are you using? As Muse is a plugable environment it does not directly interact with the HttpRequest or force return codes. As such it depends on the environment it runs in to make sensible decisions. cheers, Chris -----Original Message----- From: Rapp, Christian [mailto:[EMAIL PROTECTED] Sent: Thursday, July 03, 2008 1:45 PM To: [email protected] Subject: Responde with HTTP 500 on purpose Hello, We receive WS-Notifications from a server. We than try to store the notification first. If this fails, we need to send back a HTTP 500 errorcode so that the server knows, that we did not receive the notification successfully. Is there are a way in muse how we can accomplish that? Regards, Christian --------------------------------------------------------------------- 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] --------------------------------------------------------------------- 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] --------------------------------------------------------------------- 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] --------------------------------------------------------------------- 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]
