Turn the proxies.xml Configuration into a Spring Configfile #6

Closed
predic8 opened this Issue Oct 29, 2012 · 4 comments

Comments

Projects
None yet
3 participants
@predic8
Owner

predic8 commented Oct 29, 2012

This will make it possible to:

  • Use import statements
  • PropertyPlaceholderConfigurerer
  • ....

Besides the namespace declarations the proxies.xml file should stay as simple as it is.

@stefancretu

This comment has been minimized.

Show comment Hide comment
@stefancretu

stefancretu Oct 29, 2012

currently the config file is automatically reloaded when it changes. will that work too with spring.
(i don't know spring very well, so forgive me for asking a stupid question, i just want to make sure features are not lost.)

a PropertyPlaceholderConfigurerer configurer could already be used now in monitor-beans.xml. i would use that in case i cannot use my own interceptor tag (with attributes) in proxies.xml (see google group message). is that the reason for this change request?

would this be an optional change (both file formats supported for a while), or would it force people to change their config when updating? the way i understand semver.org the configuration is part of the public api (it does not say so explicitly). thus a backwards-incompatible change would need a version increment from 3 to 4, if following semver.

currently the config file is automatically reloaded when it changes. will that work too with spring.
(i don't know spring very well, so forgive me for asking a stupid question, i just want to make sure features are not lost.)

a PropertyPlaceholderConfigurerer configurer could already be used now in monitor-beans.xml. i would use that in case i cannot use my own interceptor tag (with attributes) in proxies.xml (see google group message). is that the reason for this change request?

would this be an optional change (both file formats supported for a while), or would it force people to change their config when updating? the way i understand semver.org the configuration is part of the public api (it does not say so explicitly). thus a backwards-incompatible change would need a version increment from 3 to 4, if following semver.

@predic8

This comment has been minimized.

Show comment Hide comment
@predic8

predic8 Oct 29, 2012

Owner

The automatic reloading will still work after the change. A monitor thread will scan the spring config and all imported files for changes. If a change is detected it will trigger a Spring context refresh.

The PropertyPlaceholderConfigurerer is just one reason. Spring offers plenty possibilites like imports and easy configuration. But the main reason is to simplify the code for parsing configuration so we can develop faster extensions for Membrane.

It will be a mandatory change. But the modifications needed to port a config to the new version will be very small. Just add some namespace declarations and the old files will be working. Yes we want to increase the version then to 4.X.

Owner

predic8 commented Oct 29, 2012

The automatic reloading will still work after the change. A monitor thread will scan the spring config and all imported files for changes. If a change is detected it will trigger a Spring context refresh.

The PropertyPlaceholderConfigurerer is just one reason. Spring offers plenty possibilites like imports and easy configuration. But the main reason is to simplify the code for parsing configuration so we can develop faster extensions for Membrane.

It will be a mandatory change. But the modifications needed to port a config to the new version will be very small. Just add some namespace declarations and the old files will be working. Yes we want to increase the version then to 4.X.

@dwaite

This comment has been minimized.

Show comment Hide comment
@dwaite

dwaite Nov 20, 2012

With this change, would their still be a separation be between monitor-beans.xml and proxies.xml?

dwaite commented Nov 20, 2012

With this change, would their still be a separation be between monitor-beans.xml and proxies.xml?

@predic8

This comment has been minimized.

Show comment Hide comment
@predic8

predic8 Nov 20, 2012

Owner

The idea is so far that Membrane will get one Spring configuration on startup. Using a config like the following Membrane will use defaults for the router, transport, message store, ...

<spring:beans xmlns="http://membrane-soa.org/router/beans/1/"
    xmlns:spring="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
                        http://membrane-soa.org/router/beans/1/ http:/www.predic8.com/schema/router/conf/router-conf.xsd">


  <soapProxy port="2000" wsdl="http://localhost:8080/buch/BuchService?wsdl">
    <regExReplacer regex=":8090" replace=":2001"/>
  </soapProxy>


</spring:beans>

But you can also config the internal components there and use the Spring features:

<spring:beans xmlns="http://membrane-soa.org/router/beans/1/"
    xmlns:spring="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
                        http://membrane-soa.org/router/beans/1/ http:/www.predic8.com/schema/router/conf/router-conf.xsd">


  <serviceProxy name="Callback" port="2001" >
    <target host="localhost" port="8090"/>
  </serviceProxy>

  <router exchangeStore="memoryExchangeStore"/>


  <transport 
            coreThreadPoolSize="5" 
            socketTimeout="30000" >
        <reverseProxying />
        <ruleMatching />
        <exchangeStore name="memoryExchangeStore" />
        <dispatching />
        <userFeature />
        <httpClient />
  </transport>

  <spring:bean id="transformerFactory" class="com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl" />

  <spring:bean id="memoryExchangeStore" class="com.predic8.membrane.core.exchangestore.LimitedMemoryExchangeStore" />

</spring:beans>

And we can split again both using the Spring import element. Our intensions are:

  • The config of proxies should be as simple as now in the proxies.xml. But we get additional namespace declarations in the root element.
  • It should be possible to use everywhere the Spring features like import, PropertyPlaceholderConfigurerer, custom beans, ...
  • The hotdeploy must be still working

What we do not know yet, is how we structure the config inside the conf folder and how we setup the samples. The samples should be as simple as possible and only showing what is needed for that particular sample. But what about the default config. Should we show all the features to a power user or make it small and simple. Maybe we need multiple configs like minimal, default and maximal.

To answer your question. We plan to have only one Spring configuration for the Membrane software. But we are not sure if we split this configuration using an import and make it look like before except the additional namespaces.

Any ideas, suggestions and critique is welcome.

Owner

predic8 commented Nov 20, 2012

The idea is so far that Membrane will get one Spring configuration on startup. Using a config like the following Membrane will use defaults for the router, transport, message store, ...

<spring:beans xmlns="http://membrane-soa.org/router/beans/1/"
    xmlns:spring="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
                        http://membrane-soa.org/router/beans/1/ http:/www.predic8.com/schema/router/conf/router-conf.xsd">


  <soapProxy port="2000" wsdl="http://localhost:8080/buch/BuchService?wsdl">
    <regExReplacer regex=":8090" replace=":2001"/>
  </soapProxy>


</spring:beans>

But you can also config the internal components there and use the Spring features:

<spring:beans xmlns="http://membrane-soa.org/router/beans/1/"
    xmlns:spring="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
                        http://membrane-soa.org/router/beans/1/ http:/www.predic8.com/schema/router/conf/router-conf.xsd">


  <serviceProxy name="Callback" port="2001" >
    <target host="localhost" port="8090"/>
  </serviceProxy>

  <router exchangeStore="memoryExchangeStore"/>


  <transport 
            coreThreadPoolSize="5" 
            socketTimeout="30000" >
        <reverseProxying />
        <ruleMatching />
        <exchangeStore name="memoryExchangeStore" />
        <dispatching />
        <userFeature />
        <httpClient />
  </transport>

  <spring:bean id="transformerFactory" class="com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl" />

  <spring:bean id="memoryExchangeStore" class="com.predic8.membrane.core.exchangestore.LimitedMemoryExchangeStore" />

</spring:beans>

And we can split again both using the Spring import element. Our intensions are:

  • The config of proxies should be as simple as now in the proxies.xml. But we get additional namespace declarations in the root element.
  • It should be possible to use everywhere the Spring features like import, PropertyPlaceholderConfigurerer, custom beans, ...
  • The hotdeploy must be still working

What we do not know yet, is how we structure the config inside the conf folder and how we setup the samples. The samples should be as simple as possible and only showing what is needed for that particular sample. But what about the default config. Should we show all the features to a power user or make it small and simple. Maybe we need multiple configs like minimal, default and maximal.

To answer your question. We plan to have only one Spring configuration for the Membrane software. But we are not sure if we split this configuration using an import and make it look like before except the additional namespaces.

Any ideas, suggestions and critique is welcome.

@predic8 predic8 closed this Apr 8, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment