You are viewing a plain text version of this content. The canonical link for it is here.
Posted to sandesha-dev@ws.apache.org by "Matt Lovett (JIRA)" <ji...@apache.org> on 2006/07/12 10:19:29 UTC

[jira] Created: (SANDESHA2-15) Enable Sandesha2 to send unreliable messages

Enable Sandesha2 to send unreliable messages
--------------------------------------------

         Key: SANDESHA2-15
         URL: http://issues.apache.org/jira/browse/SANDESHA2-15
     Project: Apache Sandesha2
        Type: New Feature

    Reporter: Matt Lovett
    Priority: Minor


Some clients will want to send a mix of reliable and unrealiable messages. Ideally, they should be able to do that by using a single axis2 configuration (with Sandesha engaged), by passing parameters into the invocation. I propose adding a new "UNRELIABLE_MESSAGE" property into SandeshaClientConstants, so that applications can disable RM for a given invocation. I'll put in some new unit tests that make sure that unreliable messages work for both 1 and 2-way messaging.

An alternative implementation is to set the internal APPLICATION_PROCESSING_DONE property onto the message context, but that seems like messing with Sandesha internals when a client constant would be more appropriate.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org


Re: [jira] Updated: (SANDESHA2-15) Enable Sandesha2 to send unreliable messages

Posted by Chamikara Jayalath <ch...@gmail.com>.
Hi Matt,

Can u please give some more info on this. When does the IBM copyright become
a requirement. Is it required when doing updates to the available Sandesha2
source files.

Chamikara


