You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@synapse.apache.org by "Asankha C. Perera" <as...@wso2.com> on 2006/05/17 08:04:44 UTC

Spring support enhancement...

I am updating the Spring support of Synapse, and was thinking about 
allowing one to define the Spring bean mediators within the 
<definitions> section (in XML configuration terms) and refer to the 
mediators through a <spring ref="beanname"> for usage.

an example of this would be as follows

<synapse>
    <definitions>
       ....
      <spring configuration="file:/springconfig.xml"/>
       ....
    </definitions>

    </rules>
        ......
        <springmediator ref="exampleBean"/>
        ....
    </rules>
<synapse>

The Spring configuration thus would be kept outside of the synapse XML 
configuration (as the synapse configuration could be created 
programmatically as well).

The spring configuration for the above example thus would be something like

....
<bean id="exampleBean" class="examples.ExampleBean">
  <property name="beanOne"><ref bean="anotherExampleBean"/></property>
  <property name="beanTwo"><ref bean="yetAnotherBean"/></property>
  <property name="integerProperty"><value>1</value></property>
</bean>
....

Hence at runtime (mediator use time) the spring mediator would get the 
Spring ApplicationContext (from the SynapseConfiguration) and look for 
the bean named by the ref attribute and if found and it implements the 
Mediator interface, delegate mediation. This way, the Spring 
configuration could also be updated programatically (if one desires!) 
and could be reused by multiple Spring mediators.

Your thoughts on this approach are very much appreciated

asankha




---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org


Re: Spring support enhancement...

Posted by "Asankha C. Perera" <as...@wso2.com>.
This patch stores the Spring configurations as simple properties into 
the SynapseConfiguration; we also support inlined configuration

asankha


> I wasn't suggesting that we put endpoints, sequences etc. into this
> property bag. Rather, if any mediator wants to save some state /
> context / whatever, then they can put it into the property bag and save
> it. We just document saying the names are flat so use your creativity to
> make good names!
>
>   

Re: Spring support enhancement...

Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Thu, 2006-05-18 at 08:45 +0530, Asankha C. Perera wrote:
> Sanjiva
> 
> One reason I thought of keeping things separate is that most of the
> time users may want to have an endpoint named "mywebservice" and maybe
> also a sequence with the same name "mywebservice" just since it seems
> easier in a usability point of view, so that it implicitly ties
> different items together. If we kept everything together, we will need
> to use unique names for the above scenario, as well as cast back
> objects by first checking which type of objects they are when you do a
> getProperty() etc. 

I wasn't suggesting that we put endpoints, sequences etc. into this
property bag. Rather, if any mediator wants to save some state /
context / whatever, then they can put it into the property bag and save
it. We just document saying the names are flat so use your creativity to
make good names!

Sanjiva.


---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org


Re: Spring support enhancement...

Posted by Jaliya Ekanayake <jn...@gmail.com>.
Hi Asanka,

Now a test fails.
[junit] [ERROR] TEST org.apache.synapse.mediators.builtin.ValidateMediatorTest FAILED

However I was able to build it using my IDE, after changing the 
XMLConstants.W3C_XML_SCHEMA_NS_URI in ValidateMediator.java (line num 78) to its value http://www.w3.org/2001/XMLSchema
XMLConstants.W3C_XML_SCHEMA_NS_URI is in JDK 1.5.

- Jaliya
  ----- Original Message ----- 
  From: Asankha C. Perera 
  To: synapse-dev@ws.apache.org 
  Sent: Thursday, May 18, 2006 12:07 AM
  Subject: Re: Spring support enhancement...


  Jaliya

  You will need to place the Xerces 2.8.0 jars into the JAVA_HOME/lib/endorsed folders of the JDK being used. Could you try this and let me know?

  asankha

  Jaliya Ekanayake wrote: 
    Hi Devs,

    I am having trouble building synapse. The problem is to find javax.xml.validation.schema  package? Is it from jdk 1.5?

    - Jaliya



  --------------------------------------------------------------------- To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org For additional commands, e-mail: synapse-dev-help@ws.apache.org 

Re: Spring support enhancement...

Posted by Jaliya Ekanayake <jn...@gmail.com>.
Hi Devs,

I am having trouble building synapse. The problem is to find javax.xml.validation.schema  package? Is it from jdk 1.5?

- Jaliya

  ----- Original Message ----- 
  From: Asankha C. Perera 
  To: synapse-dev@ws.apache.org 
  Sent: Wednesday, May 17, 2006 11:15 PM
  Subject: Re: Spring support enhancement...


  Sanjiva

  One reason I thought of keeping things separate is that most of the time users may want to have an endpoint named "mywebservice" and maybe also a sequence with the same name "mywebservice" just since it seems easier in a usability point of view, so that it implicitly ties different items together. If we kept everything together, we will need to use unique names for the above scenario, as well as cast back objects by first checking which type of objects they are when you do a getProperty() etc. 

  asankha

  Sanjiva Weerawarana wrote: 
