You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@synapse.apache.org by Sanjiva Weerawarana <sa...@opensource.lk> on 2010/10/02 06:51:22 UTC
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 <ru...@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/
Re: Synapse configuration namespace
Posted by Ruwan Linton <ru...@gmail.com>.
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 <Ja...@dot.wi.gov>wrote:
> 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.linton@gmail.com]
> Sent: Sunday, November 21, 2010 10:38 PM
> To: user@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
> <sa...@opensource.lk>wrote:
>
> > On Sun, Nov 21, 2010 at 9:22 PM, Hubert, Eric <Eric.Hubert@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: 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
Re: Synapse configuration namespace
Posted by Ruwan Linton <ru...@gmail.com>.
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 <Ja...@dot.wi.gov>wrote:
> 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.linton@gmail.com]
> Sent: Sunday, November 21, 2010 10:38 PM
> To: user@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
> <sa...@opensource.lk>wrote:
>
> > On Sun, Nov 21, 2010 at 9:22 PM, Hubert, Eric <Eric.Hubert@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: 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
RE: Synapse configuration namespace
Posted by "Jaeger, Jay - DOT" <Ja...@dot.wi.gov>.
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.linton@gmail.com]
Sent: Sunday, November 21, 2010 10:38 PM
To: user@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
<sa...@opensource.lk>wrote:
> On Sun, Nov 21, 2010 at 9:22 PM, Hubert, Eric <Eric.Hubert@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: 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
Re: Synapse configuration namespace
Posted by Ruwan Linton <ru...@gmail.com>.
Hi Eric,
We haven't changed configurations a lot, but yes there are some changes and
we could keep the migration tool. Thanks for pointing it.
Thanks,
Ruwan
On Mon, Nov 22, 2010 at 7:08 PM, Hubert, Eric <Er...@foxmobile.com>wrote:
> Hi Ruwan,
>
> > 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 have no concern regarding omitting namespace changes. I'm just wondering
> whether the migration tool has been created only for a namespace change. I
> though it was to automatically convert configuration to compensate
> incompatible configuration language changes as well as to support xml schema
> introduction. Did we mix XML schema and namespaces in the discussion?
>
> Sorry, if I did get something wrong.
>
> Regards,
> Eric
>
--
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
RE: Synapse configuration namespace
Posted by "Hubert, Eric" <Er...@foxmobile.com>.
Hi Ruwan,
> 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 have no concern regarding omitting namespace changes. I'm just wondering whether the migration tool has been created only for a namespace change. I though it was to automatically convert configuration to compensate incompatible configuration language changes as well as to support xml schema introduction. Did we mix XML schema and namespaces in the discussion?
Sorry, if I did get something wrong.
Regards,
Eric
Re: Synapse configuration namespace
Posted by Hiranya Jayathilaka <hi...@gmail.com>.
On Mon, Nov 22, 2010 at 10:07 AM, Ruwan Linton <ru...@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
> <sa...@opensource.lk>wrote:
>
>> On Sun, Nov 21, 2010 at 9:22 PM, Hubert, Eric <Eric.Hubert@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: 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
>
--
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
Re: Synapse configuration namespace
Posted by Hiranya Jayathilaka <hi...@gmail.com>.
On Mon, Nov 22, 2010 at 10:07 AM, Ruwan Linton <ru...@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
> <sa...@opensource.lk>wrote:
>
>> On Sun, Nov 21, 2010 at 9:22 PM, Hubert, Eric <Eric.Hubert@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: 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
>
--
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
RE: Synapse configuration namespace
Posted by "Jaeger, Jay - DOT" <Ja...@dot.wi.gov>.
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.linton@gmail.com]
Sent: Sunday, November 21, 2010 10:38 PM
To: user@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
<sa...@opensource.lk>wrote:
> On Sun, Nov 21, 2010 at 9:22 PM, Hubert, Eric <Eric.Hubert@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: 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: Synapse configuration namespace
Posted by Ruwan Linton <ru...@gmail.com>.
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
<sa...@opensource.lk>wrote:
> On Sun, Nov 21, 2010 at 9:22 PM, Hubert, Eric <Eric.Hubert@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: 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
Re: Synapse configuration namespace
Posted by Ruwan Linton <ru...@gmail.com>.
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
<sa...@opensource.lk>wrote:
> On Sun, Nov 21, 2010 at 9:22 PM, Hubert, Eric <Eric.Hubert@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: 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
Re: Synapse configuration namespace
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Sun, Nov 21, 2010 at 9:22 PM, Hubert, Eric <Er...@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/
Re: Synapse configuration namespace
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Sun, Nov 21, 2010 at 9:22 PM, Hubert, Eric <Er...@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/
RE: Synapse configuration namespace
Posted by "Hubert, Eric" <Er...@foxmobile.com>.
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:supun06@gmail.com]
Sent: Sunday, November 21, 2010 3:25 PM
To: dev@synapse.apache.org
Cc: user@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 <ru...@gmail.com>> wrote:
I found more incompatible changes :-(
https://issues.apache.org/jira/browse/SYNAPSE-693?focusedCommentId=12934217&page=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 <sa...@opensource.lk>> wrote:
On Sat, Nov 20, 2010 at 8:58 PM, Ruwan Linton <ru...@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#forwards>This 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<http://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: ruwan@wso2.com<ma...@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<http://supunk.blogspot.com>
RE: Synapse configuration namespace
Posted by "Hubert, Eric" <Er...@foxmobile.com>.
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:supun06@gmail.com]
Sent: Sunday, November 21, 2010 3:25 PM
To: dev@synapse.apache.org
Cc: user@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 <ru...@gmail.com>> wrote:
I found more incompatible changes :-(
https://issues.apache.org/jira/browse/SYNAPSE-693?focusedCommentId=12934217&page=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 <sa...@opensource.lk>> wrote:
On Sat, Nov 20, 2010 at 8:58 PM, Ruwan Linton <ru...@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#forwards>This 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<http://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: ruwan@wso2.com<ma...@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<http://supunk.blogspot.com>
Re: Synapse configuration namespace
Posted by Supun Kamburugamuva <su...@gmail.com>.
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 <ru...@gmail.com>wrote:
> I found more incompatible changes :-(
>
>
> https://issues.apache.org/jira/browse/SYNAPSE-693?focusedCommentId=12934217&page=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 <
> sanjiva@opensource.lk> wrote:
>
>> On Sat, Nov 20, 2010 at 8:58 PM, Ruwan Linton <ru...@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#forwards>This 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: 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
>
--
Technical Lead, WSO2 Inc
http://wso2.org
supunk.blogspot.com
Re: Synapse configuration namespace
Posted by Supun Kamburugamuva <su...@gmail.com>.
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 <ru...@gmail.com>wrote:
> I found more incompatible changes :-(
>
>
> https://issues.apache.org/jira/browse/SYNAPSE-693?focusedCommentId=12934217&page=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 <
> sanjiva@opensource.lk> wrote:
>
>> On Sat, Nov 20, 2010 at 8:58 PM, Ruwan Linton <ru...@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#forwards>This 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: 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
>
--
Technical Lead, WSO2 Inc
http://wso2.org
supunk.blogspot.com
Re: Synapse configuration namespace
Posted by Ruwan Linton <ru...@gmail.com>.
I found more incompatible changes :-(
https://issues.apache.org/jira/browse/SYNAPSE-693?focusedCommentId=12934217&page=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
<sa...@opensource.lk>wrote:
> On Sat, Nov 20, 2010 at 8:58 PM, Ruwan Linton <ru...@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#forwards>This 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: 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
Re: Synapse configuration namespace
Posted by Ruwan Linton <ru...@gmail.com>.
I found more incompatible changes :-(
https://issues.apache.org/jira/browse/SYNAPSE-693?focusedCommentId=12934217&page=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
<sa...@opensource.lk>wrote:
> On Sat, Nov 20, 2010 at 8:58 PM, Ruwan Linton <ru...@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#forwards>This 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: 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
Re: Synapse configuration namespace
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Sat, Nov 20, 2010 at 8:58 PM, Ruwan Linton <ru...@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#forwards>This 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
Posted by Ruwan Linton <ru...@gmail.com>.
On Sat, Nov 20, 2010 at 8:05 PM, Sanjiva Weerawarana
<sa...@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 <ru...@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
>>> > <hi...@gmail.com>wrote:
>>> >
>>> > > Hi Paul,
>>> > >
>>> > > On Mon, Nov 8, 2010 at 4:50 AM, Paul Fremantle <pz...@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/
>
>
--
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
Re: Synapse configuration namespace
Posted by Ruwan Linton <ru...@gmail.com>.
On Sat, Nov 20, 2010 at 8:05 PM, Sanjiva Weerawarana
<sa...@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 <ru...@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
>>> > <hi...@gmail.com>wrote:
>>> >
>>> > > Hi Paul,
>>> > >
>>> > > On Mon, Nov 8, 2010 at 4:50 AM, Paul Fremantle <pz...@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/
>
>
--
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
Re: Synapse configuration namespace
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
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 <ru...@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 <Er...@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
>> > <hi...@gmail.com>wrote:
>> >
>> > > Hi Paul,
>> > >
>> > > On Mon, Nov 8, 2010 at 4:50 AM, Paul Fremantle <pz...@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/
Re: Synapse configuration namespace
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
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 <ru...@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 <Er...@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
>> > <hi...@gmail.com>wrote:
>> >
>> > > Hi Paul,
>> > >
>> > > On Mon, Nov 8, 2010 at 4:50 AM, Paul Fremantle <pz...@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/
Re: Synapse configuration namespace
Posted by Ruwan Linton <ru...@gmail.com>.
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 <Er...@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
> > <hi...@gmail.com>wrote:
> >
> > > Hi Paul,
> > >
> > > On Mon, Nov 8, 2010 at 4:50 AM, Paul Fremantle <pz...@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
Re: Synapse configuration namespace
Posted by Ruwan Linton <ru...@gmail.com>.
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 <Er...@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
> > <hi...@gmail.com>wrote:
> >
> > > Hi Paul,
> > >
> > > On Mon, Nov 8, 2010 at 4:50 AM, Paul Fremantle <pz...@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
RE: Synapse configuration namespace
Posted by "Hubert, Eric" <Er...@foxmobile.com>.
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
> <hi...@gmail.com>wrote:
>
> > Hi Paul,
> >
> > On Mon, Nov 8, 2010 at 4:50 AM, Paul Fremantle <pz...@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 <ru...@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
Re: Synapse configuration namespace
Posted by Ruwan Linton <ru...@gmail.com>.
Thanks Jay for the feedback, it really helps. I would appreciate the ideas
of few more users/devs.
Thanks,
Ruwan
On Mon, Nov 8, 2010 at 7:30 PM, Jaeger, Jay - DOT <Ja...@dot.wi.gov>wrote:
> 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.linton@gmail.com]
> Sent: Sunday, November 07, 2010 9:10 PM
> 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 <pz...@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 <ru...@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
RE: Synapse configuration namespace
Posted by "Jaeger, Jay - DOT" <Ja...@dot.wi.gov>.
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.linton@gmail.com]
Sent: Sunday, November 07, 2010 9:10 PM
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 <hi...@gmail.com>wrote:
> Hi Paul,
>
> On Mon, Nov 8, 2010 at 4:50 AM, Paul Fremantle <pz...@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 <ru...@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
RE: Synapse configuration namespace
Posted by "Jaeger, Jay - DOT" <Ja...@dot.wi.gov>.
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.linton@gmail.com]
Sent: Sunday, November 07, 2010 9:10 PM
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 <hi...@gmail.com>wrote:
> Hi Paul,
>
> On Mon, Nov 8, 2010 at 4:50 AM, Paul Fremantle <pz...@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 <ru...@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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: Synapse configuration namespace
Posted by Ruwan Linton <ru...@gmail.com>.
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 <hi...@gmail.com>wrote:
> Hi Paul,
>
> On Mon, Nov 8, 2010 at 4:50 AM, Paul Fremantle <pz...@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 <ru...@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
Re: Synapse configuration namespace
Posted by Ruwan Linton <ru...@gmail.com>.
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 <hi...@gmail.com>wrote:
> Hi Paul,
>
> On Mon, Nov 8, 2010 at 4:50 AM, Paul Fremantle <pz...@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 <ru...@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
Re: Synapse configuration namespace
Posted by Hiranya Jayathilaka <hi...@gmail.com>.
Hi Paul,
On Mon, Nov 8, 2010 at 4:50 AM, Paul Fremantle <pz...@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 <ru...@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 <sa...@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 <ru...@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
Re: Synapse configuration namespace
Posted by Paul Fremantle <pz...@gmail.com>.
PS My apologies for not bringing this up earlier :-(
On Sun, Nov 7, 2010 at 11:20 PM, Paul Fremantle <pz...@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.
>
> Paul
>
> On Sat, Oct 2, 2010 at 2:01 PM, Ruwan Linton <ru...@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 <sa...@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 <ru...@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
>
--
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
Re: Synapse configuration namespace
Posted by Paul Fremantle <pz...@gmail.com>.
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 <ru...@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 <sa...@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 <ru...@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
Re: Synapse configuration namespace
Posted by Ruwan Linton <ru...@gmail.com>.
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
<sa...@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 <ru...@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