You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@synapse.apache.org by Charith Wickramarachchi <ch...@gmail.com> on 2009/02/20 04:48:10 UTC
Make enable Synapse to configure in others ways
Hi devs,
In order to be able to configure synapse in other ways than the XML
configuration language, I have abstracted out the initialization into a
one level higher layer where you can specify the mechanism by which you
want to load the configuration. This will not affect the usual synapse
initialization flow, but is just an abstraction layer.
With this users will be able to plug their own Synapse Configuration and
ConfigurationContext with out touching the synapse code base.
Following is a brief description of this improvement and if this is OK
to be committed into synapse I will attach the patch for further reviews.
* org.apache.synapse.ConfigurationBuilder
*
This is the abstraction layer added to Synapse for it to be able to
extend or rather use new Configuration mechanism (DSL) than using the
default Synapse Configuration Language. With this improvement users can
use other Configurations by enabling the ConfigurationBuilder.
Eg: ConfigurationBuilder cbuilder=ConfigurationBuilder.getInstence();
cbuilder.setEnable(true);
(this is done in users code not in synapse codebase)
Then users must set the Builder Class in the ConfigurationBuilder.(This
must be the fully qualified name of the Builder Class that users use to
build the Configuration) And then users can set parameters needed to the
build the configuration. The only restriction that Builder Class (the
third party class that used to build the configuration) have is its
configuration builder method must have the name
"createSynapseConfiguration".
The Configuration Builder class will find the appropriate method form
the Builder class using the class name and the parameter list and then
it will build the Synapse configuration.The advantage of using this
abstraction layer is Synapse ServerManager does not depend on the third
party Synapse configuration builders.
*org.apache.synapse.ConfigurationContextBuilder*
This is the abstraction layer added to the Synapse project to Start
Axis2 and Synapse using a Different application context this works as
same as the ConfigurationBuilder described above. Users who wants to
extent synapse to Start using a different application context can use this.
Here the restriction that is given to the Builder class is it must have
the method "createConfigurationContext" to Create configuration
context.The ConfigurationContextBuilder will locate the correct method
and build the Configuration Context to start the Axis2 and Synapse in
that context.
thank you,
Charith Dhanushka Wickramarachchi
http://charithwiki.blogspot.com/
Re: Make enable Synapse to configure in others ways
Posted by Hiranya Jayathilaka <hi...@gmail.com>.
Hi Charith,
I may have misinterpreted the situation but by going through the
descriptions you have posted, I get the feeling that there is a violation of
OO principles somewhere in the design. I agree with Indika, that this is
something we need to tackle using an API/Interface and not reflection. IMHO
reflection should be used only when we have no other choice and we are
forced to bend the OO programming practices.
I think you should provide a builder interface. This interface will have a
method which builds and returns a Synapse configuration. Users can implement
the interface to initialize the Synapse in application specific ways. As for
passing arguments to the builder, you should have getParameter(String),
setParameter(String, Object) methods in your interface. The builder
implementation should be capable of interpreting these parameters (based on
their names), casting them into suitable types and using them internally.
Your configuration builder class should accept a valid implementation of the
builder interface and invoke the method which creates the Synapse
configuration.
Thanks,
Hiranya
On Fri, Feb 20, 2009 at 3:37 PM, indika kumara <in...@gmail.com>wrote:
> Interfaces are for providing abstractions. You can pass parameter as
> Map <string, Object> ... key is only meaningful to particular
> implementation…or if there many common attributes, then those can be
> encapsulated into a data structure, a class – some abstraction and
> keep a Map<string,Object> (instance variable )to hold any specific
> parameters ….there are many ways to do these things ...with out using
> reflection.
>
> I just say what I feel when I look at into your code. If you know that
> you can achieve what you want and others too (community) like these...
> I am neutral.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
> For additional commands, e-mail: dev-help@synapse.apache.org
>
>
Re: Make enable Synapse to configure in others ways
Posted by indika kumara <in...@gmail.com>.
Interfaces are for providing abstractions. You can pass parameter as
Map <string, Object> ... key is only meaningful to particular
implementation…or if there many common attributes, then those can be
encapsulated into a data structure, a class – some abstraction and
keep a Map<string,Object> (instance variable )to hold any specific
parameters ….there are many ways to do these things ...with out using
reflection.
I just say what I feel when I look at into your code. If you know that
you can achieve what you want and others too (community) like these...
I am neutral.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: Make enable Synapse to configure in others ways
Posted by Charith Wickramarachchi <ch...@gmail.com>.
On Fri, Feb 20, 2009 at 1:09 PM, indika kumara <in...@gmail.com>wrote:
> Hi Charith
>
> FOR ME , there are some issues ...
>
> One issue is there are no java documents and logging. And code has not
> been formatted.
> Sure I'll will reformat the code with some documentation and logging
>
> Another issue is you have used java reflection to detect methods
> 'createConfigurationContext' and 'createSynapseConfiguration'. One
> thing is, this is not a requirement to use reflection. These methods
> are important to synapse as they setup synapse. You must use
> "interfaces'. Using reflection is something like that you are trying
> to find a way to get work done forcibly, when someone says he cannot
> do.
The problem with using an interface to this abstraction layer is this:
> By providing this abstraction layer my intention is to enable users to plug
> there SynapseConfiguration and ConfigurationContext.
If i use an interface i have to force the user to use the specific type
of parameters to create synapse Configuration.which i think is not a
good way.What i did using reflections is allow users to use a methode which
can accept any type as a parameter.
For clarification i will explain how a user can use ConfigurationBuilder
in there code to to plug their own Builder
ConfigurationBuilder cb=ConfigurationBuilder.getInstence();
cb.setEnable(true);
paramSynapseConfig[0]=applicationContext;
cb.setBuilderClass("org.noname.atech.esb.synapse.UserSynapseConfigurationBuilder");
cb.setParameters(paramSynapseConfig);
as in above code users can set the parameters that are need to build the
configuration and the builder class. In the class they use to
initialise.
> So that when the server manager starts Configuration builder It will find
> the correct methode from the specified class with correct parameters and
> invoke it to build the Configuration.
> So i think this way is much flexsible than using an Interface (Specially in
> this senario).
> You can create something time 'SynapseConfigurationFactory' and add method
>
> 'createSynapseConfiguration(List<String> confPaths)'
>
> List of path may be needed if it is needed to merge a configurations
> from multiple configurations or create a
> 'CompositeSynaseConfiguration' without merging but just keep as
> children configurations
>
> There is another thing. It is important to avoid (as possible) when
> setting and getting instance properties of a class, use of 'Map',
> 'List'. This breaks the one of most important OOP principle –
> encapsulation. You always expose internal data structure. Therefore,
> It is better to use 'add< relates word – property, parameter>(
> key,value)' and returning 'Iterator' for getters. This is only
> important if you care OOP. Other is don't try to use toString for
> anything other than logging.
>
> I am not sure in this way you can achieve what you want. You have hard
> coded both 'ConfigurationContextBuilder' and 'ConfigurationBuilder'
> (those are not interfaces'. And I can see method like
>
> 'synapseConfiguration=builder.getSynapseConfiguration(
> builder.getBuilderClass(),builder.getParameters());'
>
> I may misunderstand these. Sorry if it is.
>
> If you want to differentiates the ways that synapse configuration
> provides (xml based DSL or some other). You need a
> 'SynapseConfigurationProvider or SynapseConfigurationFactory'
> implementations … You can get this using many ways. Simplest thing is
> to specify as a property in the synapse.properties. It is very simple,
> declarative, will work in any environment (Example OSGI) without any
> additional code, will work in any deployment mode (web app,
> standalone) and other is , this is mostly a one property not like
> mediators. You can use many other ways, system property (need to
> avoid, a security hole), inti parameter, java service provider API,
> discovery, etc….
> You simply what need here a 'SynapseConfigurationProvider' finding
> strategy. You can have single strategy with assigned precedence order
> to each ways of finding 'SynapseConfigurationProvider' class. For
> example, you can first look at synapse.properties , then init
> parameter , system properties , SPI ,etc………
>
>
> SynapseConfigurationProvider provider =
> SynapseConfigurationProviderFindingStrategy.find(..);
>
> Within find method, it is needed to implement the strategy
>
> If this 'provider' is null you can use default our existing
> XMLBasedConfigurationBuilder
>
> To get synapse configuration
>
> SynapeConfiguration = proiver.getSynapseConfiguration(List<String>
> confPaths)
>
> (If you use 'SynapseConfigurationFactory' instead of
> 'SynapseConfigurationProvider' use can call
> 'createSynapseConfiguration(List<String> confPaths)'
> )..
>
> This is only a way (untested) and you never want to do this …You can
> think and do it in better way than this.
>
> For your knowledge, existing synapse language is a DSL. It is focused
> on domain ESB or a middleware with some properties that make it
> special. It is too an external DSL. Actually, according to the
> 'martinfowler' - one of well recognized scientist, XML is the worst
> thing for external DSL. There are more resources at [1] .
> Thank you for the link this is really useful.
> Thanks
> Indika
>
> [1] http://martinfowler.com/dslwip/
>
>
> On Fri, Feb 20, 2009 at 9:18 AM, Charith Wickramarachchi
> <ch...@gmail.com> wrote:
> > Hi devs,
> >
> > In order to be able to configure synapse in other ways than the XML
> > configuration language, I have abstracted out the initialization into a
> > one level higher layer where you can specify the mechanism by which you
> > want to load the configuration. This will not affect the usual synapse
> > initialization flow, but is just an abstraction layer.
> >
> > With this users will be able to plug their own Synapse Configuration and
> > ConfigurationContext with out touching the synapse code base.
> >
> > Following is a brief description of this improvement and if this is OK
> > to be committed into synapse I will attach the patch for further
> reviews.
> >
> > org.apache.synapse.ConfigurationBuilder
> >
> > This is the abstraction layer added to Synapse for it to be able to
> > extend or rather use new Configuration mechanism (DSL) than using the
> > default Synapse Configuration Language. With this improvement users can
> > use other Configurations by enabling the ConfigurationBuilder.
> >
> > Eg: ConfigurationBuilder cbuilder=ConfigurationBuilder.getInstence();
> > cbuilder.setEnable(true);
> > (this is done in users code not in synapse codebase)
> >
> > Then users must set the Builder Class in the ConfigurationBuilder.(This
> > must be the fully qualified name of the Builder Class that users use to
> > build the Configuration) And then users can set parameters needed to the
> > build the configuration. The only restriction that Builder Class (the
> > third party class that used to build the configuration) have is its
> > configuration builder method must have the name
> > "createSynapseConfiguration".
> >
> > The Configuration Builder class will find the appropriate method form
> > the Builder class using the class name and the parameter list and then
> > it will build the Synapse configuration.The advantage of using this
> > abstraction layer is Synapse ServerManager does not depend on the third
> > party Synapse configuration builders.
> >
> > org.apache.synapse.ConfigurationContextBuilder
> >
> > This is the abstraction layer added to the Synapse project to Start
> > Axis2 and Synapse using a Different application context this works as
> > same as the ConfigurationBuilder described above. Users who wants to
> > extent synapse to Start using a different application context can use
> this.
> > Here the restriction that is given to the Builder class is it must have
> > the method "createConfigurationContext" to Create configuration
> > context.The ConfigurationContextBuilder will locate the correct method
> > and build the Configuration Context to start the Axis2 and Synapse in
> > that context.
> >
> > thank you,
> > Charith Dhanushka Wickramarachchi
> > http://charithwiki.blogspot.com/
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
> For additional commands, e-mail: dev-help@synapse.apache.org
>
>
--
Charith Dhanushka Wickramarachchi
http://charithwiki.blogspot.com/
Re: Make enable Synapse to configure in others ways
Posted by indika kumara <in...@gmail.com>.
Hi Charith
FOR ME , there are some issues ...
One issue is there are no java documents and logging. And code has not
been formatted.
Another issue is you have used java reflection to detect methods
'createConfigurationContext' and 'createSynapseConfiguration'. One
thing is, this is not a requirement to use reflection. These methods
are important to synapse as they setup synapse. You must use
"interfaces'. Using reflection is something like that you are trying
to find a way to get work done forcibly, when someone says he cannot
do.
You can create something time 'SynapseConfigurationFactory' and add method
'createSynapseConfiguration(List<String> confPaths)'
List of path may be needed if it is needed to merge a configurations
from multiple configurations or create a
'CompositeSynaseConfiguration' without merging but just keep as
children configurations
There is another thing. It is important to avoid (as possible) when
setting and getting instance properties of a class, use of 'Map',
'List'. This breaks the one of most important OOP principle –
encapsulation. You always expose internal data structure. Therefore,
It is better to use 'add< relates word – property, parameter>(
key,value)' and returning 'Iterator' for getters. This is only
important if you care OOP. Other is don't try to use toString for
anything other than logging.
I am not sure in this way you can achieve what you want. You have hard
coded both 'ConfigurationContextBuilder' and 'ConfigurationBuilder'
(those are not interfaces'. And I can see method like
'synapseConfiguration=builder.getSynapseConfiguration(builder.getBuilderClass(),builder.getParameters());'
I may misunderstand these. Sorry if it is.
If you want to differentiates the ways that synapse configuration
provides (xml based DSL or some other). You need a
'SynapseConfigurationProvider or SynapseConfigurationFactory'
implementations … You can get this using many ways. Simplest thing is
to specify as a property in the synapse.properties. It is very simple,
declarative, will work in any environment (Example OSGI) without any
additional code, will work in any deployment mode (web app,
standalone) and other is , this is mostly a one property not like
mediators. You can use many other ways, system property (need to
avoid, a security hole), inti parameter, java service provider API,
discovery, etc….
You simply what need here a 'SynapseConfigurationProvider' finding
strategy. You can have single strategy with assigned precedence order
to each ways of finding 'SynapseConfigurationProvider' class. For
example, you can first look at synapse.properties , then init
parameter , system properties , SPI ,etc………
SynapseConfigurationProvider provider =
SynapseConfigurationProviderFindingStrategy.find(..);
Within find method, it is needed to implement the strategy
If this 'provider' is null you can use default our existing
XMLBasedConfigurationBuilder
To get synapse configuration
SynapeConfiguration = proiver.getSynapseConfiguration(List<String> confPaths)
(If you use 'SynapseConfigurationFactory' instead of
'SynapseConfigurationProvider' use can call
'createSynapseConfiguration(List<String> confPaths)'
)..
This is only a way (untested) and you never want to do this …You can
think and do it in better way than this.
For your knowledge, existing synapse language is a DSL. It is focused
on domain ESB or a middleware with some properties that make it
special. It is too an external DSL. Actually, according to the
'martinfowler' - one of well recognized scientist, XML is the worst
thing for external DSL. There are more resources at [1] .
Thanks
Indika
[1] http://martinfowler.com/dslwip/
On Fri, Feb 20, 2009 at 9:18 AM, Charith Wickramarachchi
<ch...@gmail.com> wrote:
> Hi devs,
>
> In order to be able to configure synapse in other ways than the XML
> configuration language, I have abstracted out the initialization into a
> one level higher layer where you can specify the mechanism by which you
> want to load the configuration. This will not affect the usual synapse
> initialization flow, but is just an abstraction layer.
>
> With this users will be able to plug their own Synapse Configuration and
> ConfigurationContext with out touching the synapse code base.
>
> Following is a brief description of this improvement and if this is OK
> to be committed into synapse I will attach the patch for further reviews.
>
> org.apache.synapse.ConfigurationBuilder
>
> This is the abstraction layer added to Synapse for it to be able to
> extend or rather use new Configuration mechanism (DSL) than using the
> default Synapse Configuration Language. With this improvement users can
> use other Configurations by enabling the ConfigurationBuilder.
>
> Eg: ConfigurationBuilder cbuilder=ConfigurationBuilder.getInstence();
> cbuilder.setEnable(true);
> (this is done in users code not in synapse codebase)
>
> Then users must set the Builder Class in the ConfigurationBuilder.(This
> must be the fully qualified name of the Builder Class that users use to
> build the Configuration) And then users can set parameters needed to the
> build the configuration. The only restriction that Builder Class (the
> third party class that used to build the configuration) have is its
> configuration builder method must have the name
> "createSynapseConfiguration".
>
> The Configuration Builder class will find the appropriate method form
> the Builder class using the class name and the parameter list and then
> it will build the Synapse configuration.The advantage of using this
> abstraction layer is Synapse ServerManager does not depend on the third
> party Synapse configuration builders.
>
> org.apache.synapse.ConfigurationContextBuilder
>
> This is the abstraction layer added to the Synapse project to Start
> Axis2 and Synapse using a Different application context this works as
> same as the ConfigurationBuilder described above. Users who wants to
> extent synapse to Start using a different application context can use this.
> Here the restriction that is given to the Builder class is it must have
> the method "createConfigurationContext" to Create configuration
> context.The ConfigurationContextBuilder will locate the correct method
> and build the Configuration Context to start the Axis2 and Synapse in
> that context.
>
> thank you,
> Charith Dhanushka Wickramarachchi
> http://charithwiki.blogspot.com/
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: Make enable Synapse to configure in others ways
Posted by Paul Fremantle <pz...@gmail.com>.
Charith
Perhaps you could explain the use case to me more clearly?
Thanks
Paul
On Mon, Feb 23, 2009 at 11:32 AM, Charith Wickramarachchi
<ch...@gmail.com> wrote:
> Hi Paul,
>
> Yes With the support in Synapse we can add an alternative XML configuration
> with out any code change.For the Spring DSL scenario we can use that
> support.Thank you very much for pointing out that.
>
> But I think we need an abstraction if we are going to build the
> Configuration Context for synapse in an Other way(eg:in Spring).
>
> thank you,
> Charith
>
> On Mon, Feb 23, 2009 at 3:41 PM, Paul Fremantle <pz...@gmail.com> wrote:
>>
>> Frankly I'm completely confused by this discussion. I already added
>> support for this in July 2007:
>> see http://issues.apache.org/jira/browse/SYNAPSE-111
>>
>> You can already add an alternative configuration builder based on the
>> namespace of the XML document without any further code changes.
>>
>> Admittedly this only works for XML, but I'm guessing you want XML for
>> the Spring model?
>>
>> I also completely disagree with Asankha's point that no-one has ever
>> asked for it since there is a blooming JIRA and I've also blogged a
>> number of times about adding DSL support to Synapse!
>>
>> Paul
>>
>>
>>
>> On Sun, Feb 22, 2009 at 11:40 AM, Sanjiva Weerawarana
>> <sa...@opensource.lk> wrote:
>> > On 2/22/09, Asankha C. Perera <as...@apache.org> wrote:
>> >> Charith's email (nor the patch) did not indicate any of this, not even
>> >> the word 'Spring' :-)
>> >
>> > Right, probably because the changes are generic and not specific to
>> > Spring. Spring is only one potentially interesting alternative DSL for
>> > how to wire up a Synapse configuration.
>> >
>> >> Charith I still stand by what I wrote below. Also please refer to [1]
>> >> for the Synapse development guidelines for code contributions
>> >
>> > Totally +1 for making contributions compliant to the guidelines.
>> >
>> > Sanjiva.
>> > --
>> > Sanjiva Weerawarana, Ph.D.
>> > Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
>> > Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
>> > Member; Apache Software Foundation; http://www.apache.org/
>> > Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>> >
>> > Blog: http://sanjiva.weerawarana.org/
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>> > For additional commands, e-mail: dev-help@synapse.apache.org
>> >
>> >
>>
>>
>>
>> --
>> 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
>>
>
>
>
> --
> Charith Dhanushka Wickramarachchi
> http://charithwiki.blogspot.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: Make enable Synapse to configure in others ways
Posted by Charith Wickramarachchi <ch...@gmail.com>.
Hi Paul,
Yes With the support in Synapse we can add an alternative XML configuration
with out any code change.For the Spring DSL scenario we can use that
support.Thank you very much for pointing out that.
But I think we need an abstraction if we are going to build the
Configuration Context for synapse in an Other way(eg:in Spring).
thank you,
Charith
On Mon, Feb 23, 2009 at 3:41 PM, Paul Fremantle <pz...@gmail.com> wrote:
> Frankly I'm completely confused by this discussion. I already added
> support for this in July 2007:
> see http://issues.apache.org/jira/browse/SYNAPSE-111
>
> You can already add an alternative configuration builder based on the
> namespace of the XML document without any further code changes.
>
> Admittedly this only works for XML, but I'm guessing you want XML for
> the Spring model?
>
> I also completely disagree with Asankha's point that no-one has ever
> asked for it since there is a blooming JIRA and I've also blogged a
> number of times about adding DSL support to Synapse!
>
> Paul
>
>
>
> On Sun, Feb 22, 2009 at 11:40 AM, Sanjiva Weerawarana
> <sa...@opensource.lk> wrote:
> > On 2/22/09, Asankha C. Perera <as...@apache.org> wrote:
> >> Charith's email (nor the patch) did not indicate any of this, not even
> >> the word 'Spring' :-)
> >
> > Right, probably because the changes are generic and not specific to
> > Spring. Spring is only one potentially interesting alternative DSL for
> > how to wire up a Synapse configuration.
> >
> >> Charith I still stand by what I wrote below. Also please refer to [1]
> >> for the Synapse development guidelines for code contributions
> >
> > Totally +1 for making contributions compliant to the guidelines.
> >
> > Sanjiva.
> > --
> > Sanjiva Weerawarana, Ph.D.
> > Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
> > Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> > Member; Apache Software Foundation; http://www.apache.org/
> > Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
> >
> > Blog: http://sanjiva.weerawarana.org/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
> > For additional commands, e-mail: dev-help@synapse.apache.org
> >
> >
>
>
>
> --
> 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
>
>
--
Charith Dhanushka Wickramarachchi
http://charithwiki.blogspot.com/
Re: Make enable Synapse to configure in others ways
Posted by Paul Fremantle <pz...@gmail.com>.
Frankly I'm completely confused by this discussion. I already added
support for this in July 2007:
see http://issues.apache.org/jira/browse/SYNAPSE-111
You can already add an alternative configuration builder based on the
namespace of the XML document without any further code changes.
Admittedly this only works for XML, but I'm guessing you want XML for
the Spring model?
I also completely disagree with Asankha's point that no-one has ever
asked for it since there is a blooming JIRA and I've also blogged a
number of times about adding DSL support to Synapse!
Paul
On Sun, Feb 22, 2009 at 11:40 AM, Sanjiva Weerawarana
<sa...@opensource.lk> wrote:
> On 2/22/09, Asankha C. Perera <as...@apache.org> wrote:
>> Charith's email (nor the patch) did not indicate any of this, not even
>> the word 'Spring' :-)
>
> Right, probably because the changes are generic and not specific to
> Spring. Spring is only one potentially interesting alternative DSL for
> how to wire up a Synapse configuration.
>
>> Charith I still stand by what I wrote below. Also please refer to [1]
>> for the Synapse development guidelines for code contributions
>
> Totally +1 for making contributions compliant to the guidelines.
>
> Sanjiva.
> --
> Sanjiva Weerawarana, Ph.D.
> Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> Member; Apache Software Foundation; http://www.apache.org/
> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>
> Blog: http://sanjiva.weerawarana.org/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
> For additional commands, e-mail: dev-help@synapse.apache.org
>
>
--
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: Make enable Synapse to configure in others ways
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On 2/22/09, Asankha C. Perera <as...@apache.org> wrote:
> Charith's email (nor the patch) did not indicate any of this, not even
> the word 'Spring' :-)
Right, probably because the changes are generic and not specific to
Spring. Spring is only one potentially interesting alternative DSL for
how to wire up a Synapse configuration.
> Charith I still stand by what I wrote below. Also please refer to [1]
> for the Synapse development guidelines for code contributions
Totally +1 for making contributions compliant to the guidelines.
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
Blog: http://sanjiva.weerawarana.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: Make enable Synapse to configure in others ways
Posted by "Asankha C. Perera" <as...@apache.org>.
Hi Sanjiva
> Asankha, the objective is to make it possible for a Spring user to
> configure Synapse without touching anything outside of a Spring
> configuration. While you may not find that useful, there are others
> that do!
Charith's email (nor the patch) did not indicate any of this, not even
the word 'Spring' :-)
Charith I still stand by what I wrote below. Also please refer to [1]
for the Synapse development guidelines for code contributions
>> If you are still keen on this, I would like you to first suggest a
>> concrete sample of a Synapse configuration in this 'other' way - to
>> compare if implementing support for that really is more meaningful.
cheers
asankha
[1] http://cwiki.apache.org/synapse/developer-guidelines.html
--
Asankha C. Perera
http://adroitlogic.org
http://esbmagic.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: Make enable Synapse to configure in others ways
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Asankha, the objective is to make it possible for a Spring user to
configure Synapse without touching anything outside of a Spring
configuration. While you may not find that useful, there are others that do!
We mustn't tell people "do more useful stuff" - if there are changes
needed to support different uses from what you believe is the one true
usecase then *if* the changes don't break anything then we cannot say no
to that!
(I haven't looked at the details of the changes - indeed they may be
wrongly executed and maybe need to be re-written or whatever. However, I'm
not willing to accept your position that there are other more important
issues and hence we can say no to someone doing something that you don't
find useful!!!!)
Sanjiva.
Asankha C. Perera wrote:
> Hi Charith
>
> While I value your intent to contribute to Synapse to make it better, I
> think we already have issues reported by real users as JIRAs, which
> should IMHO take higher priority over a new feature such as this - which
> I consider just nice to have at most. We already have a well established
> configuration language from Synapse 1.0 (almost 3 years old now), and
> according to my knowledge no user has requested for another mechanism to
> initialize Synapse - although we left room at the start to be even able
> to do that. If you are still keen on this, I would like you to first
> suggest a concrete sample of a Synapse configuration in this 'other' way
> - to compare if implementing support for that really is more
> meaningful.. If you check the Synapse archives back into 2006, you will
> see the birth of the current configuration language [1]
>
> cheers
> asankha
>
> [1] http://markmail.org/message/u7rxhs4irw73c7j3
>> Hi devs,
>>
>> In order to be able to configure synapse in other ways than the XML
>> configuration language, I have abstracted out the initialization into a
>> one level higher layer where you can specify the mechanism by which you
>> want to load the configuration. This will not affect the usual synapse
>> initialization flow, but is just an abstraction layer.
>>
>> With this users will be able to plug their own Synapse Configuration
>> and
>> ConfigurationContext with out touching the synapse code base.
>>
>> Following is a brief description of this improvement and if this is OK
>> to be committed into synapse I will attach the patch for further reviews.
>>
>> * org.apache.synapse.ConfigurationBuilder
>> *
>> This is the abstraction layer added to Synapse for it to be able to
>> extend or rather use new Configuration mechanism (DSL) than using the
>> default Synapse Configuration Language. With this improvement users can
>> use other Configurations by enabling the ConfigurationBuilder.
>>
>> Eg: ConfigurationBuilder cbuilder=ConfigurationBuilder.getInstence();
>> cbuilder.setEnable(true);
>> (this is done in users code not in synapse codebase)
>>
>> Then users must set the Builder Class in the ConfigurationBuilder.(This
>> must be the fully qualified name of the Builder Class that users use to
>> build the Configuration) And then users can set parameters needed to the
>> build the configuration. The only restriction that Builder Class (the
>> third party class that used to build the configuration) have is its
>> configuration builder method must have the name
>> "createSynapseConfiguration".
>>
>> The Configuration Builder class will find the appropriate method form
>> the Builder class using the class name and the parameter list and then
>> it will build the Synapse configuration.The advantage of using this
>> abstraction layer is Synapse ServerManager does not depend on the third
>> party Synapse configuration builders.
>>
>> *org.apache.synapse.ConfigurationContextBuilder*
>>
>> This is the abstraction layer added to the Synapse project to Start
>> Axis2 and Synapse using a Different application context this works as
>> same as the ConfigurationBuilder described above. Users who wants to
>> extent synapse to Start using a different application context can use
>> this.
>> Here the restriction that is given to the Builder class is it must have
>> the method "createConfigurationContext" to Create configuration
>> context.The ConfigurationContextBuilder will locate the correct method
>> and build the Configuration Context to start the Axis2 and Synapse in
>> that context.
>>
>> thank you,
>> Charith Dhanushka Wickramarachchi
>> http://charithwiki.blogspot.com/
>>
>
>
> --
> Asankha C. Perera
> http://adroitlogic.org
>
> http://esbmagic.blogspot.com
>
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
Blog: http://sanjiva.weerawarana.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: Make enable Synapse to configure in others ways
Posted by "Asankha C. Perera" <as...@apache.org>.
Hi Charith
While I value your intent to contribute to Synapse to make it better, I
think we already have issues reported by real users as JIRAs, which
should IMHO take higher priority over a new feature such as this - which
I consider just nice to have at most. We already have a well established
configuration language from Synapse 1.0 (almost 3 years old now), and
according to my knowledge no user has requested for another mechanism to
initialize Synapse - although we left room at the start to be even able
to do that. If you are still keen on this, I would like you to first
suggest a concrete sample of a Synapse configuration in this 'other' way
- to compare if implementing support for that really is more
meaningful.. If you check the Synapse archives back into 2006, you will
see the birth of the current configuration language [1]
cheers
asankha
[1] http://markmail.org/message/u7rxhs4irw73c7j3
> Hi devs,
>
> In order to be able to configure synapse in other ways than the XML
> configuration language, I have abstracted out the initialization into a
> one level higher layer where you can specify the mechanism by which you
> want to load the configuration. This will not affect the usual synapse
> initialization flow, but is just an abstraction layer.
>
> With this users will be able to plug their own Synapse Configuration
> and
> ConfigurationContext with out touching the synapse code base.
>
> Following is a brief description of this improvement and if this is OK
> to be committed into synapse I will attach the patch for further reviews.
>
> * org.apache.synapse.ConfigurationBuilder
> *
> This is the abstraction layer added to Synapse for it to be able to
> extend or rather use new Configuration mechanism (DSL) than using the
> default Synapse Configuration Language. With this improvement users can
> use other Configurations by enabling the ConfigurationBuilder.
>
> Eg: ConfigurationBuilder cbuilder=ConfigurationBuilder.getInstence();
> cbuilder.setEnable(true);
> (this is done in users code not in synapse codebase)
>
> Then users must set the Builder Class in the ConfigurationBuilder.(This
> must be the fully qualified name of the Builder Class that users use to
> build the Configuration) And then users can set parameters needed to the
> build the configuration. The only restriction that Builder Class (the
> third party class that used to build the configuration) have is its
> configuration builder method must have the name
> "createSynapseConfiguration".
>
> The Configuration Builder class will find the appropriate method form
> the Builder class using the class name and the parameter list and then
> it will build the Synapse configuration.The advantage of using this
> abstraction layer is Synapse ServerManager does not depend on the third
> party Synapse configuration builders.
>
> *org.apache.synapse.ConfigurationContextBuilder*
>
> This is the abstraction layer added to the Synapse project to Start
> Axis2 and Synapse using a Different application context this works as
> same as the ConfigurationBuilder described above. Users who wants to
> extent synapse to Start using a different application context can use
> this.
> Here the restriction that is given to the Builder class is it must have
> the method "createConfigurationContext" to Create configuration
> context.The ConfigurationContextBuilder will locate the correct method
> and build the Configuration Context to start the Axis2 and Synapse in
> that context.
>
> thank you,
> Charith Dhanushka Wickramarachchi
> http://charithwiki.blogspot.com/
>
--
Asankha C. Perera
http://adroitlogic.org
http://esbmagic.blogspot.com