diff --git a/docs/src/reference/docbook/control-bus.xml b/docs/src/reference/docbook/control-bus.xml new file mode 100644 index 0000000000..b36ded613b --- /dev/null +++ b/docs/src/reference/docbook/control-bus.xml @@ -0,0 +1,35 @@ + +
+ Control Bus + + As described in (EIP), the idea behind the Control Bus is that + the same messaging system can be used for monitoring and managing + the components within the framework as is used for + "application-level" messaging. In Spring Integration we build upon + the adapters described above so that it's possible to send Messages + as a means of invoking exposed operations. + + + + The Control Bus has an input channel that can be accessed for + invoking operations on the beans in the application context. It + also has all the common properties of a service activating endpoint, + e.g. you can specify an output channel if the result of the + operation has a return value that you want to send on to a + downsatrem channel. + + + The Control Bus executes messages on the input channel as + Spring Expression Language expressions. It takes a message, + compiles the body to an expression, adds some context, and then + executes it. The default context just exposes all the beans in the + application context by name. + + +
diff --git a/docs/src/reference/docbook/groovy.xml b/docs/src/reference/docbook/groovy.xml index 979985e0d2..bfe5e062c6 100644 --- a/docs/src/reference/docbook/groovy.xml +++ b/docs/src/reference/docbook/groovy.xml @@ -1,30 +1,34 @@ -
+
Groovy support - - With Spring Integration 2.0 we've added Groovy support allowing you to use Groovy scripting language to provide - integration and business logic  for various integration components similar to the way Spring Expression Language (SpEL) - is use to implement routing, transformation and other integration concerns. - For more information about Groovy please refer to Groovy documentation which you can find here: http://groovy.codehaus.org/ - + With Spring Integration 2.0 we've added Groovy support allowing you to + use Groovy scripting language to provide integration and business logic  for + various integration components similar to the way Spring Expression Language + (SpEL) is use to implement routing, transformation and other integration + concerns. For more information about Groovy please refer to Groovy + documentation which you can find + on the project website
Groovy configuration - - Depending on the complexity of your integration requirements Groovy scripts could be provided inline as CDATA in XML - configuration or as a reference to a file containing Groovy script. - To enable Groovy support Spring Integration defines GroovyScriptExecutingMessageProcessor which will - create a groovy Binding object identifying Message Payload as payload variable and Message Headers as - headers variable. All that is left for you to do is write script that uses these variables. - Below are couple of sample configurations: - + Depending on the complexity of your integration requirements Groovy + scripts could be provided inline as CDATA in XML configuration or as a + reference to a file containing Groovy script. To enable Groovy support + Spring Integration defines + GroovyScriptExecutingMessageProcessor which will + create a groovy Binding object identifying Message Payload as + payload variable and Message Headers as headers + variable. All that is left for you to do is write script that uses these + variables. Below are couple of sample configurations: - - Filter - <filter input-channel="referencedScriptInput"> + Filter <filter input-channel="referencedScriptInput"> <groovy:script location="some/path/to/groovy/file/GroovyFilterTests.groovy"/> </filter> @@ -32,41 +36,50 @@ <groovy:script><![CDATA[ return payload == 'good' ]]></groovy:script> -</filter> -You see that script could be included inline or via location attribute using the groovy namespace sport.  - +</filter> You see that script could be included inline + or via location attribute using the groovy namespace + sport.  - - Other supported elements are router, service-activator, transformer, splitter - - - - Another interesting aspect of using Groovy support is framework's ability to update (reload) scripts  - without restarting the Application Context. - To accomplish this all you need is specify refresh-check-delay attribute on script - element. The reason for this attribute is to make reloading of the script more efficient.  - - ]]> - - In the above example for the next 5 seconds after you update the script you'll still be using the old script and - after 5 seconds the context will be updated with the new script. This is a good example where  'near real time' - is acceptable. - - ]]> - - In the above example the context will be updated with the new script every time the script is modified. Basically this is the example of the - 'real-time' and might not be the most efficient way. - - ]]> - - - Any negative number value means the script will never be refreshed after initial initialization of application context. - DEFAULT BEHAVIOR - - Inline defined script can not be reloaded. - - + Other supported elements are router, service-activator, + transformer, splitter + Another interesting aspect of using Groovy support is framework's + ability to update (reload) scripts  without restarting the Application + Context. To accomplish this all you need is specify + refresh-check-delay attribute on script + element. The reason for this attribute is to make reloading of the script + more efficient.  <groovy:script location="..." refresh-check-delay="5000"/> + In the above example for the next 5 seconds after you update the script + you'll still be using the old script and after 5 seconds the context will + be updated with the new script. This is a good example where  'near real + time' is acceptable. <groovy:script location="..." refresh-check-delay="0"/> + In the above example the context will be updated with the new script every + time the script is modified. Basically this is the example of the + 'real-time' and might not be the most efficient way. <groovy:script location="..." refresh-check-delay="-1"/> + Any negative number value means the script will never be refreshed after + initial initialization of application context. DEFAULT BEHAVIOR + Inline defined script can not be reloaded.
+
+ Control Bus + + As described in (EIP), the idea + behind the Control Bus is that the same messaging system can be used for + monitoring and managing the components within the framework as is used for + "application-level" messaging. In Spring Integration we build upon the + adapters described above so that it's possible to send Messages as a means + of invoking exposed operations. <groovy:control-bus input-channel="operationChannel"/> + + The Control Bus has an input channel that can be accessed for + invoking operations on the beans in the application context. + + The groovy control bus executes messages on the input channel as + Groovy scripts. It takes a message, compiles the body to a Script, + customizes it with a GroovyObjectCustomizer, and then executes it. The + default customizer just exposes all the beans in the application context + as script context objects. +
diff --git a/docs/src/reference/docbook/index.xml b/docs/src/reference/docbook/index.xml index 4938bffadd..6f28145a8d 100644 --- a/docs/src/reference/docbook/index.xml +++ b/docs/src/reference/docbook/index.xml @@ -45,6 +45,10 @@ Gary Russell + + Dave + Syer + Josh Long diff --git a/docs/src/reference/docbook/jmx.xml b/docs/src/reference/docbook/jmx.xml index b3c27ead27..c8e28f9077 100644 --- a/docs/src/reference/docbook/jmx.xml +++ b/docs/src/reference/docbook/jmx.xml @@ -1,6 +1,10 @@ -
+
JMX Support Spring Integration provides Channel Adapters for receiving and @@ -17,18 +21,17 @@ <jmx:notification-listening-channel-adapter id="adapter" channel="channel" object-name="example.domain:name=publisher"/> - - The - - notification-listening-channel-adapter - - registers with an MBeanServer at startup, and the default bean name is "mbeanServer" which happens to be the same bean name generated when using Spring's <context:mbean-server/> element. If you need to use a different name be sure to include the "mbean-server" attribute. - The adapter can also accept a reference to a NotificationFilter - and a "handback" Object to provide some context that is passed back with - each Notification. Both of those attributes are optional. Extending the - above example to include those attributes as well as an explicit - MBeanServer bean name would produce the following: <jmx:notification-listening-channel-adapter id="adapter" + The + notification-listening-channel-adapter registers with + an MBeanServer at startup, and the default bean name is "mbeanServer" + which happens to be the same bean name generated when using Spring's + <context:mbean-server/> element. If you need to use a different name + be sure to include the "mbean-server" attribute. The adapter can + also accept a reference to a NotificationFilter and a "handback" Object to + provide some context that is passed back with each Notification. Both of + those attributes are optional. Extending the above example to include + those attributes as well as an explicit MBeanServer bean name would + produce the following: <jmx:notification-listening-channel-adapter id="adapter" channel="channel" mbean-server="someServer" object-name="example.domain:name=somePublisher" @@ -145,16 +148,17 @@ create an instance of the IntegrationMBeanExporter, define a bean and provide a reference to an MBeanServer and a domain name (if desired). The domain can be left out in which case the default domain - is "spring.application". <jmx:mbean-exporter domain="my.company.domain" mbean-server="mbeanServer"/> + is "org.springframework.integration". <jmx:mbean-exporter domain="my.company.domain" mbean-server="mbeanServer"/> <bean id="mbeanServer" class="org.springframework.jmx.support.MBeanServerFactoryBean"> <property name="locateExistingServerIfPossible" value="true"/> </bean> The MBean exporter is orthogonal to the one provided in Spring core - - it registers message channels and message handlers, but not itself (you - can expose the exporter itself using the standard - <context:mbean-export/> tag). + - it registers message channels and message handlers, but not itself. You + can expose the exporter itself, and certain other components in Spring + Integration, using the standard + <context:mbean-export/> tag.
diff --git a/docs/src/reference/docbook/system-management.xml b/docs/src/reference/docbook/system-management.xml index a8f7342c0b..963dedbc33 100644 --- a/docs/src/reference/docbook/system-management.xml +++ b/docs/src/reference/docbook/system-management.xml @@ -5,6 +5,7 @@ System Management + diff --git a/spring-integration-groovy/src/main/resources/org/springframework/integration/groovy/config/spring-integration-groovy-2.0.xsd b/spring-integration-groovy/src/main/resources/org/springframework/integration/groovy/config/spring-integration-groovy-2.0.xsd index c9bee625ee..5e3c4de53f 100644 --- a/spring-integration-groovy/src/main/resources/org/springframework/integration/groovy/config/spring-integration-groovy-2.0.xsd +++ b/spring-integration-groovy/src/main/resources/org/springframework/integration/groovy/config/spring-integration-groovy-2.0.xsd @@ -51,6 +51,7 @@ + @@ -65,7 +66,6 @@ -