[ 
https://issues.apache.org/jira/browse/WSCOMMONS-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12694063#action_12694063
 ] 

Amila Chinthaka Suriarachchi commented on WSCOMMONS-456:
--------------------------------------------------------

I think I did not get what you really means.

"in principle it should be possible to use the mail transport with asynchronous 
responses without WS-Addressing"

What you mean here? In asynchronous communication we map the request and 
response messages using addressing 'relatesTo' field.

"However this will only be possible if the SMTP message ID is the same as the 
Axis2 message ID".

When we use addressing 'relatesTo' Axis2 keeps a map of sending messageID and 
operation context. When the response comes it gets the relatesTo filed value 
(which is same as messageID ) and get the corresponding OperationContext.

Are you thinking doing such a thing with SMTP transport level without using 
addressing? In that case you can keep a table with SMTP message ID and 
OperationContext. Then dispatch it with the SMTP In-Reply-To header. So no need 
to use the same message ID for SMTP message.

But currently it does this by using a table which keeps SMTP message ID and  
SynchronousCallback.



 



> Supporting SMTP transport for RM
> --------------------------------
>
>                 Key: WSCOMMONS-456
>                 URL: https://issues.apache.org/jira/browse/WSCOMMONS-456
>             Project: WS-Commons
>          Issue Type: Improvement
>            Reporter: Amila Chinthaka Suriarachchi
>         Attachments: patch.txt
>
>
> I recently had some tests for smtp RM support. With the following changes and 
> couple of changes to Sandesha2 trunk I was able to make it working. Here are 
> the smtp transport changes required.
> 1. removing using of same message ID for mail message.
> 2. Setting a RequestResponse transport object and set the status as wait.
> This is the same issue I saw in supporting synapse NIO transport as well.
> Sandesha2 SenderWorker.java 191 has the following code. 
> if (t==null) {
>                               if (op != null)
>                                       inMsg = 
> op.getMessageContext(WSDLConstants.MESSAGE_LABEL_IN_VALUE);
>                               if (inMsg != null)
>                                       t = (RequestResponseTransport) 
> inMsg.getProperty(RequestResponseTransport.TRANSPORT_CONTROL);
>                       }
>                       // If we are anonymous, and this is not a 
> makeConnection, then we must have a transport waiting
>                       if((toEPR==null || toEPR.hasAnonymousAddress()) &&
>                          (makeConnection == null || 
> !makeConnection.booleanValue()) &&
>                          (t == null || 
> !t.getStatus().equals(RequestResponseTransportStatus.WAITING))) {
>                               
>                               // Mark this sender bean so that we know that 
> the transport is unavailable, if the
>                               // bean is still stored.
>                               SenderBean bean = 
> senderBeanMgr.retrieve(senderBean.getMessageID());
>                               if(bean != null && bean.isTransportAvailable()) 
> {
>                                       bean.setTransportAvailable(false);
>                                       senderBeanMgr.update(bean);
>                               }
>                               
>                               // Commit the update
>                               if(transaction != null && 
> transaction.isActive()) transaction.commit();
>                               transaction = null;
>                               
>                               if (log.isDebugEnabled())
>                                       log.debug("Exit: SenderWorker::run, no 
> response transport for anonymous message");
>                               return;
>                       }
> to send a response message this code assumes a RequestResponseTransport 
> object and its state is waiting. 
> So I had to add a new MailRequestResponseTransport class and set it to 
> message context at the receiver. 
> will attach the patch.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to