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 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.com>wrote: > > > > > 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...@synapse.apache.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 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