On 7/12/06, Matt Lovett (JIRA) <ji...@apache.org> wrote:
>
>      [ http://issues.apache.org/jira/browse/SANDESHA2-15?page=all ]
>
> Matt Lovett updated SANDESHA2-15:
> ---------------------------------
>
>     Attachment: NOTICE.txt
>
> Sorry folks, but I just noticed that the Sandesha distribution doesn't
> contain a NOTICE file to allow us to record the IBM copyright material that
> we are contributing. The Axis2 distribution put the NOTICE file in as an
> alternative to scattering copyright notices throughout the code.
>
> Please add this NOTICE.txt to the top of the sandesha2 java tree. Let me
> know if we should be discussing this some more!
>
> Thanks, Matt
>
> > Enable Sandesha2 to send unreliable messages
> > --------------------------------------------
> >
> >          Key: SANDESHA2-15
> >          URL: http://issues.apache.org/jira/browse/SANDESHA2-15
> >      Project: Apache Sandesha2
> >         Type: New Feature
>
> >     Reporter: Matt Lovett
> >     Priority: Minor
> >  Attachments: NOTICE.txt , Unreliable.patch
> >
> > Some clients will want to send a mix of reliable and unrealiable
> messages. Ideally, they should be able to do that by using a single axis2
> configuration (with Sandesha engaged), by passing parameters into the
> invocation. I propose adding a new "UNRELIABLE_MESSAGE" property into
> SandeshaClientConstants, so that applications can disable RM for a given
> invocation. I'll put in some new unit tests that make sure that unreliable
> messages work for both 1 and 2-way messaging.
> > An alternative implementation is to set the internal
> APPLICATION_PROCESSING_DONE property onto the message context, but that
> seems like messing with Sandesha internals when a client constant would be
> more appropriate.
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
>    http://issues.apache.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see:
>    http://www.atlassian.com/software/jira
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>
>

Re: [jira] Updated: (SANDESHA2-15) Enable Sandesha2 to send unreliable messages

Posted by Chamikara Jayalath <ch...@gmail.com>.
Hi Matt,

Can u please give some more info on this. When does the IBM copyright become
a requirement. Is it required when doing updates to the available Sandesha2
source files.

Chamikara


On 7/12/06, Matt Lovett (JIRA) <ji...@apache.org> wrote:
>
>      [ http://issues.apache.org/jira/browse/SANDESHA2-15?page=all ]
>
> Matt Lovett updated SANDESHA2-15:
> ---------------------------------
>
>     Attachment: NOTICE.txt
>
> Sorry folks, but I just noticed that the Sandesha distribution doesn't
> contain a NOTICE file to allow us to record the IBM copyright material that
> we are contributing. The Axis2 distribution put the NOTICE file in as an
> alternative to scattering copyright notices throughout the code.
>
> Please add this NOTICE.txt to the top of the sandesha2 java tree. Let me
> know if we should be discussing this some more!
>
> Thanks, Matt
>
> > Enable Sandesha2 to send unreliable messages
> > --------------------------------------------
> >
> >          Key: SANDESHA2-15
> >          URL: http://issues.apache.org/jira/browse/SANDESHA2-15
> >      Project: Apache Sandesha2
> >         Type: New Feature
>
> >     Reporter: Matt Lovett
> >     Priority: Minor
> >  Attachments: NOTICE.txt , Unreliable.patch
> >
> > Some clients will want to send a mix of reliable and unrealiable
> messages. Ideally, they should be able to do that by using a single axis2
> configuration (with Sandesha engaged), by passing parameters into the
> invocation. I propose adding a new "UNRELIABLE_MESSAGE" property into
> SandeshaClientConstants, so that applications can disable RM for a given
> invocation. I'll put in some new unit tests that make sure that unreliable
> messages work for both 1 and 2-way messaging.
> > An alternative implementation is to set the internal
> APPLICATION_PROCESSING_DONE property onto the message context, but that
> seems like messing with Sandesha internals when a client constant would be
> more appropriate.
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
>    http://issues.apache.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see:
>    http://www.atlassian.com/software/jira
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>
>

[jira] Updated: (SANDESHA2-15) Enable Sandesha2 to send unreliable messages

Posted by "Matt Lovett (JIRA)" <ji...@apache.org>.
     [ http://issues.apache.org/jira/browse/SANDESHA2-15?page=all ]

Matt Lovett updated SANDESHA2-15:
---------------------------------

    Attachment: NOTICE.txt

Sorry folks, but I just noticed that the Sandesha distribution doesn't contain a NOTICE file to allow us to record the IBM copyright material that we are contributing. The Axis2 distribution put the NOTICE file in as an alternative to scattering copyright notices throughout the code.

Please add this NOTICE.txt to the top of the sandesha2 java tree. Let me know if we should be discussing this some more!

Thanks, Matt

> Enable Sandesha2 to send unreliable messages
> --------------------------------------------
>
>          Key: SANDESHA2-15
>          URL: http://issues.apache.org/jira/browse/SANDESHA2-15
>      Project: Apache Sandesha2
>         Type: New Feature

>     Reporter: Matt Lovett
>     Priority: Minor
>  Attachments: NOTICE.txt, Unreliable.patch
>
> Some clients will want to send a mix of reliable and unrealiable messages. Ideally, they should be able to do that by using a single axis2 configuration (with Sandesha engaged), by passing parameters into the invocation. I propose adding a new "UNRELIABLE_MESSAGE" property into SandeshaClientConstants, so that applications can disable RM for a given invocation. I'll put in some new unit tests that make sure that unreliable messages work for both 1 and 2-way messaging.
> An alternative implementation is to set the internal APPLICATION_PROCESSING_DONE property onto the message context, but that seems like messing with Sandesha internals when a client constant would be more appropriate.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org


[jira] Updated: (SANDESHA2-15) Enable Sandesha2 to send unreliable messages

Posted by "Matt Lovett (JIRA)" <ji...@apache.org>.
     [ http://issues.apache.org/jira/browse/SANDESHA2-15?page=all ]

Matt Lovett updated SANDESHA2-15:
---------------------------------

    Attachment: Unreliable.patch

Patch that adds the new ClientConstant, and a unit test which exercises it.

> Enable Sandesha2 to send unreliable messages
> --------------------------------------------
>
>          Key: SANDESHA2-15
>          URL: http://issues.apache.org/jira/browse/SANDESHA2-15
>      Project: Apache Sandesha2
>         Type: New Feature

>     Reporter: Matt Lovett
>     Priority: Minor
>  Attachments: Unreliable.patch
>
> Some clients will want to send a mix of reliable and unrealiable messages. Ideally, they should be able to do that by using a single axis2 configuration (with Sandesha engaged), by passing parameters into the invocation. I propose adding a new "UNRELIABLE_MESSAGE" property into SandeshaClientConstants, so that applications can disable RM for a given invocation. I'll put in some new unit tests that make sure that unreliable messages work for both 1 and 2-way messaging.
> An alternative implementation is to set the internal APPLICATION_PROCESSING_DONE property onto the message context, but that seems like messing with Sandesha internals when a client constant would be more appropriate.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org


[jira] Updated: (SANDESHA2-15) Enable Sandesha2 to send unreliable messages

Posted by "Matt Lovett (JIRA)" <ji...@apache.org>.
     [ http://issues.apache.org/jira/browse/SANDESHA2-15?page=all ]

Matt Lovett updated SANDESHA2-15:
---------------------------------

    Attachment: NOTICE.txt

Sorry folks, but I just noticed that the Sandesha distribution doesn't contain a NOTICE file to allow us to record the IBM copyright material that we are contributing. The Axis2 distribution put the NOTICE file in as an alternative to scattering copyright notices throughout the code.

Please add this NOTICE.txt to the top of the sandesha2 java tree. Let me know if we should be discussing this some more!

Thanks, Matt

> Enable Sandesha2 to send unreliable messages
> --------------------------------------------
>
>          Key: SANDESHA2-15
>          URL: http://issues.apache.org/jira/browse/SANDESHA2-15
>      Project: Apache Sandesha2
>         Type: New Feature

>     Reporter: Matt Lovett
>     Priority: Minor
>  Attachments: NOTICE.txt, Unreliable.patch
>
> Some clients will want to send a mix of reliable and unrealiable messages. Ideally, they should be able to do that by using a single axis2 configuration (with Sandesha engaged), by passing parameters into the invocation. I propose adding a new "UNRELIABLE_MESSAGE" property into SandeshaClientConstants, so that applications can disable RM for a given invocation. I'll put in some new unit tests that make sure that unreliable messages work for both 1 and 2-way messaging.
> An alternative implementation is to set the internal APPLICATION_PROCESSING_DONE property onto the message context, but that seems like messing with Sandesha internals when a client constant would be more appropriate.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org


[jira] Updated: (SANDESHA2-15) Enable Sandesha2 to send unreliable messages

Posted by "Matt Lovett (JIRA)" <ji...@apache.org>.
     [ http://issues.apache.org/jira/browse/SANDESHA2-15?page=all ]

Matt Lovett updated SANDESHA2-15:
---------------------------------

    Attachment: Unreliable.patch

Patch that adds the new ClientConstant, and a unit test which exercises it.

> Enable Sandesha2 to send unreliable messages
> --------------------------------------------
>
>          Key: SANDESHA2-15
>          URL: http://issues.apache.org/jira/browse/SANDESHA2-15
>      Project: Apache Sandesha2
>         Type: New Feature

>     Reporter: Matt Lovett
>     Priority: Minor
>  Attachments: Unreliable.patch
>
> Some clients will want to send a mix of reliable and unrealiable messages. Ideally, they should be able to do that by using a single axis2 configuration (with Sandesha engaged), by passing parameters into the invocation. I propose adding a new "UNRELIABLE_MESSAGE" property into SandeshaClientConstants, so that applications can disable RM for a given invocation. I'll put in some new unit tests that make sure that unreliable messages work for both 1 and 2-way messaging.
> An alternative implementation is to set the internal APPLICATION_PROCESSING_DONE property onto the message context, but that seems like messing with Sandesha internals when a client constant would be more appropriate.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org


[jira] Resolved: (SANDESHA2-15) Enable Sandesha2 to send unreliable messages

Posted by "Chamikara Jayalath (JIRA)" <ji...@apache.org>.
     [ http://issues.apache.org/jira/browse/SANDESHA2-15?page=all ]

Chamikara Jayalath resolved SANDESHA2-15.
-----------------------------------------

    Resolution: Fixed

> Enable Sandesha2 to send unreliable messages
> --------------------------------------------
>
>                 Key: SANDESHA2-15
>                 URL: http://issues.apache.org/jira/browse/SANDESHA2-15
>             Project: Apache Sandesha2
>          Issue Type: New Feature
>            Reporter: Matt Lovett
>            Priority: Minor
>         Attachments: NOTICE.txt, Unreliable.patch
>
>
> Some clients will want to send a mix of reliable and unrealiable messages. Ideally, they should be able to do that by using a single axis2 configuration (with Sandesha engaged), by passing parameters into the invocation. I propose adding a new "UNRELIABLE_MESSAGE" property into SandeshaClientConstants, so that applications can disable RM for a given invocation. I'll put in some new unit tests that make sure that unreliable messages work for both 1 and 2-way messaging.
> An alternative implementation is to set the internal APPLICATION_PROCESSING_DONE property onto the message context, but that seems like messing with Sandesha internals when a client constant would be more appropriate.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org


[jira] Resolved: (SANDESHA2-15) Enable Sandesha2 to send unreliable messages

Posted by "Chamikara Jayalath (JIRA)" <ji...@apache.org>.
     [ http://issues.apache.org/jira/browse/SANDESHA2-15?page=all ]

Chamikara Jayalath resolved SANDESHA2-15.
-----------------------------------------

    Resolution: Fixed

> Enable Sandesha2 to send unreliable messages
> --------------------------------------------
>
>                 Key: SANDESHA2-15
>                 URL: http://issues.apache.org/jira/browse/SANDESHA2-15
>             Project: Apache Sandesha2
>          Issue Type: New Feature
>            Reporter: Matt Lovett
>            Priority: Minor
>         Attachments: NOTICE.txt, Unreliable.patch
>
>
> Some clients will want to send a mix of reliable and unrealiable messages. Ideally, they should be able to do that by using a single axis2 configuration (with Sandesha engaged), by passing parameters into the invocation. I propose adding a new "UNRELIABLE_MESSAGE" property into SandeshaClientConstants, so that applications can disable RM for a given invocation. I'll put in some new unit tests that make sure that unreliable messages work for both 1 and 2-way messaging.
> An alternative implementation is to set the internal APPLICATION_PROCESSING_DONE property onto the message context, but that seems like messing with Sandesha internals when a client constant would be more appropriate.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org