synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sanjiva Weerawarana <sanj...@opensource.lk>
Subject Re: Synapse configuration namespace
Date Sat, 20 Nov 2010 14:35:28 GMT
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.linton@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.Hubert@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.linton@gmail.com]
>> > Sent: Monday, November 08, 2010 4:10 AM
>> > To: dev@synapse.apache.org
>> > Cc: user@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
>> > <hiranya911@gmail.com>wrote:
>> >
>> > > Hi Paul,
>> > >
>> > > On Mon, Nov 8, 2010 at 4:50 AM, Paul Fremantle <pzfreo@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.linton@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 <
>> > > sanjiva@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.linton@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: ruwan@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: ruwan@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
>> > > > paul@wso2.com
>> > > >
>> > > > "Oxygenating the Web Service Platform", www.wso2.com
>> > > >
>> > > >
>> ---------------------------------------------------------------------
>> > > > To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>> > > > For additional commands, e-mail: dev-help@synapse.apache.org
>> > > >
>> > > >
>> > >
>> > >
>> > >
>> > > --
>> > > Hiranya Jayathilaka
>> > > Senior Software Engineer;
>> > > WSO2 Inc.;  http://wso2.org
>> > > E-mail: hiranya@wso2.com;  Mobile: +94 77 633 3491
>> > > Blog: http://techfeast-hiranya.blogspot.com
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>> > > For additional commands, e-mail: dev-help@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: ruwan@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: ruwan@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/

Mime
View raw message