You are viewing a plain text version of this content. The canonical link for it is here.
Posted to muse-user@ws.apache.org by "Beil, Matthias" <Be...@ascom-ac.de> on 2007/09/19 12:00:26 UTC
Notify returns a SOAP message
Hi,
we need urgent help on an aspect that so far didn't make a problem, but
now does!
In the WS-N specification the "notify" method is defined as an out-only
method. This means that no reply at all is expected. This is the way how
Metro implements this method. But Muse returns a result SOAP message. As
Metro can't interpret this message, they resend the notification in a
loop.
As Muse is not conforming to the WS-N specification, is there any
possibility to avoid the returning of a SOAP message?
I already tried to overwrite the AxisIsolationLayer class, but this only
resulted in the fact, that an empty body element was returned in the
SOAP message. Who creates the returned SOAP message?
Would be great if someone could help quickly, as we need a solution for
going live with the system.
Mit freundlichen Gruessen / With kind regards
Matthias Beil
Re: Notify returns a SOAP message
Posted by "Kam K. Yee" <op...@gmail.com>.
Matthias,
It looks like the return SOAP messages are created in org.apache.muse.core.platform.axis2.ResponseActionHandler.invoke() (in the Axis2 platform) and in org.apache.muse.core.platform.mini.MiniServlet.doPost() (in the Mini platform).
I think you may be right in that a responses get sent regardless of whether the requester expects a response.
I'll be setting up an environment to trace and debug further. Have you gather any addtional insight into this problem?
----- Original Message -----
From: "Beil, Matthias" <Be...@ascom-ac.de>
To: <mu...@ws.apache.org>
Sent: Wednesday, September 19, 2007 6:00 AM
Subject: Notify returns a SOAP message
Hi,
we need urgent help on an aspect that so far didn't make a problem, but
now does!
In the WS-N specification the "notify" method is defined as an out-only
method. This means that no reply at all is expected. This is the way how
Metro implements this method. But Muse returns a result SOAP message. As
Metro can't interpret this message, they resend the notification in a
loop.
As Muse is not conforming to the WS-N specification, is there any
possibility to avoid the returning of a SOAP message?
I already tried to overwrite the AxisIsolationLayer class, but this only
resulted in the fact, that an empty body element was returned in the
SOAP message. Who creates the returned SOAP message?
Would be great if someone could help quickly, as we need a solution for
going live with the system.
Mit freundlichen Gruessen / With kind regards
Matthias Beil
RE: Notify returns a SOAP message
Posted by "Vinh Nguyen (vinguye2)" <vi...@cisco.com>.
Hi Andreas,
No offense taken:) I do agree with you entirely. To follow closely to
the spec, Muse should be updated to not return a NotifyResponse since
the spec and wsdl defines it as a one-way operation as you pointed out.
To get around this bug, I think you can do the following:
1) Subclass the Notifyhandler class and return null from the toXML()
method. This class handles the Notify message input/output, and it
currently returns a fixed response.
2) Subclass the SimpleNotificationConsumer capability and override the
createNotifyHandler(). Return your custom NotifyHandler class instead
of the original Muse implementation.
3) In your consumer's muse.xml, specify your custom class in #2 above
instead of the original SimpleNotificationConsumer.
-----Original Message-----
From: Andreas.Loew@Sun.COM [mailto:Andreas.Loew@Sun.COM]
Sent: Wednesday, October 10, 2007 1:22 PM
To: muse-user@ws.apache.org
Subject: Re: Notify returns a SOAP message
Vinh,
I don't want to start arguing with you on the correct interpretation of
the textual wording in the spec document. I would rather point to the
WSDL provided with the WS-N 1.3 specification, where the definition of
the "Notify" operation clearly is a "one-way operation" (see WSDL 1.1
spec, section 2.4.1) as follows:
<wsdl:portType name="NotificationConsumer">
<wsdl:operation name="Notify">
<wsdl:input message="wsntw:Notify" />
</wsdl:operation>
</wsdl:portType>
From the WSDL specification, this clearly means that the operation
indeed *is* one-way, which implies neither an output nor a fault message
must be sent back.
Let me try and clarify the issue that Matthias Beil and myself have seen
when sending WS-N notifications from a custom NotificationProducer
implementation based on Metro to a NotificationCosumer implemented using
Muse:
The Glassfish v2/Metro web service client implements the following
logics when calling a one-way endpoint using HTTP(S) transport:
- If the HTTP return code received with the HTTP response is 2xx
(request successfully processed), Metro considers the web service call
to have succeeded.
- If the HTTP return code is within 4xx (client-side error) or 5xx
(server-side error), Metro considers the Web service call to have
failed.
The issue with Muse's implementation is that for a WS-N Notify request,
the Axis2/Muse combo returns an HTTP status code of 200 while at the
same time sending back an HTTP response that contains a SOAP message
with a SOAP fault. This means that Metro considers this notification to
have been sent successfully, while in reality, notification processing
at the consumer side has failed: we have suffered a message loss!!!
Basically is not the fact that, in case of an unforeseen error at the
Notification Consumer, the HTTP response sent back by Axis2/Muse
contains a - well, let's say: "unnecessary" (at least) - SOAP message,
the crucial point is that this fault message is sent together with an
HTTP status code of 200 (OK): It is this misleading HTTP response code
that, in our case, causes the loss of notifications in case some
unforeseen exceptions have happened in the Muse NotificationConsumer.
So IMHO, for interoperability with other frameworks, you should
definitely consider to change Muse's default implementation to (at
least) ensure that HTTP status 5xx is returned whenever the
(unnecessary) response message happens to contain a fault...
Best regards,
Andreas
BTW: I am just a professional services field guy working at Sun in
Germany and not directly related to the Sun engineering team that
created Metro. No offense meant ;-)
Vinh Nguyen (vinguye2) schrieb:
> Hmm, I wouldn't go as far to say that Muse is non-compliant with WS-N
> 1.3. Muse's NotificationConsumer does meet the specification for the
> Notify message by handling the message properly. Just that it returns
> a response to the sender, which is extra behavior on top of the
> specification. I'm not sure this means non-compliance.
>
> If you look at the last sentence on p.12 of the specification found
> via the link below, it just says that: "No response is expected from
> the NotificationConsumer upon receipt of this message."
>
> But it doesn't mean that the consumer can't return a response at all.
> In a way, I think returning a response is good because it lets the
> sender know that the notification was received successfully by the
> consumer. Perhaps Metro should just ignore the response if it knows
> an operation doesn't need a response. But then, it still needs to be
> smart enough to handle responses like an http 400 error:)
>
> http://docs.oasis-open.org/wsn/wsn-ws_base_notification-1.3-spec-os.pd
> f
>
>
>
>
> -----Original Message----- From: Beil, Matthias
> [mailto:Beil@ascom-ac.de] Sent: Wednesday, October 10, 2007 12:12 AM
> To: muse-user@ws.apache.org Subject: AW: Notify returns a SOAP message
>
> Hi,
>
> it's true that Axis2 doesn't return a response by its own.
>
> As I'm using the Axis2 environment of Muse the incoming request goes
> through the in-engine of Axis2. The response returns through the
> out-engine. What I did was to add an Axis2 handler to this out flow.
> This handler just drops the response. With a bit more logic it would
> be possible to filter the returning messages.
>
> But this is not the solution: The problem lies within Muse himself!
>
> The "notify" message is defined as an "out-only" message (see
> wsn-ws_base_notification-1.3-spec-os line 363 and the wsdl file).
> This means that there is absolutely NO return value expected!!!!
> Neither a response, nor any fault message.
>
> But Muse doesn't implement this in this way. The implementation of
> Muse always returns a "NotifyResponse" and / or a fault message. But
> for the "notify" message, even a fault return is not expected.
>
> So it is Muse who does not comply with the WS-N 1.3 Specification!
>
> Regards, Matthias
--
Andreas Loew
Java Architect
Sun Microsystems (Germany)
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
Re: Notify returns a SOAP message
Posted by Andreas Loew <An...@Sun.COM>.
Vinh,
I don't want to start arguing with you on the correct interpretation of
the textual wording in the spec document. I would rather point to the
WSDL provided with the WS-N 1.3 specification, where the definition of
the "Notify" operation clearly is a "one-way operation" (see WSDL 1.1
spec, section 2.4.1) as follows:
<wsdl:portType name="NotificationConsumer">
<wsdl:operation name="Notify">
<wsdl:input message="wsntw:Notify" />
</wsdl:operation>
</wsdl:portType>
From the WSDL specification, this clearly means that the operation
indeed *is* one-way, which implies neither an output nor a fault message
must be sent back.
Let me try and clarify the issue that Matthias Beil and myself have seen
when sending WS-N notifications from a custom NotificationProducer
implementation based on Metro to a NotificationCosumer implemented using
Muse:
The Glassfish v2/Metro web service client implements the following
logics when calling a one-way endpoint using HTTP(S) transport:
- If the HTTP return code received with the HTTP response is 2xx
(request successfully processed), Metro considers the web service call
to have succeeded.
- If the HTTP return code is within 4xx (client-side error) or 5xx
(server-side error), Metro considers the Web service call to have failed.
The issue with Muse's implementation is that for a WS-N Notify request,
the Axis2/Muse combo returns an HTTP status code of 200 while at the
same time sending back an HTTP response that contains a SOAP message
with a SOAP fault. This means that Metro considers this notification to
have been sent successfully, while in reality, notification processing
at the consumer side has failed: we have suffered a message loss!!!
Basically is not the fact that, in case of an unforeseen error at the
Notification Consumer, the HTTP response sent back by Axis2/Muse
contains a - well, let's say: "unnecessary" (at least) - SOAP message,
the crucial point is that this fault message is sent together with an
HTTP status code of 200 (OK): It is this misleading HTTP response code
that, in our case, causes the loss of notifications in case some
unforeseen exceptions have happened in the Muse NotificationConsumer.
So IMHO, for interoperability with other frameworks, you should
definitely consider to change Muse's default implementation to (at
least) ensure that HTTP status 5xx is returned whenever the
(unnecessary) response message happens to contain a fault...
Best regards,
Andreas
BTW: I am just a professional services field guy working at Sun in
Germany and not directly related to the Sun engineering team that
created Metro. No offense meant ;-)
Vinh Nguyen (vinguye2) schrieb:
> Hmm, I wouldn't go as far to say that Muse is non-compliant with WS-N
> 1.3. Muse's NotificationConsumer does meet the specification for the
> Notify message by handling the message properly. Just that it
> returns a response to the sender, which is extra behavior on top of
> the specification. I'm not sure this means non-compliance.
>
> If you look at the last sentence on p.12 of the specification found
> via the link below, it just says that: "No response is expected from
> the NotificationConsumer upon receipt of this message."
>
> But it doesn't mean that the consumer can't return a response at all.
> In a way, I think returning a response is good because it lets the
> sender know that the notification was received successfully by the
> consumer. Perhaps Metro should just ignore the response if it knows
> an operation doesn't need a response. But then, it still needs to be
> smart enough to handle responses like an http 400 error:)
>
> http://docs.oasis-open.org/wsn/wsn-ws_base_notification-1.3-spec-os.pdf
>
>
>
>
> -----Original Message----- From: Beil, Matthias
> [mailto:Beil@ascom-ac.de] Sent: Wednesday, October 10, 2007 12:12 AM
> To: muse-user@ws.apache.org Subject: AW: Notify returns a SOAP
> message
>
> Hi,
>
> it's true that Axis2 doesn't return a response by its own.
>
> As I'm using the Axis2 environment of Muse the incoming request goes
> through the in-engine of Axis2. The response returns through the
> out-engine. What I did was to add an Axis2 handler to this out flow.
> This handler just drops the response. With a bit more logic it would
> be possible to filter the returning messages.
>
> But this is not the solution: The problem lies within Muse himself!
>
> The "notify" message is defined as an "out-only" message (see
> wsn-ws_base_notification-1.3-spec-os line 363 and the wsdl file).
> This means that there is absolutely NO return value expected!!!!
> Neither a response, nor any fault message.
>
> But Muse doesn't implement this in this way. The implementation of
> Muse always returns a "NotifyResponse" and / or a fault message. But
> for the "notify" message, even a fault return is not expected.
>
> So it is Muse who does not comply with the WS-N 1.3 Specification!
>
> Regards, Matthias
--
Andreas Loew
Java Architect
Sun Microsystems (Germany)
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
RE: Notify returns a SOAP message
Posted by "Vinh Nguyen (vinguye2)" <vi...@cisco.com>.
Hmm, I wouldn't go as far to say that Muse is non-compliant with WS-N 1.3. Muse's NotificationConsumer does meet the specification for the Notify message by handling the message properly. Just that it returns a response to the sender, which is extra behavior on top of the specification. I'm not sure this means non-compliance.
If you look at the last sentence on p.12 of the specification found via the link below, it just says that:
"No response is expected from the NotificationConsumer upon receipt of this message."
But it doesn't mean that the consumer can't return a response at all. In a way, I think returning a response is good because it lets the sender know that the notification was received successfully by the consumer. Perhaps Metro should just ignore the response if it knows an operation doesn't need a response. But then, it still needs to be smart enough to handle responses like an http 400 error:)
http://docs.oasis-open.org/wsn/wsn-ws_base_notification-1.3-spec-os.pdf
-----Original Message-----
From: Beil, Matthias [mailto:Beil@ascom-ac.de]
Sent: Wednesday, October 10, 2007 12:12 AM
To: muse-user@ws.apache.org
Subject: AW: Notify returns a SOAP message
Hi,
it's true that Axis2 doesn't return a response by its own.
As I'm using the Axis2 environment of Muse the incoming request goes through the in-engine of Axis2. The response returns through the out-engine. What I did was to add an Axis2 handler to this out flow. This handler just drops the response. With a bit more logic it would be possible to filter the returning messages.
But this is not the solution: The problem lies within Muse himself!
The "notify" message is defined as an "out-only" message (see wsn-ws_base_notification-1.3-spec-os line 363 and the wsdl file). This means that there is absolutely NO return value expected!!!! Neither a response, nor any fault message.
But Muse doesn't implement this in this way. The implementation of Muse always returns a "NotifyResponse" and / or a fault message. But for the "notify" message, even a fault return is not expected.
So it is Muse who does not comply with the WS-N 1.3 Specification!
Regards,
Matthias
-----Ursprüngliche Nachricht-----
Von: Vinh Nguyen (vinguye2) [mailto:vinguye2@cisco.com]
Gesendet: Dienstag, 9. Oktober 2007 20:38
An: muse-user@ws.apache.org
Betreff: RE: Notify returns a SOAP message
I believe the response is coming from NotifyHandler, which is created by SimpleNotificationConsumer to handle the "notify" message.
notifyHandler.toXML(Object) always returns a static xml response. This is where the fix needs to be made.
I don't believe Axis2 itself is automatically returning a response. If it is, then you'd also get a response for all custom operations that don't have a return value, which then should be very noticable.
-----Original Message-----
From: beil [mailto:Beil@ascom-ac.de]
Sent: Tuesday, October 09, 2007 2:36 AM
To: muse-user@ws.apache.org
Subject: Re: Notify returns a SOAP message
Hi,
I'm using the SimpleNotificationConsumer.
Finally I gave up to find the source of this return response. The
solution I finally used, was to create an abort handler.
This is just a class, which aborts all response message in an Axis2
handler.
Made an Axis2 handler out of it and added this handler to axis2.xml
file.
So no responses at all are returned from the wsn-consumer. In our
environment I can live with this solution.
THX for the help.
Regards,
Matthias
Kam K. Yee wrote:
>
> Matthias,
>
> Are you using the SimpleNotificationConsumer default implementation or
> did you write your own?
>
>
> Regards,
> Kam K. Yee
> IBM Corporation
>
>
> ----- Original Message -----
> From: "Beil, Matthias" <Be...@ascom-ac.de>
> To: <mu...@ws.apache.org>
> Sent: Wednesday, September 19, 2007 6:00 AM
> Subject: Notify returns a SOAP message
>
>
> Hi,
>
> we need urgent help on an aspect that so far didn't make a problem,
> but now does!
>
> In the WS-N specification the "notify" method is defined as an
> out-only method. This means that no reply at all is expected. This is
> the way how Metro implements this method. But Muse returns a result
> SOAP message. As Metro can't interpret this message, they resend the
> notification in a loop.
>
> As Muse is not conforming to the WS-N specification, is there any
> possibility to avoid the returning of a SOAP message?
>
> I already tried to overwrite the AxisIsolationLayer class, but this
> only resulted in the fact, that an empty body element was returned in
> the SOAP message. Who creates the returned SOAP message?
>
> Would be great if someone could help quickly, as we need a solution
> for going live with the system.
>
> Mit freundlichen Gruessen / With kind regards Matthias Beil
>
>
>
>
>
--
View this message in context:
http://www.nabble.com/Notify-returns-a-SOAP-message-tf4479979.html#a1311
2206
Sent from the Muse User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
AW: Notify returns a SOAP message
Posted by "Beil, Matthias" <Be...@ascom-ac.de>.
Hi,
it's true that Axis2 doesn't return a response by its own.
As I'm using the Axis2 environment of Muse the incoming request goes through the in-engine of Axis2. The response returns through the out-engine. What I did was to add an Axis2 handler to this out flow. This handler just drops the response. With a bit more logic it would be possible to filter the returning messages.
But this is not the solution: The problem lies within Muse himself!
The "notify" message is defined as an "out-only" message (see wsn-ws_base_notification-1.3-spec-os line 363 and the wsdl file). This means that there is absolutely NO return value expected!!!! Neither a response, nor any fault message.
But Muse doesn't implement this in this way. The implementation of Muse always returns a "NotifyResponse" and / or a fault message. But for the "notify" message, even a fault return is not expected.
So it is Muse who does not comply with the WS-N 1.3 Specification!
Regards,
Matthias
-----Ursprüngliche Nachricht-----
Von: Vinh Nguyen (vinguye2) [mailto:vinguye2@cisco.com]
Gesendet: Dienstag, 9. Oktober 2007 20:38
An: muse-user@ws.apache.org
Betreff: RE: Notify returns a SOAP message
I believe the response is coming from NotifyHandler, which is created by
SimpleNotificationConsumer to handle the "notify" message.
notifyHandler.toXML(Object) always returns a static xml response. This
is where the fix needs to be made.
I don't believe Axis2 itself is automatically returning a response. If
it is, then you'd also get a response for all custom operations that
don't have a return value, which then should be very noticable.
-----Original Message-----
From: beil [mailto:Beil@ascom-ac.de]
Sent: Tuesday, October 09, 2007 2:36 AM
To: muse-user@ws.apache.org
Subject: Re: Notify returns a SOAP message
Hi,
I'm using the SimpleNotificationConsumer.
Finally I gave up to find the source of this return response. The
solution I finally used, was to create an abort handler.
This is just a class, which aborts all response message in an Axis2
handler.
Made an Axis2 handler out of it and added this handler to axis2.xml
file.
So no responses at all are returned from the wsn-consumer. In our
environment I can live with this solution.
THX for the help.
Regards,
Matthias
Kam K. Yee wrote:
>
> Matthias,
>
> Are you using the SimpleNotificationConsumer default implementation or
> did you write your own?
>
>
> Regards,
> Kam K. Yee
> IBM Corporation
>
>
> ----- Original Message -----
> From: "Beil, Matthias" <Be...@ascom-ac.de>
> To: <mu...@ws.apache.org>
> Sent: Wednesday, September 19, 2007 6:00 AM
> Subject: Notify returns a SOAP message
>
>
> Hi,
>
> we need urgent help on an aspect that so far didn't make a problem,
> but now does!
>
> In the WS-N specification the "notify" method is defined as an
> out-only method. This means that no reply at all is expected. This is
> the way how Metro implements this method. But Muse returns a result
> SOAP message. As Metro can't interpret this message, they resend the
> notification in a loop.
>
> As Muse is not conforming to the WS-N specification, is there any
> possibility to avoid the returning of a SOAP message?
>
> I already tried to overwrite the AxisIsolationLayer class, but this
> only resulted in the fact, that an empty body element was returned in
> the SOAP message. Who creates the returned SOAP message?
>
> Would be great if someone could help quickly, as we need a solution
> for going live with the system.
>
> Mit freundlichen Gruessen / With kind regards Matthias Beil
>
>
>
>
>
--
View this message in context:
http://www.nabble.com/Notify-returns-a-SOAP-message-tf4479979.html#a1311
2206
Sent from the Muse User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
RE: Notify returns a SOAP message
Posted by "Vinh Nguyen (vinguye2)" <vi...@cisco.com>.
I believe the response is coming from NotifyHandler, which is created by
SimpleNotificationConsumer to handle the "notify" message.
notifyHandler.toXML(Object) always returns a static xml response. This
is where the fix needs to be made.
I don't believe Axis2 itself is automatically returning a response. If
it is, then you'd also get a response for all custom operations that
don't have a return value, which then should be very noticable.
-----Original Message-----
From: beil [mailto:Beil@ascom-ac.de]
Sent: Tuesday, October 09, 2007 2:36 AM
To: muse-user@ws.apache.org
Subject: Re: Notify returns a SOAP message
Hi,
I'm using the SimpleNotificationConsumer.
Finally I gave up to find the source of this return response. The
solution I finally used, was to create an abort handler.
This is just a class, which aborts all response message in an Axis2
handler.
Made an Axis2 handler out of it and added this handler to axis2.xml
file.
So no responses at all are returned from the wsn-consumer. In our
environment I can live with this solution.
THX for the help.
Regards,
Matthias
Kam K. Yee wrote:
>
> Matthias,
>
> Are you using the SimpleNotificationConsumer default implementation or
> did you write your own?
>
>
> Regards,
> Kam K. Yee
> IBM Corporation
>
>
> ----- Original Message -----
> From: "Beil, Matthias" <Be...@ascom-ac.de>
> To: <mu...@ws.apache.org>
> Sent: Wednesday, September 19, 2007 6:00 AM
> Subject: Notify returns a SOAP message
>
>
> Hi,
>
> we need urgent help on an aspect that so far didn't make a problem,
> but now does!
>
> In the WS-N specification the "notify" method is defined as an
> out-only method. This means that no reply at all is expected. This is
> the way how Metro implements this method. But Muse returns a result
> SOAP message. As Metro can't interpret this message, they resend the
> notification in a loop.
>
> As Muse is not conforming to the WS-N specification, is there any
> possibility to avoid the returning of a SOAP message?
>
> I already tried to overwrite the AxisIsolationLayer class, but this
> only resulted in the fact, that an empty body element was returned in
> the SOAP message. Who creates the returned SOAP message?
>
> Would be great if someone could help quickly, as we need a solution
> for going live with the system.
>
> Mit freundlichen Gruessen / With kind regards Matthias Beil
>
>
>
>
>
--
View this message in context:
http://www.nabble.com/Notify-returns-a-SOAP-message-tf4479979.html#a1311
2206
Sent from the Muse User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
Re: Notify returns a SOAP message
Posted by beil <Be...@ascom-ac.de>.
Hi,
I'm using the SimpleNotificationConsumer.
Finally I gave up to find the source of this return response. The solution I
finally used, was to create an abort handler.
This is just a class, which aborts all response message in an Axis2 handler.
Made an Axis2 handler out of it and added this handler to axis2.xml file.
So no responses at all are returned from the wsn-consumer. In our
environment I can live with this solution.
THX for the help.
Regards,
Matthias
Kam K. Yee wrote:
>
> Matthias,
>
> Are you using the SimpleNotificationConsumer default implementation or did
> you write your own?
>
>
> Regards,
> Kam K. Yee
> IBM Corporation
>
>
> ----- Original Message -----
> From: "Beil, Matthias" <Be...@ascom-ac.de>
> To: <mu...@ws.apache.org>
> Sent: Wednesday, September 19, 2007 6:00 AM
> Subject: Notify returns a SOAP message
>
>
> Hi,
>
> we need urgent help on an aspect that so far didn't make a problem, but
> now does!
>
> In the WS-N specification the "notify" method is defined as an out-only
> method. This means that no reply at all is expected. This is the way how
> Metro implements this method. But Muse returns a result SOAP message. As
> Metro can't interpret this message, they resend the notification in a
> loop.
>
> As Muse is not conforming to the WS-N specification, is there any
> possibility to avoid the returning of a SOAP message?
>
> I already tried to overwrite the AxisIsolationLayer class, but this only
> resulted in the fact, that an empty body element was returned in the
> SOAP message. Who creates the returned SOAP message?
>
> Would be great if someone could help quickly, as we need a solution for
> going live with the system.
>
> Mit freundlichen Gruessen / With kind regards
> Matthias Beil
>
>
>
>
>
--
View this message in context: http://www.nabble.com/Notify-returns-a-SOAP-message-tf4479979.html#a13112206
Sent from the Muse User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
Re: Notify returns a SOAP message
Posted by "Kam K. Yee" <op...@gmail.com>.
Matthias,
Are you using the SimpleNotificationConsumer default implementation or did you write your own?
Regards,
Kam K. Yee
IBM Corporation
----- Original Message -----
From: "Beil, Matthias" <Be...@ascom-ac.de>
To: <mu...@ws.apache.org>
Sent: Wednesday, September 19, 2007 6:00 AM
Subject: Notify returns a SOAP message
Hi,
we need urgent help on an aspect that so far didn't make a problem, but
now does!
In the WS-N specification the "notify" method is defined as an out-only
method. This means that no reply at all is expected. This is the way how
Metro implements this method. But Muse returns a result SOAP message. As
Metro can't interpret this message, they resend the notification in a
loop.
As Muse is not conforming to the WS-N specification, is there any
possibility to avoid the returning of a SOAP message?
I already tried to overwrite the AxisIsolationLayer class, but this only
resulted in the fact, that an empty body element was returned in the
SOAP message. Who creates the returned SOAP message?
Would be great if someone could help quickly, as we need a solution for
going live with the system.
Mit freundlichen Gruessen / With kind regards
Matthias Beil