Hi folks, I appreciate what you are saying. Given the contribution is small (and the new file is almost a duplicate of one of the other tests) it's probably best to let sleeping dogs lie. How about applying the patch without introducing the NOTICE?
Thanks Matt "Davanum Srinivas" <[EMAIL PROTECTED]> wrote on 12/07/2006 19:05:35: > Matt, > > Typically we add the copyright to NOTICE when we get a significant > code contribution. In this JIRA issue, i see just 1 new file for a > test case. For Axis2, the reason was there was a big code drop with > brand new files for JAXWS. That just isn't the case here...Is someone > insisting on the copyright? Can you please ask them to chime in? Maybe > we should just not accept that 1 new file to avoid the situation? :) > > thanks, > dims > > On 7/12/06, Chamikara Jayalath <[EMAIL PROTECTED]> wrote: > > 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) <[EMAIL PROTECTED] > 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: > > [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > -- > Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) > > --------------------------------------------------------------------- > 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]