On Wed, 2006-05-17 at 15:56 +0530, Asankha C. Perera wrote:
  Paul

To do this without making the Synapse core (i.e. SynapseConfiguration)
dependent on Spring classes, we could keep the reference to the
ApplicationContext as just an Object?  Maybe the approach should be to
make the Spring configuration definitions "named" (as other elements
within the "definitions" section), and keep these named
"configuration"s as a Map of Objects.. just thinking out aloud. .maybe
something like...

SynapseConfiguration will keep a Map of named "configuration" Objects,
and expose methods
     Object getNamedConfiguration(String configName)
     void addNamedConfiguration(String configName, Object config)
    
Do we need such a glorified interface or can we just have:
	Object getProperty (String)
	void setProperty (String, Object)

We're quite used to having this concept around everywhere ;-).

Sanjiva.


---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org



  --------------------------------------------------------------------- To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org For additional commands, e-mail: synapse-dev-help@ws.apache.org 

Re: Spring support enhancement...

Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Wed, 2006-05-17 at 15:56 +0530, Asankha C. Perera wrote:
> Paul
> 
> To do this without making the Synapse core (i.e. SynapseConfiguration)
> dependent on Spring classes, we could keep the reference to the
> ApplicationContext as just an Object?  Maybe the approach should be to
> make the Spring configuration definitions "named" (as other elements
> within the "definitions" section), and keep these named
> "configuration"s as a Map of Objects.. just thinking out aloud. .maybe
> something like...
> 
> SynapseConfiguration will keep a Map of named "configuration" Objects,
> and expose methods
>      Object getNamedConfiguration(String configName)
>      void addNamedConfiguration(String configName, Object config)

Do we need such a glorified interface or can we just have:
	Object getProperty (String)
	void setProperty (String, Object)

We're quite used to having this concept around everywhere ;-).

Sanjiva.


---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org


Re: Spring support enhancement...

Posted by Paul Fremantle <pz...@gmail.com>.
Asankha

Interesting approach.

A couple of questions:

How would the spring application context be stored in the
SynapseConfiguration?
How would you handle more than one spring configuration?

Paul

On 5/17/06, Asankha C. Perera <as...@wso2.com> wrote:
>
> I am updating the Spring support of Synapse, and was thinking about
> allowing one to define the Spring bean mediators within the
> <definitions> section (in XML configuration terms) and refer to the
> mediators through a <spring ref="beanname"> for usage.
>
> an example of this would be as follows
>
> <synapse>
>     <definitions>
>        ....
>       <spring configuration="file:/springconfig.xml"/>
>        ....
>     </definitions>
>
>     </rules>
>         ......
>         <springmediator ref="exampleBean"/>
>         ....
>     </rules>
> <synapse>
>
> The Spring configuration thus would be kept outside of the synapse XML
> configuration (as the synapse configuration could be created
> programmatically as well).
>
> The spring configuration for the above example thus would be something
> like
>
> ....
> <bean id="exampleBean" class="examples.ExampleBean">
>   <property name="beanOne"><ref bean="anotherExampleBean"/></property>
>   <property name="beanTwo"><ref bean="yetAnotherBean"/></property>
>   <property name="integerProperty"><value>1</value></property>
> </bean>
> ....
>
> Hence at runtime (mediator use time) the spring mediator would get the
> Spring ApplicationContext (from the SynapseConfiguration) and look for
> the bean named by the ref attribute and if found and it implements the
> Mediator interface, delegate mediation. This way, the Spring
> configuration could also be updated programatically (if one desires!)
> and could be reused by multiple Spring mediators.
>
> Your thoughts on this approach are very much appreciated
>
> asankha
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: synapse-dev-help@ws.apache.org
>
>


-- 
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair

http://bloglines.com/blog/paulfremantle
paul@wso2.com

"Oxygenating the Web Service Platform", www.wso2.com

Re: Spring support enhancement...

Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Wed, 2006-05-17 at 11:34 +0530, Asankha C. Perera wrote:
> 
> The Spring configuration thus would be kept outside of the synapse XML 
> configuration (as the synapse configuration could be created 
> programmatically as well).

+1 for keeping that bit of config outside. However, it'll be good if we
can support inlined configs as well.

So how about:

<synapse>
  <rules>
    <spring id="id-of-bean-to-run-as-mediator" [src="uri-to-config"]>
      optional spring config goes here
    </spring>
  </rules>
</synapse>

That is, we create a new element called "spring" (I'd prefer not to use
the word mediator in any name as we haven't done it for anything else)
and have it identify the spring bean to run and either point to an
external config or inline a config. 

This way you can have it either way; inlined config or external config.

Sanjiva.


---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org