synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruwan Linton <ruwan.lin...@gmail.com>
Subject Re: Synapse configuration namespace
Date Sat, 20 Nov 2010 12:44:43 GMT
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

Mime
View raw message