Re: [axis2] Transport naming refactor

+1. Sanjiva. Glen Daniels wrote: OK, here's what I'm planning to do as a compromise position here. Let me know what you think. For now, I'm going to make the Module changes, and put the deprecated setters in for both Transports and Modules, but COMMENTED OUT. This will essentially force u

Re: [axis2] Transport naming refactor

Hi Deepal! Deepal Jayasinghe wrote: OK, here's what I'm planning to do as a compromise position here. Let me know what you think. For now, I'm going to make the Module changes, and put the deprecated setters in for both Transports and Modules, but COMMENTED OUT. I think we do not need to mar

Re: [axis2] Transport naming refactor

Hi Glen; > OK, here's what I'm planning to do as a compromise position here. Let > me know what you think. > > For now, I'm going to make the Module changes, and put the deprecated > setters in for both Transports and Modules, but COMMENTED OUT. I think we do not need to mark the method as depre

Re: [axis2] Transport naming refactor

OK, here's what I'm planning to do as a compromise position here. Let me know what you think. For now, I'm going to make the Module changes, and put the deprecated setters in for both Transports and Modules, but COMMENTED OUT. This will essentially force us within the Apache WS community to

Re: [axis2] Transport naming refactor

+1. Thanks Deepal Sanjiva Weerawarana wrote: > Given the inability to deprecate smoothly I suggest we take the hit > and put tags around this change in the release notes. > > Maybe we should put a section titled "Backwards Incompatible Changes" > (and make sure we explain why they are backwards

Re: [axis2] Transport naming refactor

I'm +1 on this. Do the deprecated setters and most importantly the deprecated engageModule(QName). Paul On 3/21/07, Glen Daniels <[EMAIL PROTECTED]> wrote: Hi Asankha: We can certainly add deprecated methods for the setters and the constructors, but not for getName() (since it would only diffe

Re: [axis2] Transport naming refactor

Given the inability to deprecate smoothly I suggest we take the hit and put tags around this change in the release notes. Maybe we should put a section titled "Backwards Incompatible Changes" (and make sure we explain why they are backwards incompatible). Big +1 for making both the changes p

Re: [axis2] Transport naming refactor

Hi Asankha: We can certainly add deprecated methods for the setters and the constructors, but not for getName() (since it would only differ by return type). That being the case, I figured just take the hit now rather than only having the set half of the API continue to work. Let me know if

Re: [axis2] Transport naming refactor

Glen I agree its good overall, but I am a bit concerned about a public API change if its without deprecation of the previous methods. Synapse can upgrade our code - but there may be other projects/code outside that may get broken. Just a concern.. asankha How about public void engageModul

[axis2] Transport naming refactor

Hi all! Please note/review this change: http://svn.apache.org/viewvc?view=rev&rev=520956 In it I refactored the name of transports (both in and out) to be a String instead of a QName, for simplicity and speed. Let me know if there are any issues with this. I know I still need to change the

Re: [axis2] Transport naming refactor

Hi Paul! Yay! :) How about public void engageModule(String modName) { engageModule(new QName(modName)); } Funny you should ask... How about I just do the same thing with Module names (Stringify them) right now and be done with it? --Glen

Re: [axis2] Transport naming refactor

Yay! How about public void engageModule(String modName) { engageModule(new QName(modName)); } Paul On 3/21/07, Glen Daniels <[EMAIL PROTECTED]> wrote: Hi all! Please note/review this change: http://svn.apache.org/viewvc?view=rev&rev=520956 In it I refactored the name of transports (both