Author: ruwan Date: Thu Jun 18 13:13:23 2009 New Revision: 39364 URL: http://wso2.org/svn/browse/wso2?view=rev&revision=39364
Log: Fixing the issues in the configuration language guide Modified: branches/esb/java/2.1/product/docs/xdoc/configuration_language.xml Modified: branches/esb/java/2.1/product/docs/xdoc/configuration_language.xml URL: http://wso2.org/svn/browse/wso2/branches/esb/java/2.1/product/docs/xdoc/configuration_language.xml?rev=39364&r1=39363&r2=39364&view=diff ============================================================================== --- branches/esb/java/2.1/product/docs/xdoc/configuration_language.xml (original) +++ branches/esb/java/2.1/product/docs/xdoc/configuration_language.xml Thu Jun 18 13:13:23 2009 @@ -194,8 +194,6 @@ <p><img alt="Synapse message flow" src="images/synapse-flow.png" width="400" height="300" /> </p> -<p></p> - <p>The Synapse ESB can operate in two modes: </p> <h3><a href="#service_mediation">Service mediation</a> / <a href="#proxy">Proxy @@ -328,8 +326,6 @@ <a href="#mediator">mediator</a>* </definitions></pre> -<p></p> - <p>The <definitions> elements in a synapse.xml holds the Synapse ESB configuration. While the <registry>, <sequence>, <endpoint>, <proxy>, <task> and <localEntry> elements refer to those @@ -375,8 +371,6 @@ different resources, or mark some resources as never expires. (e.g. Check the WSO2 ESB implementation built over the Apache Synapse ESB core) </p> -<p></p> - <h3><a id="localEntry">Local Registry / Local Entry</a> </h3> <p>The <localEntry> element is used to declare registry entries that are @@ -769,8 +763,6 @@ </tbody> </table> -<p></p> - <p>Transport specific parameters that may be set as service parameters: </p> <table border="1" cellpadding="0" cellspacing="0" style="width: 100%" @@ -920,11 +912,8 @@ <h2><a id="task">Tasks</a> </h2> -<p></p> - <p>A <task> element is used to define a Synapse Startup Task. </p> -<p></p> <pre xml:space="preserve"> <task class="mypackage.MyTask" name="string" [pinnedServers="(serverName)+"]> <property name="stringProp" value="String"/> <property name="xmlProp"> @@ -933,24 +922,18 @@ <trigger ([[count="10"]? interval="1000"] | [cron="0 * 1 * * ?"] | [once=(true | false)])/> </task></pre> -<p></p> - <p>A task is created and scheduled to run at specified time intervals or as specified by the cron expression. The Task class specifies the actual task implementation class (which must implement org.apache.synapse.startup.Task interface) to be executed at the specified interval/s, and name specifies an identifier for the scheduled task. </p> -<p></p> - <p>Fields in the task class can be set using properties provided as string literals or as XML fragments. (For example; if the task implementation class has a field named "version" with a corresponding setter method, the configuration value which will be assigned to this field before running the task can be specified using a property with the name 'version') </p> -<p></p> - <p>There are three different trigger mechanisms to schedule tasks. A simple trigger is specified specifying a 'count' and an 'interval', implying that the task will run a 'count' number of times at specified intervals. A trigger may @@ -959,27 +942,18 @@ specified as true in which case this task will be executed only once just after the initialization of Synapse </p> -<p></p> - <p>You can give a list of Synapse server names where this task should be started using pinnedServers attribute. Refer to the explanation of this attribute under proxy services for more information. </p> -<p></p> - <h2><a id="mediator">Mediators</a> </h2> -<p></p> - <p>A mediator token refers to any of the following tokens: </p> -<p></p> <pre xml:space="preserve"><a href="#send">send</a> | <a href="#drop">drop</a> | <a href="#log">log</a> | <a href="#property">property</a> | <a href="#sequence_ref">sequence</a> | <a href="#validate">validate</a> | <a href="#fault">fault</a> | <a href="#callout">callout</a> | <a href="#xslt">xslt</a> | <a href="#header">header</a> | <a href="#filter">filter</a> | <a href="#switch">switch</a> | <a href="#in">in</a> | <a href="#out">out</a> | <a href="#router">router</a> | <a href="#dblookup">dblookup</a> | <a href="#dbreport">dbreport</a> | <a href="#RMSequence">RMSequence</a> | <a href="#throttle">throttle</a> | <a href="#xquery">xquery</a> | <a href="#cache">cache</a> | <a href="#clone">clone</a> | <a href="#iterate">iterate</a> | <a href="#aggregate">aggregate</a> | <a href="#class">class</a> | <a href="#pojoCommand">pojoCommand</a> | <a href="#script">script</a> | <a href="#spring">spring</a> | <a href="#event">event</a> | <a href="#transaction">transaction</a></pre> -<p></p> - <p>In addition to the above, Synapse will be able to load custom mediators via the J2SE Service Provider model. Mediator extensions must implement the MediatorFactory interface. The Class and POJO Command mediators allow custom @@ -987,16 +961,10 @@ allows Apache BSF scripts such as Javascript, Ruby, Groovy etc to be used for mediation. </p> -<p></p> - <h3>Core Mediators </h3> -<p></p> - <h4><a id="send">Send</a> </h4> -<p></p> - <p>The send token represents a <send> element, used to send messages out of Synapse to some endpoint. The send mediator also copies any message context properties from the current message context to the reply message received on @@ -1004,8 +972,6 @@ back to the request. Messages may be correlated by WS-A MessageID, or even simple custom text labels (see the property mediator and samples) </p> -<p></p> - <p>In the simplest case shown below, the destination to send a message is implicit in the message via the 'To' address. Thus a request message will be sent to its 'To' address, and a response message would be sent back to the @@ -1014,8 +980,6 @@ changing its direction. (Note: to mark a message as a response set the property RESPONSE to true) </p> -<p></p> - <p><strong>Note:</strong> A send operation may be blocking or non-blocking depending on the actual transport implementation used. As the default NIO based http/s implementation does not block on a send, care must be taken if the same @@ -1023,79 +987,45 @@ scenario, it maybe required to first clone the message into two copies and then perform processing to avoid conflicts. </p> -<p></p> <pre xml:space="preserve"> <send/></pre> -<p></p> - <p>If the message is to be sent to one or more endpoints, then the following is used: </p> -<p></p> <pre xml:space="preserve"> <send> (endpointref | endpoint)+ </send></pre> -<p></p> - <p>where the endpointref token refers to the following: </p> -<p></p> <pre xml:space="preserve"> <endpoint key="name"/></pre> -<p></p> - <p>and the endpoint token refers to an anonymous endpoint definition. </p> -<p></p> - -<p></p> - -<p></p> - <h4><a id="drop">Drop</a> </h4> -<p></p> - <p>The drop token refers to a <drop> element which is used to stop further processing of a message: </p> -<p></p> <pre xml:space="preserve"> <drop/></pre> -<p></p> - <p>Once the <drop> mediator executes, further processing of the current message stops. A the drop mediator does not necessarily close transports. </p> -<p></p> - -<p></p> - -<p></p> - <h4><a id="log">Log</a> </h4> -<p></p> - <p>The log token refers to a <log> element which may be used to log messages being mediated: </p> -<p></p> <pre xml:space="preserve"> <log [level="string"] [separator="string"]> <property name="string" (value="literal" | expression="xpath")/>* </log></pre> -<p></p> - <p>The optional level attribute selects a pre-defined subset of properties to be logged. </p> -<p></p> - <p>e.g. </p> -<p></p> <ul> <li>simple = To, From, WSAction, SOAPAction, ReplyTo, MessageID and any properties </li> @@ -1105,24 +1035,13 @@ <li>custom = Only properties specified to the Log mediator </li> </ul> -<p></p> - <p>A separator if defined will be used to separate the attributes being logged. The default separator is the ',' comma. </p> -<p></p> - -<p></p> - -<p></p> - <h4><a id="property">Property</a> </h4> -<p></p> <pre xml:space="preserve"> <property name="string" [action=set|remove] (value="literal" | expression="xpath") [scope=transport|axis2|axis2-client]/></pre> -<p></p> - <p>The property token refers to a <property> element which is a mediator that has no direct impact on the message but rather on the message context flowing through Synapse. The properties set on a message can be later retrieved @@ -1133,12 +1052,9 @@ Synapse message context scope. Using the property element with action specified as "remove" you can remove any existing message context properties. </p> -<p></p> - <p>There are some well-defined properties that you can get/set on the Synapse message context scope: </p> -<p></p> <ul> <li>RESPONSE - 'true' means the message is to be marked as a response message </li> @@ -1155,12 +1071,9 @@ fault </li> </ul> -<p></p> - <p>There are some Axis2 and module properties that are useful which are set at scope="axis2" </p> -<p></p> <ul> <li>MercurySequenceKey - can be an identifier specifying an Mercury internal sequence key, and </li> @@ -1168,23 +1081,16 @@ the sequence </li> </ul> -<p></p> - <p>There are some Axis2 client side properties/options that are useful which are set at scope="axis2-client" </p> -<p></p> <ul> <li>FORCE_HTTP_1.0 - forces outgoing http/s messages to use HTTP 1.0 (instead of the default 1.1) </li> </ul> -<p></p> - <h5>The synapse:get-property() XPath extension function </h5> -<p></p> - <p>The get-property() function allows any XPath expression used in a configuration to lookup information from the current message context. It is possible to retrieve properties previously set with the property mediator, @@ -1192,20 +1098,11 @@ header. The function accepts the scope as an optional parameter as shown below: </p> -<p></p> - <p>synapse:get-property( [(axis2 | axis2-client | transport),] <property_name> [,<dateformat>] ) </p> -<p></p> - -<p></p> - -<p></p> - <p>Some useful properties from the Synapse message context follows: </p> -<p></p> <ul> <li>SYSTEM_DATE - Returns the current date as a String. Optionally a date format as per standard date format may be supplied. e.g. @@ -1221,8 +1118,6 @@ <li>OperationName - returns the operation name for the message </li> </ul> -<p></p> - <p>In addition to the above, one may use the get-property() function to retrieve Axis2 message context properties or transport headers. e.g. synapse:get-property('transport', 'USER_AGENT') </p> @@ -1253,27 +1148,15 @@ 'Content-Type' transport header, which is going to be the Content-Type of the current message </ul> -<p></p> - <h4><a id="sequence_ref">Sequence</a> </h4> -<p></p> <pre xml:space="preserve"> <sequence key="name"/></pre> -<p></p> - <p>A sequence ref token refers to a <sequence> element which is used to invoke a named sequence of mediators. </p> -<p></p> - -<p></p> - -<p></p> - <h4><a id="validate">Validate</a> </h4> -<p></p> <pre xml:space="preserve"> <validate [source="xpath"]> <property name="validation-feature-id" value="true|false"/>* <schema key="string"/>+ @@ -1282,8 +1165,6 @@ </on-fail> </validate></pre> -<p></p> - <p>The <validate> mediator validates the result of the evaluation of the source xpath expression, against the schema specified. If the source attribute is not specified, the validation is performed against the first child of the @@ -1293,19 +1174,10 @@ href="http://xerces.apache.org/xerces2-j/features.html";>http://xerces.apache.org/xerces2-j/features.html</a>) </p> -<p></p> - -<p></p> - -<p></p> - <h3>Transformation Mediators </h3> -<p></p> - <h4><a id="fault">Fault</a> </h4> -<p></p> <pre xml:space="preserve"> <makefault [version="soap11|soap12|pox"]> <code (value="literal" | expression="xpath")/> <reason (value="literal" | expression="xpath")> @@ -1314,8 +1186,6 @@ <detail>? </makefault></pre> -<p></p> - <p>The fault mediator transforms the current message into a fault message, but does NOT send it. The <send> mediator needs to be invoked to send a fault message created this way. The fault message "To" header is set to the @@ -1323,12 +1193,6 @@ message. If a 'version' attribute is specified, the created fault message will be created as a selected SOAP 1.1, SOAP 1.2 or POX fault. </p> -<p></p> - -<p></p> - -<p></p> - <h4><a id="callout">Callout</a> </h4> <pre xml:space="preserve"> <callout serviceURL="string" [action="string"]> <configuration [axis2xml="string"] [repository="string"]/>? @@ -1353,15 +1217,12 @@ <h4><a id="xslt">XSLT</a> </h4> -<p></p> <pre xml:space="preserve"> <xslt key="string" [source="xpath"]> <property name="string" (value="literal" | expression="xpath")/>* <feature name="string" value="true| false" />* <resource location="..." key="..."/>* </xslt></pre> -<p></p> - <p>The <xslt> mediator applies the specified XSLT transformation to the selected element of the current message payload. If the source element is not specified, it defaults to the first child of the soap body. Optionally @@ -1382,8 +1243,6 @@ <variable name="string" type="string" [key="string"] [expression="xpath"] [value="string"]/>? </xquery> </pre> -<p></p> - <p>The XQuery mediator can be used to perform an XQuery transformation. The 'key' attribute specifies the XQuery transformation, and the optional 'target' attribute specifies the node of the message that should be transformed. This @@ -1415,16 +1274,11 @@ <li>XQItemType.XQITEMKIND_ELEMENT -> ELEMENT </li> </ul> -<p></p> - <h4><a id="header">Header</a> </h4> -<p></p> <pre xml:space="preserve"> <header name="qname" (value="literal" | expression="xpath") [action="set"]/> <header name="qname" action="remove"/></pre> -<p></p> - <p>The <header> mediator sets or removes a specified header from the current soap infoset. Currently the set header only supports simple valued headers. In the future we may extend this to have XML structured headers by @@ -1432,25 +1286,14 @@ attribute specifies whether the mediator should set or remove the header. If omitted, it defaults to a set-header. </p> -<p></p> - -<p></p> - -<p></p> - <h3>Selection Mediators </h3> -<p></p> - <h4><a id="filter">Filter</a> </h4> -<p></p> <pre xml:space="preserve"> <filter (source="xpath" regex="string") | xpath="xpath"> mediator+ </filter></pre> -<p></p> - <p>The <filter> mediator either test the given xpath expression as a boolean expression, or match the evaluation result of a source xpath expression as a String against the given regular expression. If the test succeeds, the @@ -1472,15 +1315,8 @@ element in sequence, while failed messages will be mediated using the set of mediators enclosed in the else element in sequence </p> -<p></p> - -<p></p> - -<p></p> - <h4><a id="switch">Switch</a> </h4> -<p></p> <pre xml:space="preserve"> <switch source="xpath"> <case regex="string"> mediator+ @@ -1490,33 +1326,25 @@ </default>? </switch></pre> -<p></p> - <p>The <switch> mediator will evaluate the given source xpath expression into its string value, and match it against the given regular expressions. If the specified cases does not match and a default case exists, it will be executed. </p> -<p><a id="in"></a> </p> +<p><a id="in"/> </p> <h4><a id="out">In / Out</a> </h4> -<p></p> <pre xml:space="preserve"><in><br /> mediator+ </in><br /></pre> -<p></p> <pre xml:space="preserve"><out> mediator+ </out></pre> -<p></p> - <p><br /> </p> -<p></p> - <p>The In and Out mediators will execute the child mediators over the current message if the message matches the direction of the mediator. Hence all incoming messages would pass through the "<in>" mediators and vice versa. @@ -1556,19 +1384,10 @@ inline sequence and a refered sequence at the same time. The same applies to endpoit of the target as well. </p> -<p></p> - -<p></p> - -<p></p> - <h3>Database Mediators </h3> -<p></p> - <h4><a id="dblookup">DB-lookup</a> </h4> -<p></p> <pre xml:space="preserve"><dblookup> <connection> <pool> @@ -1594,12 +1413,6 @@ </statement>+ </dblookup></pre> -<p></p> - -<p></p> - -<p></p> - <p>The dblookup mediator is capable of executing an arbitrary SQL select statement, and then set some resulting values as local message properties on the message context. The DB connection used maybe looked up from an external @@ -1607,7 +1420,6 @@ is established and used. Apache DBCP connection pools support the following properties: </p> -<p></p> <ul> <li>autocommit = true | false </li> <li>isolation = Connection.TRANSACTION_NONE | @@ -1628,8 +1440,6 @@ <li>validationquery = String </li> </ul> -<p></p> - <p>More than one statement may be specified, and the SQL statement may specify parameters which could be specified as values or XPath expressions. The types of parameters could be any valid SQL types. Only the first row of a result set @@ -1638,11 +1448,8 @@ defines the name under which the result is stored in the Synapse message context, and the column attribute specifies a column number or name . </p> -<p></p> - <h4><a id="dbreport">DB-report</a> </h4> -<p></p> <pre xml:space="preserve"><dbreport> <connection> <pool> @@ -1667,32 +1474,15 @@ </statement>+ </dblreport></pre> -<p></p> - -<p></p> - -<p></p> - <p>The dbreport mediator is very similar to the dblookup mediator, but writes information to a Database, using the specified insert SQL statement. </p> -<p></p> - -<p></p> - -<p></p> - <h3>Advanced Mediators </h3> -<p></p> - <h4><a id="RMSequence">RMSequence</a> </h4> -<p></p> <pre xml:space="preserve"> <RMSequence (correlation="xpath" [last-message="xpath"]) | single="true" [version="1.0|1.1"]/></pre> -<p></p> - <p>The <RMSequence> mediator can be used to create a sequence of messages to communicate via WS-Reliable Messaging with an WS-RM enabled endpoint (<enableRM>). The simple use case of this mediator is to specify a @@ -1706,27 +1496,14 @@ attribute the WS-RM specification version to be used can be specified, 1.0 or 1.1. </p> -<p></p> - -<p></p> - -<p></p> - <h4><a id="throttle">Throttle</a> </h4> -<p></p> <pre xml:space="preserve"><throttle [onReject="string"] [onAccept="string"] id="string"> (<policy key="string"/> | <policy>..</policy>) <onReject>..</onReject>? <onAccept>..</onAccept>? </throttle></pre> -<p></p> - -<p></p> - -<p></p> - <p>The Throttle mediator can be used for rate limiting as well as concurrency based limiting. A WS-Policy dictates the throttling configuration and may be specified inline or loaded from the registry. Please refer to the samples @@ -1739,11 +1516,8 @@ 'onAccept' sequence references or inline sequences define how accepted and rejected messages are to be handled. </p> -<p></p> - <h4><a id="cache">Cache</a> </h4> -<p></p> <pre xml:space="preserve"> <cache [id="string"] [hashGenerator="class"] [timeout="seconds"] [scope=(per-host | per-mediator)] collector=(true | false) [maxMessageSize="in-bytes"]> <onCacheHit [sequence="key"]> @@ -1752,8 +1526,6 @@ <implementation type=(memory | disk) maxSize="int"/> </cache></pre> -<p></p> - <p>The <cache> mediator will evaluate the hash value of an incoming message as described in the optional hash generator implementation (which should be a class implementing the org.wso2.caching.digest.DigestGenerator @@ -1773,11 +1545,8 @@ element may define if the cache is disk or memory based, and the 'maxSize' attribute defines the maximum number of elements to be cached. </p> -<p></p> - <h4><a id="clone">Clone</a> </h4> -<p></p> <pre xml:space="preserve"> <clone [continueParent=(true | false)]> <target [to="uri"] [soapAction="qname"] [sequence="sequence_ref"] [endpoint="endpoint_ref"]> <sequence> @@ -1789,19 +1558,14 @@ </target>+ </clone></pre> -<p></p> - <p>The clone mediator closely resembles the Message Splitter EIP and will split the message into number of identical messages which will be processed in parallel. The original message cloned can be continued or dropped depending on the boolean value of the optional 'continueParent' attribute. Optionally a custom 'To' address and/or a 'Action' may be specified for cloned messages </p> -<p></p> - <h4><a id="iterate">Iterate</a> </h4> -<p></p> <pre xml:space="preserve"> <iterate [continueParent=(true | false)] [preservePayload=(true | false)] (attachPath="xpath")? expression="xpath"> <target [to="uri"] [soapAction="qname"] [sequence="sequence_ref"] [endpoint="endpoint_ref"]> <sequence> @@ -1813,8 +1577,6 @@ </target>+ </iterate></pre> -<p></p> - <p>The iterate mediator implements another EIP and will split the message into number of different messages derived from the parent message by finding matching elements for the XPath expression specified. New messages will be @@ -1825,11 +1587,8 @@ creating the splitted messages, and defaults to 'false', in which case the splitted messages would contain the split elements as the SOAP body. </p> -<p></p> - <h4><a id="aggregate">Aggregate</a> </h4> -<p></p> <pre xml:space="preserve"> <aggregate> <correlateOn expression="xpath"/>? <completeCondition [timeout="time-in-seconds"]> @@ -1840,8 +1599,6 @@ </onComplete> </aggregate></pre> -<p></p> - <p>The aggregate mediator implements the Message Aggregator EIP and will aggregate the messages or responses for splitted messages using either the clone or iterate mediators. At the same time it can aggregate messages on the @@ -1855,14 +1612,9 @@ expression specified by the attribute 'expression' on the 'onComplete' element. </p> -<p></p> - <h4><a id="event">Event</a> </h4> -<p></p> - -<p><pre xml:space="preserve"> <syn:eventPublisher eventSourceName="event-source-name"/></pre> -</p> +<pre xml:space="preserve"> <syn:eventPublisher eventSourceName="event-source-name"/></pre> <p>Event mediator publishes events to the given event source. Thus, the presence of defined event sources are necessary prior to the usage of this @@ -1870,10 +1622,7 @@ <h4><a id="transaction">Transaction</a> </h4> -<p></p> - -<p><pre xml:space="preserve"> <syn:transaction action="transaction-action" /></pre> -</p> +<pre xml:space="preserve"> <syn:transaction action="transaction-action" /></pre> <p>Transaction mediator can provide transaction facility for a set of mediators defined as its child mediators. A transaction mediator with the action "new" @@ -1885,33 +1634,21 @@ <h3>Extension mediators </h3> -<p></p> - <h4><a id="class">Class</a> </h4> -<p></p> <pre xml:space="preserve"> <class name="class-name"> <property name="string" value="literal"> (either literal or XML child) </property> </class> </pre> -<p></p> - <p>The class mediator creates an instance of a custom specified class and sets it as a mediator. The class must implement the org.apache.synapse.api.Mediator interface. If any properties are specified, the corresponding setter methods are invoked on the class, once, during initialization. </p> -<p></p> - -<p></p> - -<p></p> - <h4><a id="pojoCommand">POJOCommand</a> </h4> -<p></p> <pre xml:space="preserve"> <pojoCommand name="class-name"> ( <property name="string" value="string"/> | @@ -1922,8 +1659,6 @@ )* </pojoCommand> </pre> -<p></p> - <p>The pojoCommand mediator creates an instance of the specified command class - which may implement the org.apache.synapse.Command interface or should have a public void method "public void execute()". If any properties are specified, @@ -1936,20 +1671,8 @@ behaviour is expected or not via the Read, Update and ReadAndUpdate properties. </p> -<p></p> - -<p></p> - -<p></p> - <h3><a id="script">Scripting language mediators</a> </h3> -<p></p> - -<p></p> - -<p></p> - <p>Synapse supports Mediators implemented in a variety of scripting languages such as JavaScript, Python or Ruby. There are two ways of defining script mediators, either with the script program statements stored in a separate file @@ -1958,11 +1681,8 @@ mediator using a script off the registry (local or remote) is defined as follows: </p> -<p></p> <pre xml:space="preserve"> <script key="string" language="string" [function="script-function-name"]/></pre> -<p></p> - <p>The property key is the registry key to load the script. The language attribute specifies the scripting language of the script code (e.g. "js" for Javascript, "rb" for ruby, "groovy" for Groovy, "py" for Python..). The @@ -1973,28 +1693,20 @@ the script mediator returns this value. An inline script mediator has the script source embedded in the configuration as follows: </p> -<p></p> <pre xml:space="preserve"> <script language="string">...script source code...<script/></pre> -<p></p> - <p>The execution context environment of the script has access to the Synapse MessageContext predefined in a script variable named 'mc' . An example of an inline mediator using JavaScript/E4X which returns false if the SOAP message body contains an element named 'symbol' which has a value of 'IBM' would be: </p> -<p></p> <pre xml:space="preserve"> <script language="js">mc.getPayloadXML()..symbol != "IBM";<script/></pre> -<p></p> - <p>Synapse uses the Apache <a href="http://jakarta.apache.org/bsf/";>Bean Scripting Framework</a> for the scripting language support, any script language supported by BSF may be used to implement a Synapse Mediator. </p> -<p></p> - <p>Implementing a Mediator with a script language can have advantages over using the built in Synapse Mediator types or implementing a custom Java class Mediator. Script Mediators have all the flexibility of a class Mediator with @@ -2010,65 +1722,39 @@ getPayloadXML and setPayloadXML, E4X XML objects, and when using Ruby, REXML documents. </p> -<p></p> - <h3>Extensibility of Synapse </h3> -<p></p> - <p>The Synapse configuration language could be easily extended, with configuration extensions as well as mediation extensions. The Spring mediator is such an example. </p> -<p></p> - <h4>Spring Configuration </h4> -<p></p> - <p>A Spring configuration could be created as a localEntry or remote registry entry providing a URL or a key reference to a Registry. The configuration is then created on first use or as necessary (as per registry lookup semantics) by the mediators which reference this configuration. </p> -<p></p> <pre xml:space="preserve"> <localEntry key="string"/> <localEntry key="string" src="url"/></pre> -<p></p> - <p>The name attribute specifies a unique name for the configuration, and the src, key or inlined XML references to the Spring configuration </p> -<p></p> - -<p></p> - -<p></p> - <h4><a id="spring">Spring mediator</a> </h4> -<p></p> <pre xml:space="preserve"> <spring:spring bean="exampleBean1" key="string"/></pre> -<p></p> - <p>The <spring> element creates an instance of a mediator, which is managed by Spring. This Spring bean must implement the Mediator interface for it to act as a Mediator. The key will reference the Spring ApplicationContext/Configuration used for the bean </p> -<p></p> - -<p></p> - <p>The <spring> element creates an instance of a mediator, which is managed by Spring. This Spring bean must implement the Mediator interface for it to act as a Mediator. The key will reference the Spring ApplicationContext/Configuration used for the bean </p> -<p></p> - <h4><a id="spring1">Rule Mediator - Java Rule mediator </a></h4> <p>Rule mediator has been implemented based on <strong>Java Rule Engine API @@ -2207,8 +1893,8 @@ the SOAP message. There is a sample to illustrate this capability. Please refers the sample guide.</p> -<p>A Custom Java Object (‘input’ / ‘output’ with type -‘custom’) can be configured using 'property' inside 'input / +<p>A Custom Java Object ("input" / "output" with type +"custom") can be configured using 'property' inside 'input / output' definitions. There is a sample to illustrate this capability. Please refers the sample guide.</p> _______________________________________________ Esb-java-dev mailing list [email protected] https://wso2.org/cgi-bin/mailman/listinfo/esb-java-dev
