On Sat, Nov 20, 2010 at 8:05 PM, Sanjiva Weerawarana <sanj...@opensource.lk>wrote:
> 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.com>wrote: > >> 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 >> > > > > -- > 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
