Re: Synapse configuration namespace
Hi Jay, First of all sorry for not figuring out your first name earlier. I guess your first name is Jay. Well, I really appreciate your comments and feedback on this, and your views with your experience is much important for us. Thanks, Ruwan On Mon, Nov 22, 2010 at 6:51 PM, Jaeger, Jay - DOT jay.jae...@dot.wi.govwrote: I don't feel *that* strongly about it, and I won't actually be affected by your decision one way or the other. I just chose to speak based on 30+ years of experience in the industry. I was more providing input rather than intending to be a significant factor in your decision. Jay Jaeger -Original Message- From: Ruwan Linton [mailto:ruwan.lin...@gmail.com] Sent: Sunday, November 21, 2010 10:38 PM To: u...@synapse.apache.org Cc: dev@synapse.apache.org Subject: Re: Synapse configuration namespace OK We need to do the 2.0.0 release ASAP, it has been dragging way too much, and I don't want to delay it because of a namespace change and do not want to call another vote for this. Let me take your votes from this thread and try to summarize the decision on this. If I have interpreted this thread correctly, following people are for this NS change; Ruwan, Hiranya, Eric And even though after a long time there has been a huge oppose to this from the following people :-) Sanjiva, Paul, Jaeger I would consider Supun as (-0) with his statement, and Rajika to be neutral as I cannot interpret anything. With the above analysis, and the Apache way, I think we will have to revert the namespace change. I am working on the final documentation fixes for the release, once it is done I will revert the namespace change and remove the migration tool. My personal belief is that this is a step backwards and waste of a lot of work, with the migration tool and so forth. If you have any concerns over this decision please shout NOW and only NOW. Thanks, Ruwan On Mon, Nov 22, 2010 at 9:16 AM, Sanjiva Weerawarana sanj...@opensource.lkwrote: On Sun, Nov 21, 2010 at 9:22 PM, Hubert, Eric eric.hub...@foxmobile.com wrote: Well, I think I have to agree with Sanjiva's statement about the meaning of namespaces for an end user. I also do not know many people really caring about namespaces as long as those namespaces are not causing any troubles. Maybe one should not look at a namespace change independent of other changes. +1. If for whatever reason a configuration format and/or syntax has changed resulting in the possibility that some or even all the user's configurations will no longer work with a newer software version and users receive a migration tool to convert their configurations using the old format into a new format, users also do not care whether there is a namespace change or not (as long as the migration tool works properly). API changes breaking existing custom extensions (in the case of Synapse primarily mediators) or (even more critical) changed runtime behaviour should normally affect end users much more. During the too long time without any release since the last release of Synapse in June 2008 (so about two and a half years ago) I'm pretty sure any of the above will be the case. Right, v2.0 indicates that there are major, incompatible changes in the product. Namespace change is an unnecessary thing to support that as for most people the silly namespace thing is something to gloss over (and a PITA in general). In fact, I no longer believe that XML languages should use namespaces at all .. only an extreme case where the language is meant to be transparently embedded in other languages is a namespace name a necessity. Just use unqualified XML syntax and make life easier! Now, if you want to support a model of ignoring the namespace I'd totally +1 that! Qualified names can still be used for extensions of course; that makes crystal clear when one is using an extension vs. the core. Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder, Director Chief Scientist; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2; http://wso2.com/ Founder Director; Thinkcube Systems; http://www.thinkcube.com/ Member; Apache Software Foundation; http://www.apache.org/ Member; Sahana Software Foundation; http://www.sahanafoundation.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ -- Ruwan Linton Software Architect Product Manager, WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org Lean . Enterprise . Middleware phone: +1 408 754 7388 ext 51789 email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://blog.ruwan.org linkedin: http://www.linkedin.com/in/ruwanlinton google: http://www.google.com/profiles/ruwan.linton tweet: http://twitter.com/ruwanlinton -- Ruwan Linton Software Architect Product Manager, WSO2
RE: Synapse configuration namespace
I don't feel *that* strongly about it, and I won't actually be affected by your decision one way or the other. I just chose to speak based on 30+ years of experience in the industry. I was more providing input rather than intending to be a significant factor in your decision. Jay Jaeger -Original Message- From: Ruwan Linton [mailto:ruwan.lin...@gmail.com] Sent: Sunday, November 21, 2010 10:38 PM To: u...@synapse.apache.org Cc: dev@synapse.apache.org Subject: Re: Synapse configuration namespace OK We need to do the 2.0.0 release ASAP, it has been dragging way too much, and I don't want to delay it because of a namespace change and do not want to call another vote for this. Let me take your votes from this thread and try to summarize the decision on this. If I have interpreted this thread correctly, following people are for this NS change; Ruwan, Hiranya, Eric And even though after a long time there has been a huge oppose to this from the following people :-) Sanjiva, Paul, Jaeger I would consider Supun as (-0) with his statement, and Rajika to be neutral as I cannot interpret anything. With the above analysis, and the Apache way, I think we will have to revert the namespace change. I am working on the final documentation fixes for the release, once it is done I will revert the namespace change and remove the migration tool. My personal belief is that this is a step backwards and waste of a lot of work, with the migration tool and so forth. If you have any concerns over this decision please shout NOW and only NOW. Thanks, Ruwan On Mon, Nov 22, 2010 at 9:16 AM, Sanjiva Weerawarana sanj...@opensource.lkwrote: On Sun, Nov 21, 2010 at 9:22 PM, Hubert, Eric eric.hub...@foxmobile.com wrote: Well, I think I have to agree with Sanjiva's statement about the meaning of namespaces for an end user. I also do not know many people really caring about namespaces as long as those namespaces are not causing any troubles. Maybe one should not look at a namespace change independent of other changes. +1. If for whatever reason a configuration format and/or syntax has changed resulting in the possibility that some or even all the user's configurations will no longer work with a newer software version and users receive a migration tool to convert their configurations using the old format into a new format, users also do not care whether there is a namespace change or not (as long as the migration tool works properly). API changes breaking existing custom extensions (in the case of Synapse primarily mediators) or (even more critical) changed runtime behaviour should normally affect end users much more. During the too long time without any release since the last release of Synapse in June 2008 (so about two and a half years ago) I'm pretty sure any of the above will be the case. Right, v2.0 indicates that there are major, incompatible changes in the product. Namespace change is an unnecessary thing to support that as for most people the silly namespace thing is something to gloss over (and a PITA in general). In fact, I no longer believe that XML languages should use namespaces at all .. only an extreme case where the language is meant to be transparently embedded in other languages is a namespace name a necessity. Just use unqualified XML syntax and make life easier! Now, if you want to support a model of ignoring the namespace I'd totally +1 that! Qualified names can still be used for extensions of course; that makes crystal clear when one is using an extension vs. the core. Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder, Director Chief Scientist; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2; http://wso2.com/ Founder Director; Thinkcube Systems; http://www.thinkcube.com/ Member; Apache Software Foundation; http://www.apache.org/ Member; Sahana Software Foundation; http://www.sahanafoundation.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ -- Ruwan Linton Software Architect Product Manager, WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org Lean . Enterprise . Middleware phone: +1 408 754 7388 ext 51789 email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://blog.ruwan.org linkedin: http://www.linkedin.com/in/ruwanlinton google: http://www.google.com/profiles/ruwan.linton tweet: http://twitter.com/ruwanlinton - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
Re: Synapse configuration namespace
I'm +1 for a namespace change if we have changed the semantics of the synapse configuration language at a broader level. But since we haven't done any major change to the configuration language im 0 on this. So my opinion solely depend on what users will think and how they will get affected. Thanks, Supun.. On Sun, Nov 21, 2010 at 7:35 AM, Ruwan Linton ruwan.lin...@gmail.comwrote: I found more incompatible changes :-( https://issues.apache.org/jira/browse/SYNAPSE-693?focusedCommentId=12934217page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12934217 I do not understand why you are opposing to changing the namespace with 2.0 release, while we have this sort of dangerous incompatibilities. Ruwan On Sun, Nov 21, 2010 at 6:43 AM, Sanjiva Weerawarana sanj...@opensource.lk wrote: On Sat, Nov 20, 2010 at 8:58 PM, Ruwan Linton ruwan.lin...@gmail.comwrote: Also, in general using namespaces to version XML schemas is generally considered bad practice. I don't think we are doing a versioning of the synapse configuration schema with the namespace, anyway most of Then what are you achieving with the namespace name change? the other schemas, like (WSDL, XSLT) have different namespaces for different versions. :-( Not correct .. WSDL 1.1 to 2.0 does do but in that case the languages and semantics are majorly different. The 2.0 language was also delivered by a whole different group instead of a small private club. XSLT was intentionally, carefully designed for forwards compatibility and has a version attribute: http://www.w3.org/TR/xslt#forwards http://www.w3.org/TR/xslt#forwardsThis was a James Clark masterpiece. Now see XSLT 2.0's section on backwards compatibility: http://www.w3.org/TR/xslt20/#backwards http://www.w3.org/TR/xslt20/#backwards Also there is more than the domain name or being a new TLP out from WS for this namespace change, which is, that Synapse is more than web services and it can handle many things apart from web services, as you know web services is just one connector among many other connectors for mediation, and that is why I do not want to limit the namespace to the ws.apache.org. Yes Synapse is much more than Web services. However, IMO, most users don't bother to give any quality time to looking at the namespace and making judgments based on that. I'm done pushing my position on this topic :). Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder, Director Chief Scientist; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2; http://wso2.com/ Founder Director; Thinkcube Systems; http://www.thinkcube.com/ Member; Apache Software Foundation; http://www.apache.org/ Member; Sahana Software Foundation; http://www.sahanafoundation.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ -- Ruwan Linton Software Architect Product Manager, WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org Lean . Enterprise . Middleware phone: +1 408 754 7388 ext 51789 email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://blog.ruwan.org linkedin: http://www.linkedin.com/in/ruwanlinton google: http://www.google.com/profiles/ruwan.linton tweet: http://twitter.com/ruwanlinton -- Technical Lead, WSO2 Inc http://wso2.org supunk.blogspot.com
RE: Synapse configuration namespace
Well, I think I have to agree with Sanjiva’s statement about the meaning of namespaces for an end user. I also do not know many people really caring about namespaces as long as those namespaces are not causing any troubles. Maybe one should not look at a namespace change independent of other changes. If for whatever reason a configuration format and/or syntax has changed resulting in the possibility that some or even all the user’s configurations will no longer work with a newer software version and users receive a migration tool to convert their configurations using the old format into a new format, users also do not care whether there is a namespace change or not (as long as the migration tool works properly). API changes breaking existing custom extensions (in the case of Synapse primarily “mediators”) or (even more critical) changed runtime behaviour should normally affect end users much more. During the too long time without any release since the last release of Synapse in June 2008 (so about two and a half years ago) I’m pretty sure any of the above will be the case. Regards, Eric From: Supun Kamburugamuva [mailto:supu...@gmail.com] Sent: Sunday, November 21, 2010 3:25 PM To: dev@synapse.apache.org Cc: u...@synapse.apache.org Subject: Re: Synapse configuration namespace I'm +1 for a namespace change if we have changed the semantics of the synapse configuration language at a broader level. But since we haven't done any major change to the configuration language im 0 on this. So my opinion solely depend on what users will think and how they will get affected. Thanks, Supun.. On Sun, Nov 21, 2010 at 7:35 AM, Ruwan Linton ruwan.lin...@gmail.commailto:ruwan.lin...@gmail.com wrote: I found more incompatible changes :-( https://issues.apache.org/jira/browse/SYNAPSE-693?focusedCommentId=12934217page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12934217 I do not understand why you are opposing to changing the namespace with 2.0 release, while we have this sort of dangerous incompatibilities. Ruwan On Sun, Nov 21, 2010 at 6:43 AM, Sanjiva Weerawarana sanj...@opensource.lkmailto:sanj...@opensource.lk wrote: On Sat, Nov 20, 2010 at 8:58 PM, Ruwan Linton ruwan.lin...@gmail.commailto:ruwan.lin...@gmail.com wrote: Also, in general using namespaces to version XML schemas is generally considered bad practice. I don't think we are doing a versioning of the synapse configuration schema with the namespace, anyway most of Then what are you achieving with the namespace name change? the other schemas, like (WSDL, XSLT) have different namespaces for different versions. :-( Not correct .. WSDL 1.1 to 2.0 does do but in that case the languages and semantics are majorly different. The 2.0 language was also delivered by a whole different group instead of a small private club. XSLT was intentionally, carefully designed for forwards compatibility and has a version attribute: http://www.w3.org/TR/xslt#forwards http://www.w3.org/TR/xslt#forwardsThis was a James Clark masterpiece. Now see XSLT 2.0's section on backwards compatibility: http://www.w3.org/TR/xslt20/#backwards http://www.w3.org/TR/xslt20/#backwards Also there is more than the domain name or being a new TLP out from WS for this namespace change, which is, that Synapse is more than web services and it can handle many things apart from web services, as you know web services is just one connector among many other connectors for mediation, and that is why I do not want to limit the namespace to the ws.apache.orghttp://ws.apache.org. Yes Synapse is much more than Web services. However, IMO, most users don't bother to give any quality time to looking at the namespace and making judgments based on that. I'm done pushing my position on this topic :). Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder, Director Chief Scientist; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2; http://wso2.com/ Founder Director; Thinkcube Systems; http://www.thinkcube.com/ Member; Apache Software Foundation; http://www.apache.org/ Member; Sahana Software Foundation; http://www.sahanafoundation.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ -- Ruwan Linton Software Architect Product Manager, WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org Lean . Enterprise . Middleware phone: +1 408 754 7388 ext 51789 email: ru...@wso2.commailto:ru...@wso2.com; cell: +94 77 341 3097 blog: http://blog.ruwan.org linkedin: http://www.linkedin.com/in/ruwanlinton google: http://www.google.com/profiles/ruwan.linton tweet: http://twitter.com/ruwanlinton -- Technical Lead, WSO2 Inc http://wso2.org supunk.blogspot.comhttp://supunk.blogspot.com
Re: Synapse configuration namespace
On Sun, Nov 21, 2010 at 9:22 PM, Hubert, Eric eric.hub...@foxmobile.comwrote: Well, I think I have to agree with Sanjiva’s statement about the meaning of namespaces for an end user. I also do not know many people really caring about namespaces as long as those namespaces are not causing any troubles. Maybe one should not look at a namespace change independent of other changes. +1. If for whatever reason a configuration format and/or syntax has changed resulting in the possibility that some or even all the user’s configurations will no longer work with a newer software version and users receive a migration tool to convert their configurations using the old format into a new format, users also do not care whether there is a namespace change or not (as long as the migration tool works properly). API changes breaking existing custom extensions (in the case of Synapse primarily “mediators”) or (even more critical) changed runtime behaviour should normally affect end users much more. During the too long time without any release since the last release of Synapse in June 2008 (so about two and a half years ago) I’m pretty sure any of the above will be the case. Right, v2.0 indicates that there are major, incompatible changes in the product. Namespace change is an unnecessary thing to support that as for most people the silly namespace thing is something to gloss over (and a PITA in general). In fact, I no longer believe that XML languages should use namespaces at all .. only an extreme case where the language is meant to be transparently embedded in other languages is a namespace name a necessity. Just use unqualified XML syntax and make life easier! Now, if you want to support a model of ignoring the namespace I'd totally +1 that! Qualified names can still be used for extensions of course; that makes crystal clear when one is using an extension vs. the core. Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder, Director Chief Scientist; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2; http://wso2.com/ Founder Director; Thinkcube Systems; http://www.thinkcube.com/ Member; Apache Software Foundation; http://www.apache.org/ Member; Sahana Software Foundation; http://www.sahanafoundation.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/
Re: Synapse configuration namespace
OK We need to do the 2.0.0 release ASAP, it has been dragging way too much, and I don't want to delay it because of a namespace change and do not want to call another vote for this. Let me take your votes from this thread and try to summarize the decision on this. If I have interpreted this thread correctly, following people are for this NS change; Ruwan, Hiranya, Eric And even though after a long time there has been a huge oppose to this from the following people :-) Sanjiva, Paul, Jaeger I would consider Supun as (-0) with his statement, and Rajika to be neutral as I cannot interpret anything. With the above analysis, and the Apache way, I think we will have to revert the namespace change. I am working on the final documentation fixes for the release, once it is done I will revert the namespace change and remove the migration tool. My personal belief is that this is a step backwards and waste of a lot of work, with the migration tool and so forth. If you have any concerns over this decision please shout NOW and only NOW. Thanks, Ruwan On Mon, Nov 22, 2010 at 9:16 AM, Sanjiva Weerawarana sanj...@opensource.lkwrote: On Sun, Nov 21, 2010 at 9:22 PM, Hubert, Eric eric.hub...@foxmobile.com wrote: Well, I think I have to agree with Sanjiva’s statement about the meaning of namespaces for an end user. I also do not know many people really caring about namespaces as long as those namespaces are not causing any troubles. Maybe one should not look at a namespace change independent of other changes. +1. If for whatever reason a configuration format and/or syntax has changed resulting in the possibility that some or even all the user’s configurations will no longer work with a newer software version and users receive a migration tool to convert their configurations using the old format into a new format, users also do not care whether there is a namespace change or not (as long as the migration tool works properly). API changes breaking existing custom extensions (in the case of Synapse primarily “mediators”) or (even more critical) changed runtime behaviour should normally affect end users much more. During the too long time without any release since the last release of Synapse in June 2008 (so about two and a half years ago) I’m pretty sure any of the above will be the case. Right, v2.0 indicates that there are major, incompatible changes in the product. Namespace change is an unnecessary thing to support that as for most people the silly namespace thing is something to gloss over (and a PITA in general). In fact, I no longer believe that XML languages should use namespaces at all .. only an extreme case where the language is meant to be transparently embedded in other languages is a namespace name a necessity. Just use unqualified XML syntax and make life easier! Now, if you want to support a model of ignoring the namespace I'd totally +1 that! Qualified names can still be used for extensions of course; that makes crystal clear when one is using an extension vs. the core. Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder, Director Chief Scientist; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2; http://wso2.com/ Founder Director; Thinkcube Systems; http://www.thinkcube.com/ Member; Apache Software Foundation; http://www.apache.org/ Member; Sahana Software Foundation; http://www.sahanafoundation.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ -- Ruwan Linton Software Architect Product Manager, WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org Lean . Enterprise . Middleware phone: +1 408 754 7388 ext 51789 email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://blog.ruwan.org linkedin: http://www.linkedin.com/in/ruwanlinton google: http://www.google.com/profiles/ruwan.linton tweet: http://twitter.com/ruwanlinton
Re: Synapse configuration namespace
On Mon, Nov 22, 2010 at 10:07 AM, Ruwan Linton ruwan.lin...@gmail.com wrote: OK We need to do the 2.0.0 release ASAP, it has been dragging way too much, and I don't want to delay it because of a namespace change and do not want to call another vote for this. Let me take your votes from this thread and try to summarize the decision on this. If I have interpreted this thread correctly, following people are for this NS change; Ruwan, Hiranya, Eric And even though after a long time there has been a huge oppose to this from the following people :-) Sanjiva, Paul, Jaeger I would consider Supun as (-0) with his statement, and Rajika to be neutral as I cannot interpret anything. With the above analysis, and the Apache way, I think we will have to revert the namespace change. I am working on the final documentation fixes for the release, once it is done I will revert the namespace change and remove the migration tool. My personal belief is that this is a step backwards and waste of a lot of work, with the migration tool and so forth. If you have any concerns over this decision please shout NOW and only NOW. I'm ok with reverting Thanks, Hiranya Thanks, Ruwan On Mon, Nov 22, 2010 at 9:16 AM, Sanjiva Weerawarana sanj...@opensource.lkwrote: On Sun, Nov 21, 2010 at 9:22 PM, Hubert, Eric eric.hub...@foxmobile.com wrote: Well, I think I have to agree with Sanjiva’s statement about the meaning of namespaces for an end user. I also do not know many people really caring about namespaces as long as those namespaces are not causing any troubles. Maybe one should not look at a namespace change independent of other changes. +1. If for whatever reason a configuration format and/or syntax has changed resulting in the possibility that some or even all the user’s configurations will no longer work with a newer software version and users receive a migration tool to convert their configurations using the old format into a new format, users also do not care whether there is a namespace change or not (as long as the migration tool works properly). API changes breaking existing custom extensions (in the case of Synapse primarily “mediators”) or (even more critical) changed runtime behaviour should normally affect end users much more. During the too long time without any release since the last release of Synapse in June 2008 (so about two and a half years ago) I’m pretty sure any of the above will be the case. Right, v2.0 indicates that there are major, incompatible changes in the product. Namespace change is an unnecessary thing to support that as for most people the silly namespace thing is something to gloss over (and a PITA in general). In fact, I no longer believe that XML languages should use namespaces at all .. only an extreme case where the language is meant to be transparently embedded in other languages is a namespace name a necessity. Just use unqualified XML syntax and make life easier! Now, if you want to support a model of ignoring the namespace I'd totally +1 that! Qualified names can still be used for extensions of course; that makes crystal clear when one is using an extension vs. the core. Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder, Director Chief Scientist; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2; http://wso2.com/ Founder Director; Thinkcube Systems; http://www.thinkcube.com/ Member; Apache Software Foundation; http://www.apache.org/ Member; Sahana Software Foundation; http://www.sahanafoundation.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ -- Ruwan Linton Software Architect Product Manager, WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org Lean . Enterprise . Middleware phone: +1 408 754 7388 ext 51789 email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://blog.ruwan.org linkedin: http://www.linkedin.com/in/ruwanlinton google: http://www.google.com/profiles/ruwan.linton tweet: http://twitter.com/ruwanlinton -- Hiranya Jayathilaka Senior Software Engineer; WSO2 Inc.; http://wso2.org E-mail: hira...@wso2.com; Mobile: +94 77 633 3491 Blog: http://techfeast-hiranya.blogspot.com - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
Re: Synapse configuration namespace
Thanks a lot Eric for the feedback. Folks, I am done with the schemas and the synapse configuration is now interpreted with a schema. now we need to come to a decision on the namespace to do the release. We have API changes on the mediator API too, so I would go for this now and be done with it. Thanks, Ruwan On Mon, Nov 15, 2010 at 11:59 PM, Hubert, Eric eric.hub...@foxmobile.comwrote: First of all, sorry guys for my late response as well. I have been quite busy. I understood Synapse 2.0 to be the point which changes config and api rather radically, resulting in incompatibilities (reason for the major version bump). Having and supporting xml schema definitions alone seems to be a big change to me. If I'm not wrong Ruwan first wrote about Synapse 2.0 more than half a year ago. There has been a lot of time to object regarding some of the involved changes, but nobody did so. I further understood there will be a migration tool supporting users to convert there existing config files into the new format, which sounds like a very good idea. In addition from an end user perspective I would additionally wish for a small guide describing the api changes affecting custom mediators. Users need to be aware, that there will be more effort involved in upgrading (depending on the amount of customization/extension they have done to the core project based on the apis). To me one of the biggest troubles with Synapse is that a developer has to guess which part of the api is public and safe to use and which part is part of the internals and should rather not be used at all. I do not agree with those demanding backward compatibility of any software product over the whole lifetime. This mostly leads to bad design and code at some point. One should always develop with backward compatibility in mind and only break compatibility if there is a good reason to do so. Of course at this point there will always been a lot of discussion. I'm also a big fan of any software versioning scheme which immediately reflects those changes as such (e.g. it needs a major version to introduce api incompatibilities of any kind - including configuration). I also prefer if any incompatible changes (at least to the public api/configuration) will be documented as such. So to put it short, I agree with what Ruwan said - from both developer and end user perspective. Although I'm certainly not happy having to adjust mediator code before moving the next major version I'd rather take this effort, than having to help hunting bugs in overly complicated code resulting from trying to avoid incompatibilities while adding new major features. Regards, Eric -Original Message- From: Ruwan Linton [mailto:ruwan.lin...@gmail.com] Sent: Monday, November 08, 2010 4:10 AM To: dev@synapse.apache.org Cc: u...@synapse.apache.org Subject: Re: Synapse configuration namespace Since we were planing for a 2.0 release, I thought it is OK to do backwards incompatible changes and document them properly. Well we have some changes in the API as well, which will affect the existing mediators and so forth. Do you think we should keep the ability to run the 1.x mediators as it is on the 2.0 as well. I would like to hear users and other dev feedback on this... please raise your view on this. Thanks, Ruwan On Mon, Nov 8, 2010 at 6:41 AM, Hiranya Jayathilaka hiranya...@gmail.comwrote: Hi Paul, On Mon, Nov 8, 2010 at 4:50 AM, Paul Fremantle pzf...@gmail.com wrote: I don't see the point in changing the namespace unless there is an incompatibility at the core. We wrote the model to be very flexible. Having a migration XSLT is great, but it seems to me a fix for something that is tricky. Also, we spent a lot of effort on backwards compatibility: for example, I would have loved to have added new methods to the messagecontext, but put them into helper classes to avoid breaking existing mediators. At some point I think we will need to change the config radically, and that is the time to make a breaking change. I propose we make the code read the old config as well as the new (as much as possible) and print a deprecation statement. We should be able to always write the new config, so that users serializing their config will move to the new one. I don't think we can support both namespaces at once without making a huge amount of changes/additions to the code. Axiom doesn't give too many options in this space. We have all the namespaces, local names and QNames defined as global constants in the code. So how about this? By default we expect configurations to have the new namespace. But if somebody wants to load a configuration with the old namespace, he has to first set a special property in synapse.properties or as a system property. eg: -DuseOldNamespace=true We can easily
Re: Synapse configuration namespace
Ruwan what are the incompatible changes? Eric, from my understanding the namespace change was motivated by going from ws.apache.org/synapse to synapse.apache.org rather than significant incompatible changes. I'm totally +1 for not forcing backwards compatibility at all costs but if there are no significant changes then all you're doing is causing user pain. Also, in general using namespaces to version XML schemas is generally considered bad practice. I don't have a reference handy for that but can dig stuff up if needed. Sanjiva. On Sat, Nov 20, 2010 at 6:14 PM, Ruwan Linton ruwan.lin...@gmail.comwrote: Thanks a lot Eric for the feedback. Folks, I am done with the schemas and the synapse configuration is now interpreted with a schema. now we need to come to a decision on the namespace to do the release. We have API changes on the mediator API too, so I would go for this now and be done with it. Thanks, Ruwan On Mon, Nov 15, 2010 at 11:59 PM, Hubert, Eric eric.hub...@foxmobile.comwrote: First of all, sorry guys for my late response as well. I have been quite busy. I understood Synapse 2.0 to be the point which changes config and api rather radically, resulting in incompatibilities (reason for the major version bump). Having and supporting xml schema definitions alone seems to be a big change to me. If I'm not wrong Ruwan first wrote about Synapse 2.0 more than half a year ago. There has been a lot of time to object regarding some of the involved changes, but nobody did so. I further understood there will be a migration tool supporting users to convert there existing config files into the new format, which sounds like a very good idea. In addition from an end user perspective I would additionally wish for a small guide describing the api changes affecting custom mediators. Users need to be aware, that there will be more effort involved in upgrading (depending on the amount of customization/extension they have done to the core project based on the apis). To me one of the biggest troubles with Synapse is that a developer has to guess which part of the api is public and safe to use and which part is part of the internals and should rather not be used at all. I do not agree with those demanding backward compatibility of any software product over the whole lifetime. This mostly leads to bad design and code at some point. One should always develop with backward compatibility in mind and only break compatibility if there is a good reason to do so. Of course at this point there will always been a lot of discussion. I'm also a big fan of any software versioning scheme which immediately reflects those changes as such (e.g. it needs a major version to introduce api incompatibilities of any kind - including configuration). I also prefer if any incompatible changes (at least to the public api/configuration) will be documented as such. So to put it short, I agree with what Ruwan said - from both developer and end user perspective. Although I'm certainly not happy having to adjust mediator code before moving the next major version I'd rather take this effort, than having to help hunting bugs in overly complicated code resulting from trying to avoid incompatibilities while adding new major features. Regards, Eric -Original Message- From: Ruwan Linton [mailto:ruwan.lin...@gmail.com] Sent: Monday, November 08, 2010 4:10 AM To: dev@synapse.apache.org Cc: u...@synapse.apache.org Subject: Re: Synapse configuration namespace Since we were planing for a 2.0 release, I thought it is OK to do backwards incompatible changes and document them properly. Well we have some changes in the API as well, which will affect the existing mediators and so forth. Do you think we should keep the ability to run the 1.x mediators as it is on the 2.0 as well. I would like to hear users and other dev feedback on this... please raise your view on this. Thanks, Ruwan On Mon, Nov 8, 2010 at 6:41 AM, Hiranya Jayathilaka hiranya...@gmail.comwrote: Hi Paul, On Mon, Nov 8, 2010 at 4:50 AM, Paul Fremantle pzf...@gmail.com wrote: I don't see the point in changing the namespace unless there is an incompatibility at the core. We wrote the model to be very flexible. Having a migration XSLT is great, but it seems to me a fix for something that is tricky. Also, we spent a lot of effort on backwards compatibility: for example, I would have loved to have added new methods to the messagecontext, but put them into helper classes to avoid breaking existing mediators. At some point I think we will need to change the config radically, and that is the time to make a breaking change. I propose we make the code read the old config as well as the new (as much as possible) and print a deprecation statement. We should be able to always write the new config, so that users
Re: Synapse configuration namespace
On Sat, Nov 20, 2010 at 8:05 PM, Sanjiva Weerawarana sanj...@opensource.lkwrote: Ruwan what are the incompatible changes? If you extend from the AbstracMediatorFactory/Serializer to implement a custom mediator factory/serializer, which is considered as the best practice, you need to change the method from createMediator to createSpecificMediator and so forth, as the createMediator method is final. From the configuration front there are no major changes, but filter mediator configuration requires a then element to present for the filter matching mediator set since we have introduced an else condition as well. Eric, from my understanding the namespace change was motivated by going from ws.apache.org/synapse to synapse.apache.org rather than significant incompatible changes. I'm totally +1 for not forcing backwards compatibility at all costs but if there are no significant changes then all you're doing is causing user pain. Also, in general using namespaces to version XML schemas is generally considered bad practice. I don't think we are doing a versioning of the synapse configuration schema with the namespace, anyway most of the other schemas, like (WSDL, XSLT) have different namespaces for different versions. :-( Also there is more than the domain name or being a new TLP out from WS for this namespace change, which is, that Synapse is more than web services and it can handle many things apart from web services, as you know web services is just one connector among many other connectors for mediation, and that is why I do not want to limit the namespace to the ws.apache.org. Thanks, Ruwan I don't have a reference handy for that but can dig stuff up if needed. Sanjiva. On Sat, Nov 20, 2010 at 6:14 PM, Ruwan Linton ruwan.lin...@gmail.comwrote: Thanks a lot Eric for the feedback. Folks, I am done with the schemas and the synapse configuration is now interpreted with a schema. now we need to come to a decision on the namespace to do the release. We have API changes on the mediator API too, so I would go for this now and be done with it. Thanks, Ruwan On Mon, Nov 15, 2010 at 11:59 PM, Hubert, Eric eric.hub...@foxmobile.com wrote: First of all, sorry guys for my late response as well. I have been quite busy. I understood Synapse 2.0 to be the point which changes config and api rather radically, resulting in incompatibilities (reason for the major version bump). Having and supporting xml schema definitions alone seems to be a big change to me. If I'm not wrong Ruwan first wrote about Synapse 2.0 more than half a year ago. There has been a lot of time to object regarding some of the involved changes, but nobody did so. I further understood there will be a migration tool supporting users to convert there existing config files into the new format, which sounds like a very good idea. In addition from an end user perspective I would additionally wish for a small guide describing the api changes affecting custom mediators. Users need to be aware, that there will be more effort involved in upgrading (depending on the amount of customization/extension they have done to the core project based on the apis). To me one of the biggest troubles with Synapse is that a developer has to guess which part of the api is public and safe to use and which part is part of the internals and should rather not be used at all. I do not agree with those demanding backward compatibility of any software product over the whole lifetime. This mostly leads to bad design and code at some point. One should always develop with backward compatibility in mind and only break compatibility if there is a good reason to do so. Of course at this point there will always been a lot of discussion. I'm also a big fan of any software versioning scheme which immediately reflects those changes as such (e.g. it needs a major version to introduce api incompatibilities of any kind - including configuration). I also prefer if any incompatible changes (at least to the public api/configuration) will be documented as such. So to put it short, I agree with what Ruwan said - from both developer and end user perspective. Although I'm certainly not happy having to adjust mediator code before moving the next major version I'd rather take this effort, than having to help hunting bugs in overly complicated code resulting from trying to avoid incompatibilities while adding new major features. Regards, Eric -Original Message- From: Ruwan Linton [mailto:ruwan.lin...@gmail.com] Sent: Monday, November 08, 2010 4:10 AM To: dev@synapse.apache.org Cc: u...@synapse.apache.org Subject: Re: Synapse configuration namespace Since we were planing for a 2.0 release, I thought it is OK to do backwards incompatible changes and document them properly. Well we have some changes in the API as well, which will affect the existing mediators and so forth. Do you think we
Re: Synapse configuration namespace
On Sat, Nov 20, 2010 at 8:58 PM, Ruwan Linton ruwan.lin...@gmail.comwrote: Also, in general using namespaces to version XML schemas is generally considered bad practice. I don't think we are doing a versioning of the synapse configuration schema with the namespace, anyway most of Then what are you achieving with the namespace name change? the other schemas, like (WSDL, XSLT) have different namespaces for different versions. :-( Not correct .. WSDL 1.1 to 2.0 does do but in that case the languages and semantics are majorly different. The 2.0 language was also delivered by a whole different group instead of a small private club. XSLT was intentionally, carefully designed for forwards compatibility and has a version attribute: http://www.w3.org/TR/xslt#forwards http://www.w3.org/TR/xslt#forwardsThis was a James Clark masterpiece. Now see XSLT 2.0's section on backwards compatibility: http://www.w3.org/TR/xslt20/#backwards http://www.w3.org/TR/xslt20/#backwards Also there is more than the domain name or being a new TLP out from WS for this namespace change, which is, that Synapse is more than web services and it can handle many things apart from web services, as you know web services is just one connector among many other connectors for mediation, and that is why I do not want to limit the namespace to the ws.apache.org. Yes Synapse is much more than Web services. However, IMO, most users don't bother to give any quality time to looking at the namespace and making judgments based on that. I'm done pushing my position on this topic :). Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder, Director Chief Scientist; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2; http://wso2.com/ Founder Director; Thinkcube Systems; http://www.thinkcube.com/ Member; Apache Software Foundation; http://www.apache.org/ Member; Sahana Software Foundation; http://www.sahanafoundation.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/
Re: Synapse configuration namespace
I found more incompatible changes :-( https://issues.apache.org/jira/browse/SYNAPSE-693?focusedCommentId=12934217page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12934217 I do not understand why you are opposing to changing the namespace with 2.0 release, while we have this sort of dangerous incompatibilities. Ruwan On Sun, Nov 21, 2010 at 6:43 AM, Sanjiva Weerawarana sanj...@opensource.lkwrote: On Sat, Nov 20, 2010 at 8:58 PM, Ruwan Linton ruwan.lin...@gmail.comwrote: Also, in general using namespaces to version XML schemas is generally considered bad practice. I don't think we are doing a versioning of the synapse configuration schema with the namespace, anyway most of Then what are you achieving with the namespace name change? the other schemas, like (WSDL, XSLT) have different namespaces for different versions. :-( Not correct .. WSDL 1.1 to 2.0 does do but in that case the languages and semantics are majorly different. The 2.0 language was also delivered by a whole different group instead of a small private club. XSLT was intentionally, carefully designed for forwards compatibility and has a version attribute: http://www.w3.org/TR/xslt#forwards http://www.w3.org/TR/xslt#forwardsThis was a James Clark masterpiece. Now see XSLT 2.0's section on backwards compatibility: http://www.w3.org/TR/xslt20/#backwards http://www.w3.org/TR/xslt20/#backwards Also there is more than the domain name or being a new TLP out from WS for this namespace change, which is, that Synapse is more than web services and it can handle many things apart from web services, as you know web services is just one connector among many other connectors for mediation, and that is why I do not want to limit the namespace to the ws.apache.org. Yes Synapse is much more than Web services. However, IMO, most users don't bother to give any quality time to looking at the namespace and making judgments based on that. I'm done pushing my position on this topic :). Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder, Director Chief Scientist; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2; http://wso2.com/ Founder Director; Thinkcube Systems; http://www.thinkcube.com/ Member; Apache Software Foundation; http://www.apache.org/ Member; Sahana Software Foundation; http://www.sahanafoundation.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ -- Ruwan Linton Software Architect Product Manager, WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org Lean . Enterprise . Middleware phone: +1 408 754 7388 ext 51789 email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://blog.ruwan.org linkedin: http://www.linkedin.com/in/ruwanlinton google: http://www.google.com/profiles/ruwan.linton tweet: http://twitter.com/ruwanlinton
RE: Synapse configuration namespace
One of the issues that I see from time to time in the open source space is this one. In the commercial world, IBM understood decades ago how important it was to provide backwards compatibility and migration paths. Customers needed to focus their resources in a forward way, not re-doing that which had already been done. The litany of vendors who have also made this mistake can be found in the graveyards of many companies and open source projects. DEC's demise occurred in part because they didn't do that in their 36-bit processor world. Microsoft keeps making the same mistake with some of their products (an amazing number of programs still require VB6, for example), and it hurts them more than they seem to realize. The deprecation technique is a very good way of dealing with the issue. Don't make that same mistake. Unless you have good solid information that an overwhelming number of your customers/participants are OK with breaking backwards-compatibility, don't. I think Paul is right on the button. JRJ -Original Message- From: Ruwan Linton [mailto:ruwan.lin...@gmail.com] Sent: Sunday, November 07, 2010 9:10 PM To: dev@synapse.apache.org Cc: u...@synapse.apache.org Subject: Re: Synapse configuration namespace Since we were planing for a 2.0 release, I thought it is OK to do backwards incompatible changes and document them properly. Well we have some changes in the API as well, which will affect the existing mediators and so forth. Do you think we should keep the ability to run the 1.x mediators as it is on the 2.0 as well. I would like to hear users and other dev feedback on this... please raise your view on this. Thanks, Ruwan On Mon, Nov 8, 2010 at 6:41 AM, Hiranya Jayathilaka hiranya...@gmail.comwrote: Hi Paul, On Mon, Nov 8, 2010 at 4:50 AM, Paul Fremantle pzf...@gmail.com wrote: I don't see the point in changing the namespace unless there is an incompatibility at the core. We wrote the model to be very flexible. Having a migration XSLT is great, but it seems to me a fix for something that is tricky. Also, we spent a lot of effort on backwards compatibility: for example, I would have loved to have added new methods to the messagecontext, but put them into helper classes to avoid breaking existing mediators. At some point I think we will need to change the config radically, and that is the time to make a breaking change. I propose we make the code read the old config as well as the new (as much as possible) and print a deprecation statement. We should be able to always write the new config, so that users serializing their config will move to the new one. I don't think we can support both namespaces at once without making a huge amount of changes/additions to the code. Axiom doesn't give too many options in this space. We have all the namespaces, local names and QNames defined as global constants in the code. So how about this? By default we expect configurations to have the new namespace. But if somebody wants to load a configuration with the old namespace, he has to first set a special property in synapse.properties or as a system property. eg: -DuseOldNamespace=true We can easily support this model but even that is not perfect: 1. It is global - Once set it will affect each and every artifact loaded into Synapse 2. It will affect the serialization - If the property is set, configuration will be serialized with the old namespace Thanks, Hiranya Paul On Sat, Oct 2, 2010 at 2:01 PM, Ruwan Linton ruwan.lin...@gmail.com wrote: Sanjiva, We have a complete migration XSLT (it is not just the namespace, we have a few configuration language changes as well), what we could do is that, if we find the namespace to be the 1.x while tying to build the configuration model, we could first run the script and update the synapse configuration after backing up the existing one and continue loading synapse. WDYT? Thanks, Ruwan On Sat, Oct 2, 2010 at 10:21 AM, Sanjiva Weerawarana sanj...@opensource.lk wrote: I realize this is a bit of a late response :(. This change will break all existing users. How about at least supporting both namespaces? (Maybe this is too late now for the release ... in which case there's no point doing it later.) Sanjiva. On Mon, Apr 26, 2010 at 10:22 PM, Ruwan Linton ruwan.lin...@gmail.com wrote: Folks, We have been using the http://ws.apache.org/ns/synapse as the synapse configuration namespace, since synapse was graduated on to the WS project and we didn't want to introduce a configuration incompatibility because of becoming a new TLP, and with the new 2.0 release planned to be out, I am planning to change the synapse configuration namespace to a more meaning full namespace; http://synapse.apache.org/ns/2010/04/configuration Provided that the migration tool will be there this change should be OK with the 2.0
Re: Synapse configuration namespace
I don't see the point in changing the namespace unless there is an incompatibility at the core. We wrote the model to be very flexible. Having a migration XSLT is great, but it seems to me a fix for something that is tricky. Also, we spent a lot of effort on backwards compatibility: for example, I would have loved to have added new methods to the messagecontext, but put them into helper classes to avoid breaking existing mediators. At some point I think we will need to change the config radically, and that is the time to make a breaking change. I propose we make the code read the old config as well as the new (as much as possible) and print a deprecation statement. We should be able to always write the new config, so that users serializing their config will move to the new one. Paul On Sat, Oct 2, 2010 at 2:01 PM, Ruwan Linton ruwan.lin...@gmail.com wrote: Sanjiva, We have a complete migration XSLT (it is not just the namespace, we have a few configuration language changes as well), what we could do is that, if we find the namespace to be the 1.x while tying to build the configuration model, we could first run the script and update the synapse configuration after backing up the existing one and continue loading synapse. WDYT? Thanks, Ruwan On Sat, Oct 2, 2010 at 10:21 AM, Sanjiva Weerawarana sanj...@opensource.lk wrote: I realize this is a bit of a late response :(. This change will break all existing users. How about at least supporting both namespaces? (Maybe this is too late now for the release ... in which case there's no point doing it later.) Sanjiva. On Mon, Apr 26, 2010 at 10:22 PM, Ruwan Linton ruwan.lin...@gmail.com wrote: Folks, We have been using the http://ws.apache.org/ns/synapse as the synapse configuration namespace, since synapse was graduated on to the WS project and we didn't want to introduce a configuration incompatibility because of becoming a new TLP, and with the new 2.0 release planned to be out, I am planning to change the synapse configuration namespace to a more meaning full namespace; http://synapse.apache.org/ns/2010/04/configuration Provided that the migration tool will be there this change should be OK with the 2.0 release. Thoughts?? Thanks, Ruwan -- Ruwan Linton Technical Lead Product Manager; WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://ruwansblog.blogspot.com -- Sanjiva Weerawarana, Ph.D. Founder, Director Chief Scientist; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2; http://wso2.com/ Founder Director; Thinkcube Systems; http://www.thinkcube.com/ Member; Apache Software Foundation; http://www.apache.org/ Member; Sahana Software Foundation; http://www.sahanafoundation.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ -- Ruwan Linton Software Architect Product Manager, WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org Lean . Enterprise . Middleware phone: +1 408 754 7388 ext 51789 email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://blog.ruwan.org linkedin: http://www.linkedin.com/in/ruwanlinton google: http://www.google.com/profiles/ruwan.linton tweet: http://twitter.com/ruwanlinton -- Paul Fremantle Co-Founder and CTO, WSO2 Apache Synapse PMC Chair OASIS WS-RX TC Co-chair blog: http://pzf.fremantle.org p...@wso2.com Oxygenating the Web Service Platform, www.wso2.com - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
Re: Synapse configuration namespace
Hi Paul, On Mon, Nov 8, 2010 at 4:50 AM, Paul Fremantle pzf...@gmail.com wrote: I don't see the point in changing the namespace unless there is an incompatibility at the core. We wrote the model to be very flexible. Having a migration XSLT is great, but it seems to me a fix for something that is tricky. Also, we spent a lot of effort on backwards compatibility: for example, I would have loved to have added new methods to the messagecontext, but put them into helper classes to avoid breaking existing mediators. At some point I think we will need to change the config radically, and that is the time to make a breaking change. I propose we make the code read the old config as well as the new (as much as possible) and print a deprecation statement. We should be able to always write the new config, so that users serializing their config will move to the new one. I don't think we can support both namespaces at once without making a huge amount of changes/additions to the code. Axiom doesn't give too many options in this space. We have all the namespaces, local names and QNames defined as global constants in the code. So how about this? By default we expect configurations to have the new namespace. But if somebody wants to load a configuration with the old namespace, he has to first set a special property in synapse.properties or as a system property. eg: -DuseOldNamespace=true We can easily support this model but even that is not perfect: 1. It is global - Once set it will affect each and every artifact loaded into Synapse 2. It will affect the serialization - If the property is set, configuration will be serialized with the old namespace Thanks, Hiranya Paul On Sat, Oct 2, 2010 at 2:01 PM, Ruwan Linton ruwan.lin...@gmail.com wrote: Sanjiva, We have a complete migration XSLT (it is not just the namespace, we have a few configuration language changes as well), what we could do is that, if we find the namespace to be the 1.x while tying to build the configuration model, we could first run the script and update the synapse configuration after backing up the existing one and continue loading synapse. WDYT? Thanks, Ruwan On Sat, Oct 2, 2010 at 10:21 AM, Sanjiva Weerawarana sanj...@opensource.lk wrote: I realize this is a bit of a late response :(. This change will break all existing users. How about at least supporting both namespaces? (Maybe this is too late now for the release ... in which case there's no point doing it later.) Sanjiva. On Mon, Apr 26, 2010 at 10:22 PM, Ruwan Linton ruwan.lin...@gmail.com wrote: Folks, We have been using the http://ws.apache.org/ns/synapse as the synapse configuration namespace, since synapse was graduated on to the WS project and we didn't want to introduce a configuration incompatibility because of becoming a new TLP, and with the new 2.0 release planned to be out, I am planning to change the synapse configuration namespace to a more meaning full namespace; http://synapse.apache.org/ns/2010/04/configuration Provided that the migration tool will be there this change should be OK with the 2.0 release. Thoughts?? Thanks, Ruwan -- Ruwan Linton Technical Lead Product Manager; WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://ruwansblog.blogspot.com -- Sanjiva Weerawarana, Ph.D. Founder, Director Chief Scientist; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2; http://wso2.com/ Founder Director; Thinkcube Systems; http://www.thinkcube.com/ Member; Apache Software Foundation; http://www.apache.org/ Member; Sahana Software Foundation; http://www.sahanafoundation.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ -- Ruwan Linton Software Architect Product Manager, WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org Lean . Enterprise . Middleware phone: +1 408 754 7388 ext 51789 email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://blog.ruwan.org linkedin: http://www.linkedin.com/in/ruwanlinton google: http://www.google.com/profiles/ruwan.linton tweet: http://twitter.com/ruwanlinton -- Paul Fremantle Co-Founder and CTO, WSO2 Apache Synapse PMC Chair OASIS WS-RX TC Co-chair blog: http://pzf.fremantle.org p...@wso2.com Oxygenating the Web Service Platform, www.wso2.com - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org -- Hiranya Jayathilaka Senior Software Engineer; WSO2 Inc.; http://wso2.org E-mail: hira...@wso2.com; Mobile: +94 77 633 3491 Blog: http://techfeast-hiranya.blogspot.com - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h
Re: Synapse configuration namespace
Since we were planing for a 2.0 release, I thought it is OK to do backwards incompatible changes and document them properly. Well we have some changes in the API as well, which will affect the existing mediators and so forth. Do you think we should keep the ability to run the 1.x mediators as it is on the 2.0 as well. I would like to hear users and other dev feedback on this... please raise your view on this. Thanks, Ruwan On Mon, Nov 8, 2010 at 6:41 AM, Hiranya Jayathilaka hiranya...@gmail.comwrote: Hi Paul, On Mon, Nov 8, 2010 at 4:50 AM, Paul Fremantle pzf...@gmail.com wrote: I don't see the point in changing the namespace unless there is an incompatibility at the core. We wrote the model to be very flexible. Having a migration XSLT is great, but it seems to me a fix for something that is tricky. Also, we spent a lot of effort on backwards compatibility: for example, I would have loved to have added new methods to the messagecontext, but put them into helper classes to avoid breaking existing mediators. At some point I think we will need to change the config radically, and that is the time to make a breaking change. I propose we make the code read the old config as well as the new (as much as possible) and print a deprecation statement. We should be able to always write the new config, so that users serializing their config will move to the new one. I don't think we can support both namespaces at once without making a huge amount of changes/additions to the code. Axiom doesn't give too many options in this space. We have all the namespaces, local names and QNames defined as global constants in the code. So how about this? By default we expect configurations to have the new namespace. But if somebody wants to load a configuration with the old namespace, he has to first set a special property in synapse.properties or as a system property. eg: -DuseOldNamespace=true We can easily support this model but even that is not perfect: 1. It is global - Once set it will affect each and every artifact loaded into Synapse 2. It will affect the serialization - If the property is set, configuration will be serialized with the old namespace Thanks, Hiranya Paul On Sat, Oct 2, 2010 at 2:01 PM, Ruwan Linton ruwan.lin...@gmail.com wrote: Sanjiva, We have a complete migration XSLT (it is not just the namespace, we have a few configuration language changes as well), what we could do is that, if we find the namespace to be the 1.x while tying to build the configuration model, we could first run the script and update the synapse configuration after backing up the existing one and continue loading synapse. WDYT? Thanks, Ruwan On Sat, Oct 2, 2010 at 10:21 AM, Sanjiva Weerawarana sanj...@opensource.lk wrote: I realize this is a bit of a late response :(. This change will break all existing users. How about at least supporting both namespaces? (Maybe this is too late now for the release ... in which case there's no point doing it later.) Sanjiva. On Mon, Apr 26, 2010 at 10:22 PM, Ruwan Linton ruwan.lin...@gmail.com wrote: Folks, We have been using the http://ws.apache.org/ns/synapse as the synapse configuration namespace, since synapse was graduated on to the WS project and we didn't want to introduce a configuration incompatibility because of becoming a new TLP, and with the new 2.0 release planned to be out, I am planning to change the synapse configuration namespace to a more meaning full namespace; http://synapse.apache.org/ns/2010/04/configuration Provided that the migration tool will be there this change should be OK with the 2.0 release. Thoughts?? Thanks, Ruwan -- Ruwan Linton Technical Lead Product Manager; WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://ruwansblog.blogspot.com -- Sanjiva Weerawarana, Ph.D. Founder, Director Chief Scientist; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2; http://wso2.com/ Founder Director; Thinkcube Systems; http://www.thinkcube.com/ Member; Apache Software Foundation; http://www.apache.org/ Member; Sahana Software Foundation; http://www.sahanafoundation.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ -- Ruwan Linton Software Architect Product Manager, WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org Lean . Enterprise . Middleware phone: +1 408 754 7388 ext 51789 email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://blog.ruwan.org linkedin: http://www.linkedin.com/in/ruwanlinton google: http://www.google.com/profiles/ruwan.linton tweet: http://twitter.com/ruwanlinton -- Paul Fremantle Co-Founder and CTO, WSO2 Apache Synapse PMC Chair OASIS WS-RX TC Co
Re: Synapse configuration namespace
Sanjiva, We have a complete migration XSLT (it is not just the namespace, we have a few configuration language changes as well), what we could do is that, if we find the namespace to be the 1.x while tying to build the configuration model, we could first run the script and update the synapse configuration after backing up the existing one and continue loading synapse. WDYT? Thanks, Ruwan On Sat, Oct 2, 2010 at 10:21 AM, Sanjiva Weerawarana sanj...@opensource.lkwrote: I realize this is a bit of a late response :(. This change will break all existing users. How about at least supporting both namespaces? (Maybe this is too late now for the release ... in which case there's no point doing it later.) Sanjiva. On Mon, Apr 26, 2010 at 10:22 PM, Ruwan Linton ruwan.lin...@gmail.comwrote: Folks, We have been using the http://ws.apache.org/ns/synapse as the synapse configuration namespace, since synapse was graduated on to the WS project and we didn't want to introduce a configuration incompatibility because of becoming a new TLP, and with the new 2.0 release planned to be out, I am planning to change the synapse configuration namespace to a more meaning full namespace; http://synapse.apache.org/ns/2010/04/configuration Provided that the migration tool will be there this change should be OK with the 2.0 release. Thoughts?? Thanks, Ruwan -- Ruwan Linton Technical Lead Product Manager; WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://ruwansblog.blogspot.com -- Sanjiva Weerawarana, Ph.D. Founder, Director Chief Scientist; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2; http://wso2.com/ Founder Director; Thinkcube Systems; http://www.thinkcube.com/ Member; Apache Software Foundation; http://www.apache.org/ Member; Sahana Software Foundation; http://www.sahanafoundation.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ -- Ruwan Linton Software Architect Product Manager, WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org Lean . Enterprise . Middleware phone: +1 408 754 7388 ext 51789 email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://blog.ruwan.org linkedin: http://www.linkedin.com/in/ruwanlinton google: http://www.google.com/profiles/ruwan.linton tweet: http://twitter.com/ruwanlinton
Re: Synapse configuration namespace
I realize this is a bit of a late response :(. This change will break all existing users. How about at least supporting both namespaces? (Maybe this is too late now for the release ... in which case there's no point doing it later.) Sanjiva. On Mon, Apr 26, 2010 at 10:22 PM, Ruwan Linton ruwan.lin...@gmail.comwrote: Folks, We have been using the http://ws.apache.org/ns/synapse as the synapse configuration namespace, since synapse was graduated on to the WS project and we didn't want to introduce a configuration incompatibility because of becoming a new TLP, and with the new 2.0 release planned to be out, I am planning to change the synapse configuration namespace to a more meaning full namespace; http://synapse.apache.org/ns/2010/04/configuration Provided that the migration tool will be there this change should be OK with the 2.0 release. Thoughts?? Thanks, Ruwan -- Ruwan Linton Technical Lead Product Manager; WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://ruwansblog.blogspot.com -- Sanjiva Weerawarana, Ph.D. Founder, Director Chief Scientist; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2; http://wso2.com/ Founder Director; Thinkcube Systems; http://www.thinkcube.com/ Member; Apache Software Foundation; http://www.apache.org/ Member; Sahana Software Foundation; http://www.sahanafoundation.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/
Re: Synapse configuration namespace
We need to update all the samples as well. Rajika On Tue, Apr 27, 2010 at 2:55 PM, Ruwan Linton ruwan.lin...@gmail.comwrote: Relevant changes for this namespace change has been done on the trunk. Thanks, Ruwan On Tue, Apr 27, 2010 at 10:01 AM, Hiranya Jayathilaka hiranya...@gmail.com wrote: On Mon, Apr 26, 2010 at 10:22 PM, Ruwan Linton ruwan.lin...@gmail.comwrote: Folks, We have been using the http://ws.apache.org/ns/synapse as the synapse configuration namespace, since synapse was graduated on to the WS project and we didn't want to introduce a configuration incompatibility because of becoming a new TLP, and with the new 2.0 release planned to be out, I am planning to change the synapse configuration namespace to a more meaning full namespace; http://synapse.apache.org/ns/2010/04/configuration +1 Another thing that we should have done a lot earlier :) Thanks, Hiranya Provided that the migration tool will be there this change should be OK with the 2.0 release. Thoughts?? Thanks, Ruwan -- Ruwan Linton Technical Lead Product Manager; WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://ruwansblog.blogspot.com -- Hiranya Jayathilaka Software Engineer; WSO2 Inc.; http://wso2.org E-mail: hira...@wso2.com; Mobile: +94 77 633 3491 Blog: http://techfeast-hiranya.blogspot.com -- Ruwan Linton Technical Lead Product Manager; WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://ruwansblog.blogspot.com -- http://rajikak.blogspot.com/
Re: Synapse configuration namespace
I think I have done that as well Rajika. Please take an svn update and see. Thanks, Ruwan On Wed, Apr 28, 2010 at 6:58 PM, Rajika Kumarasiri raj...@wso2.com wrote: We need to update all the samples as well. Rajika On Tue, Apr 27, 2010 at 2:55 PM, Ruwan Linton ruwan.lin...@gmail.comwrote: Relevant changes for this namespace change has been done on the trunk. Thanks, Ruwan On Tue, Apr 27, 2010 at 10:01 AM, Hiranya Jayathilaka hiranya...@gmail.com wrote: On Mon, Apr 26, 2010 at 10:22 PM, Ruwan Linton ruwan.lin...@gmail.comwrote: Folks, We have been using the http://ws.apache.org/ns/synapse as the synapse configuration namespace, since synapse was graduated on to the WS project and we didn't want to introduce a configuration incompatibility because of becoming a new TLP, and with the new 2.0 release planned to be out, I am planning to change the synapse configuration namespace to a more meaning full namespace; http://synapse.apache.org/ns/2010/04/configuration +1 Another thing that we should have done a lot earlier :) Thanks, Hiranya Provided that the migration tool will be there this change should be OK with the 2.0 release. Thoughts?? Thanks, Ruwan -- Ruwan Linton Technical Lead Product Manager; WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://ruwansblog.blogspot.com -- Hiranya Jayathilaka Software Engineer; WSO2 Inc.; http://wso2.org E-mail: hira...@wso2.com; Mobile: +94 77 633 3491 Blog: http://techfeast-hiranya.blogspot.com -- Ruwan Linton Technical Lead Product Manager; WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://ruwansblog.blogspot.com -- http://rajikak.blogspot.com/ -- Ruwan Linton Technical Lead Product Manager; WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://ruwansblog.blogspot.com
Re: Synapse configuration namespace
Relevant changes for this namespace change has been done on the trunk. Thanks, Ruwan On Tue, Apr 27, 2010 at 10:01 AM, Hiranya Jayathilaka hiranya...@gmail.comwrote: On Mon, Apr 26, 2010 at 10:22 PM, Ruwan Linton ruwan.lin...@gmail.comwrote: Folks, We have been using the http://ws.apache.org/ns/synapse as the synapse configuration namespace, since synapse was graduated on to the WS project and we didn't want to introduce a configuration incompatibility because of becoming a new TLP, and with the new 2.0 release planned to be out, I am planning to change the synapse configuration namespace to a more meaning full namespace; http://synapse.apache.org/ns/2010/04/configuration +1 Another thing that we should have done a lot earlier :) Thanks, Hiranya Provided that the migration tool will be there this change should be OK with the 2.0 release. Thoughts?? Thanks, Ruwan -- Ruwan Linton Technical Lead Product Manager; WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://ruwansblog.blogspot.com -- Hiranya Jayathilaka Software Engineer; WSO2 Inc.; http://wso2.org E-mail: hira...@wso2.com; Mobile: +94 77 633 3491 Blog: http://techfeast-hiranya.blogspot.com -- Ruwan Linton Technical Lead Product Manager; WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://ruwansblog.blogspot.com
Synapse configuration namespace
Folks, We have been using the http://ws.apache.org/ns/synapse as the synapse configuration namespace, since synapse was graduated on to the WS project and we didn't want to introduce a configuration incompatibility because of becoming a new TLP, and with the new 2.0 release planned to be out, I am planning to change the synapse configuration namespace to a more meaning full namespace; http://synapse.apache.org/ns/2010/04/configuration Provided that the migration tool will be there this change should be OK with the 2.0 release. Thoughts?? Thanks, Ruwan -- Ruwan Linton Technical Lead Product Manager; WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://ruwansblog.blogspot.com
