You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@synapse.apache.org by as...@apache.org on 2008/01/28 09:44:05 UTC
svn commit: r615763 [4/5] - in /webservices/synapse/trunk/java: ./
modules/core/ modules/core/src/main/java/org/apache/synapse/
modules/core/src/main/java/org/apache/synapse/config/
modules/core/src/main/java/org/apache/synapse/config/xml/ modules/core...
Modified: webservices/synapse/trunk/java/src/site/resources/Synapse_Configuration_Language.html
URL: http://svn.apache.org/viewvc/webservices/synapse/trunk/java/src/site/resources/Synapse_Configuration_Language.html?rev=615763&r1=615762&r2=615763&view=diff
==============================================================================
--- webservices/synapse/trunk/java/src/site/resources/Synapse_Configuration_Language.html (original)
+++ webservices/synapse/trunk/java/src/site/resources/Synapse_Configuration_Language.html Mon Jan 28 00:43:56 2008
@@ -115,19 +115,210 @@
background-color: #f0f0f0;
padding: 2px;
margin: 18px 0px 4px 0px;
+ }
+ .data-table{
+ font-family:Verdana,Arial,Helvetica,sans-serif;
+ font-size:11px;
+ border:0px;
+ margin:0px;
+ border:solid 1px #cdcdcd;
+ }
+ .data-table th{
+ background-color:#eeeeee;
+ border-bottom:solid 1px #8d8d8d;
+ padding-top:5px;
+ padding-left:3px;
+ text-align:left;
+ }
+ .data-table td{
+ padding-top:4px;
+ padding-left:3px;
+ border-bottom:solid 1px #e1e1e1;
}</style>
</head>
<body>
-<h1>Synapse Configuration Language</h1>
-<p>The Synapse configuration language is designed to support a processing
-model where messages come into Synapse, are processed via some number of
-mediators and then delivered to an endpoint somewhere. It is currently
-direction agnostic, but directionality can easily be added as a selection
-mechanism for mediators (see below for details).</p>
+<table border="0" style="width: 100%">
+ <caption></caption>
+ <tbody>
+ <tr>
+ <td><h1>Apache Synapse ESB - Configuration</h1>
+ </td>
+ <td><img alt="Synapse logo" src="images/synapse-logo-web2.png"
+ width="197" height="82"></td>
+ </tr>
+ </tbody>
+</table>
+
+<h3>Overview</h3>
+
+<p>An Apache Synapse Enterprise Service Bus (ESB) engine is driven off a set
+of simple text/xml configuration files. This allows the configuration to be
+easily hand edited, backed up from the file system, or even included into
+version control for easier management and control (e.g. moving a
+configuration from development, through QA, staging and into production). The
+configuration files that drives the Synapse ESB are as follows:</p>
+<ul>
+ <li>The Synapse configuration file - synapse.xml</li>
+ <li>The underlying Axis2 engine configuration file - axis2.xml</li>
+ <li>Resources referenced from the Registry</li>
+</ul>
+
+<p>While the axis2.xml configures the underlying transport and Web services
+support, the synapse.xml configures the mediation rules and configuration for
+the ESB. While any changes performed on the axis2.xml requires a restart
+(e.g. for enabling a transport such as JMS), the synapse.xml could be made to
+reference different configuration elements off a set of multiple files - that
+are served through the built-in Registry. When using the Registry to hold
+pieces of the configuration, certain elements such as endpoint definitions,
+sequences and local entries could be updated dynamically while the Synapse
+ESB executes, the the Registry could trigger a re-load as configured. </p>
+
+<h2>The Synapse Configuration (synapse.xml)</h2>
+
+<p>As the diagram below depicts, the Synapse configuration defines the Proxy
+services, Endpoints, Sequences and Startup jobs managed by the Synapse ESB.
+It also defines the interface to the Registry/Repository being used by the
+engine. Typically the Synapse ESB is deployed between the actual client and a
+backend service implementation to mediate the message flow in between. Thus
+the Synapse ESB can accept a message on behalf of the actual service, perform
+authentication, validation, transformation, logging, routing based on the
+content etc. and then decide the destination target endpoint for the message
+and direct it to an actual service implementation. The Synapse ESB can also
+detect timeouts, transport failures during communication or introduce load
+balancing, throttling or caching where necessary. For fault scenarios such as
+authentication failure, or schema validation failure, the Synapse ESB can be
+configured to return a custom message or a fault to the requesting client
+without forwarding the request to the actual service.</p>
+
+<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 services</a></h3>
+
+<p>In Service mediation, the Synapse ESB exposes a service endpoint on the
+ESB, that accepts messages from clients. Typically these services acts as
+proxies for existing (external) services, and the role of Synapse would be to
+"mediate" these messages before they are proxied to the actual service. In
+this mode, Synapse could expose a service already available in one transport,
+over a different transport; or expose a service that uses one schema or WSDL
+as a service that uses a different schema or WSDL etc. A Proxy service could
+define the transports over which the service is exposed, and point to the
+mediation sequences that should be used to process request and response
+messages through the proxy service. A proxy service maybe a SOAP or REST/POX
+service over http/s or SOAP, POX, Plain Text or Binary / Legacy service for
+other transports such as JMS and VFS file systems - e.g. CSV content being
+the payload</p>
+
+<h3><a name="#message_mediation">Message mediation</a></h3>
+
+<p>In Message mediation, Synapse can act as a transparent proxy for clients -
+if they are directed to point to the Synapse ESB as a http proxy. This way,
+Synapse could be configured to filter all messages on a network for logging,
+access control etc, and could "mediate" messages without the explicit
+knowledge of the original client. If Synapse receives a message that is not
+accepted by any proxy service, this message is handled through message
+mediation as well. Message mediation always processes messages according to
+the mediation sequence defined as "main".</p>
+
+<h2>Concepts and configuration elements overview</h2>
+
+<h3><a href="#mediator">Mediators</a> and <a href="#sequence">Mediation
+Sequences</a></h3>
+
+<p>The Synapse ESB defines a 'mediator' as a component that is performs some
+mediation action on a message during the process flow. Thus a mediator gets
+full access to a message at the point where it is defined to gain control,
+and could inspect the message, modify it or take an external action depending
+on some attributes or values of the current message. A mediation sequence,
+commonly called a 'sequence' is a list of such mediators. A sequence may be
+named for re-use, or defined in-line or anonymously within a configuration.
+Sequences may be defined within the synapse.xml configuration or within the
+Registry. Writing a custom mediator in Java is easy and the supplementary
+documentation provides more details on this. The 'Class' and 'POJO (command)"
+mediators allows one to plugin a Java class easily into the Synapse engine
+with minimal effort. In addition, the Script mediator allows one to provide
+an Apache BSF script (e.g. Javascript, Ruby, Groovy etc) for mediation.</p>
-<h3>Overall Structure</h3>
+<p>A Synapse configuration holds two special sequences named as "main" and
+"fault". These may be defined within the synapse.xml, or externally via the
+Registry. If either is not found, a suitable default is generated at runtime
+by the ESB. The default "main" sequence will simple send a message without
+mediation, while the default "fault" sequence would log the message including
+the payload and any error/exception encountered and stop further processing.
+The 'fault' sequence executes whenever Synapse itself encounters an error
+while processing a message - or when a fault handler has not been defined to
+handle exceptions. A sequence can assign another named sequence as its
+"fault" handler sequence, and control branches to the fault handler if an
+error is encountered during the execution of the initial sequence.</p>
+
+<h3><a href="#endpoint">Endpoints</a></h3>
+
+<p>An Endpoint definition within Synapse defines an external service endpoint
+and any attributes or semantics that should be followed when communicating
+with that endpoint. An endpoint definition can be named for re-use, or
+defined in-line or anonymously within a configuration. Typically an endpoint
+would be based on a service Address or a WSDL. Additionally the Synapse ESB
+supports Failover and Load-balance endpoints - which are defined over a group
+of endpoints. Endpoints may be defined within the synapse.xml configuration
+or within the Registry.</p>
+
+<h3><a href="#task">Tasks</a></h3>
+
+<p>A Task is a custom Java class that implements the
+org.apache.synapse.startup.Task interface that defines a single "public void
+execute()" method. Such a task can be scheduled and managed via the Synapse
+ESB. The scheduling information for a task can be specified in the cron
+format or a simple format by the user. A task may also be specified as a
+one-time task where required, and can be used to trigger a callout or inject
+a message into the Synapse ESB.</p>
+
+<h3><a href="#registry">Remote Registry</a> and <a name="Local" id="Local"
+href="#localEntry">Local Registry (Local Entries)</a></h3>
+
+<p>A Synapse configuration can refer to an external Registry / Repository for
+resources used such as WSDL's, Schemas, Scripts, XSLT or XQuery
+transformations etc. One or more remote registries may be hidden or merged
+behind a local Registry interface defined to a Synapse configuration.
+Resources from an external registry are looked up using "keys" - which are
+known to the external registry. The Synapse ESB ships with a simple URL based
+registry implementation that uses the file system for storage of resources,
+and URL's or fragments as "keys". </p>
+
+<p>A Registry may define a duration for which a resource served may be cached
+by the Synapse runtime. If such a duration is specified, the Synapse ESB is
+capable of refreshing the resource after cache expiry to support dynamic
+re-loading of resource at runtime. Optionally, a configuration could define
+certain "keys" to map to locally defined entities. These entities may refer
+to a source URL or file, or defined as in-line XML or text within the
+configuration itself. If a Registry contains a resource whose "key" matches
+the key of a locally defined entry, the local entry shadows the resource
+available in the Registry. Thus it is possible to override Registry resources
+locally from within a configuration. To integrate Synapse with a custom / new
+Registry or repository, one needs to implement the
+org.apache.synapse.registry.Registry interface to suit the actual Registry
+being used.</p>
+
+<h2>The Axis2 Configuration (axis2.xml)</h2>
+
+<p>The axis2.xml file configures the underlying Axis2 web services engine for
+the Synapse ESB. The axis2.xml thus defines the transports enabled, and other
+configuration parameters associated. A change to the axis2 configuration
+requires a hard re-start of the Synapse ESB. By default the non-blocking
+http/s and the Apache VFS file system based transport are enabled for
+listening of messages, while the non-blocking http/s, VFS and JMS transports
+are enabled for sending messages out. Sample configurations to
+enable/configure the other transports are provided within the default
+axis2.xml file, and can be easily uncommented and modified. The sample JMS
+configuration shipped is for a default ActiveMQ 4.1.x installation.</p>
+
+<h2>The contents of the Synapse.xml configuration</h2>
<p>A Synapse configuration looks like the following at the top level:</p>
<pre> <definitions>
@@ -142,148 +333,89 @@
<p></p>
-<p>The Synapse configuration is held in a single XML file called the
-'synapse.xml' and this may refer to other configuration fragments and
-resources - which may be held in an external Registry or Repository. The
-Synapse release ships with a simple URL based registry implementation that
-could use a file system, web server etc. as the registry/repository backend.
-When using the file system, the contents could be held in a version
-controlled directory so that changes could be controlled and moved from Dev,
-QA, Staging to Production. The Synapse engine and the simple URL registry
-implementation support caching and dynamic refreshing of some configuration
-elements [sequences & endpoints] and resources such as XSLT's, Scripts,
-XSDs etc. Synapse can be easily integrated with an external registry by
-implementing the 'org.apache.synapse.registry.Registry' interface.</p>
-
-<p></p>
-
-<p>A Synapse configuration refers to resources stored on an external Registry
-via 'keys'. The 'localEntry' elements in a configuration provides the
-capability to define a new resource or configuration fragment; or to override
-any existing resource available under a registry with a local replacement. An
-example would be to use a localEntry to override the production endpoint
-definition for development time. Local entries could direct to an external
-URL for the resource content, or provide the text or XML content inline.</p>
-
-<p></p>
-
-<p>Synapse accepts messages for mediation via the exposed/enabled transports.
-These are configured via the 'axis2.xml' configuration file. By default the
-http, https and VFS transports are enabled. Using the JMS and Mail transports
-requires that these be enabled and configured for your environment via the
-axis2.xml file. Once a proxy service is defined, it could be configured to
-listen for messages on one or more of the enabled transports. A proxy service
-then listens for messages over the selected transports by exposing a virtual
-service. A proxy service maybe a SOAP or POX service over http/s or SOAP, POX
-or Plain Text service for other transports such as JMS and VFS - e.g. CSV
-content being its payload. Thus Synapse is able to switch between these
-message formats and transports, as well as introduce or terminate QoS aspects
-such as WS-Security/RM through proxy services. </p>
-
-<p></p>
-
-<p>Sequences define an ordered execution of a set of 'Mediators', where each
-'Mediator' gets full access to the current message flowing through the
-system. Synapse ships with a common set of mediators that can handle most of
-the common tasks such as - logging, content based routing, transformations
-using XSLT/XQuery, validation, BSF scripting language based or Java class
-based mediation, database reporting or lookup, caching, throttling, cloning,
-splitting and aggregation etc. Writing a custom mediator in Java is easy and
-the supplementary documentation provides more details. The 'Class' and 'POJO'
-mediators allows one to plugin a Java class easily into the Synapse engine
-with minimal effort. </p>
-
-<p></p>
-
-<p>Typically proxy services associates mediation sequences for processing
-incoming and outgoing messages. A Synapse configuration holds two special
-sequences called the 'main' and 'fault' sequences. The 'main' sequence
-executes for any message that is not received by any particular proxy
-service. When using the http/s transports - this refers to the concept of
-'Message Mediation' where Synapse may be configured as a transparent proxy to
-its clients. In this scenario, Synapse could receive all messages on the wire
-and mediate them as necessary and send them to the final destinations. The
-'fault' sequence executes whenever Synapse itself encounters an error while
-processing a message - or when a fault handler has not been defined to handle
-exceptions. Typically a fault sequence would log the failed message and any
-other context information.</p>
-
-<p></p>
-
-<p>Endpoints define aspects to be considered when sending a message out from
-Synapse. Endpoints also allow load balancing, fail-over and timeout scenarios
-to be handled - or to introduce WS-Security, Addressing or RM for messages
-sent to an endpoint. An endpoint maybe defined as an Address or using a WSDL
-definition.</p>
-
-<p></p>
-
-<h2><a name="registry">Registry</a></h2>
-
-<p>The <registry> element is used to define a remote registry which are
-referenced from within the configuration. The registry provider specifies an
-implementation class for the registry used, and optionally a number of
-configuration parameters may be specified to configure the connection to the
-registry.</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 discussed above, the built-in mediator elements names are
+already registered with the Synapse engine. Custom mediators written by a
+user may be included into the library directory, and would be dynamically
+picked up in a Sun JDK environment. A list of mediators found directly as
+children under the <definitions> element would be treated as the "main"
+sequence, if a named sequence with the name "main" cannot be found.</p>
+
+<h2><a name="registry1" id="registry">Registry</a></h2>
+
+<p>The <registry> element is used to define the remote registry used by
+the configuration. The registry provider specifies an implementation class
+for the registry implementation used, and optionally a number of
+configuration parameters as may be required for the configuration of the
+connection to the registry.</p>
<pre> <registry provider="string"/>
<parameter name="string">text | xml</parameter>*
</registry></pre>
-<p>Registry entries loaded from a remote registry are cached within Synapse
-as dictated by the registry, and reloaded after the cache periods expires.
-Hence it is possible to define configuration elements such as (dynamic)
-sequences and endpoints, as well as resources such as XSLT's or XSDs off the
-registry, and update the configuration as these change dynamically over
-time.</p>
+<p>Registry entries loaded from a remote registry may be cached as dictated
+by the registry, and reloaded after the cache periods expires if a newer
+version is found. Hence it is possible to define configuration elements such
+as (dynamic) sequences and endpoints, as well as resources such as XSLT's,
+Scripts or XSDs off the registry, and update the configuration as these are
+allowed to dynamically change over time.</p>
+
+<p>Synapse ships with a built-in URL based registry implementation called the
+"SimpleURLRegistry" and this can be configured as follows:</p>
+<pre>e.g.
+<registry provider="org.apache.synapse.registry.url.SimpleURLRegistry">
+ <parameter name="root">file:./repository/conf/sample/resources/</parameter>
+ <parameter name="cachableDuration">15000</parameter>
+</registry></pre>
+
+<p>The "root" parameter specifies the root URL of the Registry for loaded
+resources. The SimpleURLRegistry keys are path fragments, that when combined
+with the root prefix would form the full URL for the referenced resource. The
+"cachableDuration" parameter specifies the number of milliseconds for which
+resources loaded from the Registry should be cached. More advanced registry
+implementations allows different cachable durations to be specified for
+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 name="localEntry">Local Entry</a></h3>
+<h3><a name="localEntry">Local Registry / Local Entry</a></h3>
<p>The <localEntry> element is used to declare registry entries that
are local to the Synapse instance, as shown below</p>
<pre> <localEntry key="string" [src="url"]>text | xml</localEntry></pre>
-<p>These entries are top level entries which are set globally for the entire
-system. Values of these entries can be retrieved via the extension XPath
-function "synapse:get-property(prop-name)".</p>
+<p>These entries are top level entries which are globally visible within the
+entire system. Values of these entries can be retrieved via the extension
+XPath function "synapse:get-property(prop-name)" and the keys of these
+entries could be specified wherever a registry key is expected within the
+configuration.</p>
<p>An entry can be static text specified as inline text or static XML
specified as an inline XML fragment or specified as a URL (using the src
-attribute). These local entries can override any existing entries with the
-same keys of the remote registry. </p>
-
-<p></p>
+attribute). A local entry shadows any entry with the same name from a remote
+Registry.</p>
+<pre>e.g.
+<localEntry key="version">0.1</localEntry>
+<localEntry key="validate_schema">
+ <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
+ ...
+ </xs:schema>
+ </localEntry>
+<localEntry key="xslt-key-req" src="file:repository/conf/sample/resources/transform/transform.xslt"/></pre>
<h2><a name="sequence">Sequences</a></h2>
<p>A <sequence> element is used to define a sequence of mediators that
-can be invoked later by name.</p>
-<pre> <sequence name="string" [onError="string"] [key="string"] [trace="enable"]>
- mediator*
- </sequence></pre>
-
-<p>If the configuration defines a sequence named "main" then it is considered
-as the main mediation sequence of Synapse. If such a sequence is not defined
-locally, and a registry has been specified, the registry is looked up for a
-key named "main" to find the main mediation sequence. Synapse also supports
-the specification of mediators directly within the <definitions> tag,
-and if any mediators are present, will be considered to constitute the main
-sequence. In the absence of a main sequence, the Synapse runtime will create
-a default main sequence that consists of an implicit send mediator.</p>
-
-<p>Synapse considers a sequence named "fault", or in its absence a registry
-entry with a key "fault" as its general fault handler sequence. If Synapse
-encounters an erroneous situation while processing a message through a
-sequence, it executes the defined error handling sequence for the current
-context - which may be specified as the 'onError' sequence for a sequence
-mediator. If a fault sequence is not specified or cannot be found through the
-registry, Synapse will create a default fault sequence that will perform a
-default logging of the message at the log level 'full'.</p>
-
-<p>If an optional error handler sequence name is specified on any sequence
-through the attribute 'onError', an exception on this sequence will invoke
-the sequence specified by this key.</p>
+can be invoked later by name. The sequences named "main" and "fault" has
+special significance in a Synapse configuration. The "main" sequence handles
+any message that is accepted for '<a href="#message_mediation">Message
+Mediation</a><a>', and the "fault" sequence is invoked if Synapse encounters
+a fault, and a custom fault handler is not specified for the sequence via its
+"onError" attribute. If the "main" or "fault" sequences are not defined
+locally or not found in the Registry, the Synapse ESB defines suitable
+defaults at initialization.</a></p>
<p>A Dynamic Sequence may be defined by specifying a key reference to a
registry entry. As the remote registry entry changes, the sequence will
@@ -291,28 +423,43 @@
expiration. If tracing is enabled on a sequence, all messages being processed
through the sequence would write tracing information through each mediation
step to the trace.log file configured via the log4j.properties configuration.
-Setting the trace log level to TRACE would additionally dump the message at
-each mediation.</p>
-
-<p></p>
+Setting the trace log level to TRACE would additionally dump the message and
+detailed trace information at each mediation step. A tracing enabled sequence
+propagates this setting to invoked sub-sequences.</p>
+<pre> <sequence name="string" [onError="string"] [key="string"] [trace="enable"]>
+ mediator*
+ </sequence></pre>
+<pre>e.g.
+<sequence name="main" onError="errorHandler">
+ .. <!-- a 'main' sequence that invokes the sequence named 'errorHandler' on a fault --> ..
+</sequence></pre>
+<pre><sequence key="sequence/dynamic_seq_1.xml"/>
+where "sequence/dynamic_seq_1.xml" refers to the following sequence definition from the registry:
+
+<sequence name="dynamic_sequence" xmlns="http://ws.apache.org/ns/synapse">
+ ..
+</sequence></pre>
<h2><a name="endpoint">Endpoints</a></h2>
<p>An <endpoint> element defines a destination for an outgoing message.
An endpoint may be specified as an address endpoint, WSDL based endpoint, a
-load balanced endpoint or a fail-over endpoint as follows:</p>
-<pre><endpoint [name="string"] [key="string"][trace="enable"]>
+load balancing endpoint or a fail-over endpoint as follows:</p>
+<pre><endpoint [name="string"] [key="string"] [trace="enable"]>
<a href="#address-endpoint">address-endpoint</a> | <a href="#wsdl-endpoint">wsdl-endpoint</a> | <a href="#load-balanced-endpoint">load-balanced-endpoint</a> | <a href="#fail-over-endpoint">fail-over-endpoint</a>
</endpoint> </pre>
-<p>All above endpoint types can have a name attribute. Such named endpoints
-can be refered by other endpoints, which only contain the key attribute. For
-example if there is an endpoint named as "foo", following endpoint can be
-used in any place, where "foo" has to be used. A tracing enabled endpoint
-would generate trace information into the trace log for each message that
-passes through.</p>
+<p>All above endpoint types can have a name attribute, and such named
+endpoints can be reffered by other endpoints, through the key attribute. For
+example if there is an endpoint named as "foo", the following endpoint can be
+used in any place, where "foo" has to be used.</p>
<pre><endpoint key="foo"/></pre>
+<p>The "trace" attribute turns on detailed trace information for messages
+being sent to the endpoint. These are available in the trace.log configured
+via the log4j.properties file. Setting the trace log level to TRACE will dump
+detailed trace information including message payloads. </p>
+
<h4><a name="address-endpoint">Address Endpoint</a></h4>
<p>Address endpoint is an endpoint defined by specifying the EPR and other
@@ -328,18 +475,26 @@
failed. If this attribute is not specified, endpoint will never be recovered
after a failure.</p>
-<p></p>
-
-<p>Address endpoints can timeout the responses if they failed to arrive
-Synapse in predefined time duration. This is done by the timeout elements.
-duration element inside the timeout element contains duration for the timeout
-in seconds. action element specifies the action to be performed once a
-timeout occurs. Allowed actions are discard and fault. If discard is
-specified, responses arriving after the timeout will be discarded without
-further processing. If fault is specified as the action, fault sequence
-applicable for the endpoint will be activated as soon as the timeout occurs
-and responses will not be processed after that.</p>
-<pre><address uri="endpoint-address" format="soap11|soap12|pox|get" [optimize="mtom|swa"]>
+<p>Address endpoints can timeout if responses fail to arrive at Synapse by a
+predefined timeout-duration specified in seconds. The timeout action
+specifies whether to discard responses that arrives late, or to trigger a
+fault. Synapse has a periodic timeout handler that triggers itself at each 15
+second interval. Thus endpoint timeouts will have a +/- error on actual
+trigger time. Though this can be minimized by setting a System property
+"synapse.timeout_handler_interval" to a millisecond duration below the
+desired endpoint timeout, care must be taken as a lesser value may have a
+higher overhead on the system. </p>
+
+<p>An endpoint that fails may be suspended for a specified duration after
+such a failure, during which new messages will not be processed through the
+endpoint. The 'suspendDurationOnFailure' could specify an optional value in
+seconds for which this endpoint should be suspended.</p>
+
+<p>QoS aspects such as WS-RM and WS-Security and WS-Addressing may be enabled
+on messages sent to an endpoint using the enableRM, enableSec and
+enableAddressing elements. Optionally, the WS-RM and WS-Security policies
+could be specified using the 'policy' attributes.</p>
+<pre><address uri="endpoint-address" [format="soap11|soap12|pox|get"] [optimize="mtom|swa"]>
<enableRM [policy="key"]/>?
<enableSec [policy="key"]/>?
<enableAddressing/>?
@@ -350,38 +505,25 @@
</timeout>?
</address></pre>
-<p>Following are some sample uri definitions.</p>
-
-<p>HTTP</p>
-<pre>http://localhost:9000/soap/SimpleStockQuoteService</pre>
-
-<p>JMS full definition</p>
-<pre>jms:/SimpleStockQuoteService?transport.jms.ConnectionFactoryJNDIName=QueueConnectionFactory&java.naming.factory.initial=org.apache.activemq.jndi.ActiveMQInitialContextFactory&java.naming.provider.url=tcp://localhost:61616&transport.jms.DestinationType=topic</pre>
-
-<p>JMS connection factory reference which is defined in JMSListener of
-axis2.xml as a parameter</p>
-<pre>jms:/SimpleStockQuoteService?transport.jms.ConnectionFactory=myQueueConnectionFactory</pre>
-
-<p>SMTP</p>
-<pre>mailto:guest@host</pre>
-
-<p>Directory</p>
-<pre>vfs:file:///home/user/directory</pre>
-
-<p>File</p>
-<pre>vfs:file:///home/user/file</pre>
-
-<p>FTP</p>
-<pre>vfs:ftp://guest:guest@localhost/directory?vfs.passive=true</pre>
+<p>Following are some sample address URI definitions.</p>
+<pre>e.g.
+HTTP http://localhost:9000/soap/SimpleStockQuoteService
+JMS jms:/SimpleStockQuoteService?transport.jms.ConnectionFactoryJNDIName=QueueConnectionFactory&
+ java.naming.factory.initial=org.apache.activemq.jndi.ActiveMQInitialContextFactory&
+ java.naming.provider.url=tcp://localhost:61616&transport.jms.DestinationType=topic
+Mail mailto:guest@host
+File vfs:file:///home/user/directory
+ vfs:file:///home/user/file
+ vfs:ftp://guest:guest@localhost/directory?vfs.passive=true</pre>
<h4><a name="wsdl-endpoint">WSDL Endpoint</a></h4>
-<p>WSDL endpoint is an endpoint based on a WSDL document. It can extract the
-target EPR from a given WSDL. The WSDL document can be specified either as a
-URI or as an inlined definition within the configuration. The service and
-port name containing the target EPR has to be specified in service and port
+<p>WSDL endpoint is an endpoint definition based on a specified WSDL
+document. The WSDL document can be specified either as a URI or as an inlined
+definition within the configuration. The service and port name containing the
+target EPR has to be specified with the 'service' and 'port' (or 'endpoint')
attributes respectively. enableRM, enableSec, enableAddressing,
-suspendDurationOnFailure and timeout elements are same as for the Address
+suspendDurationOnFailure and timeout elements are same as for an Address
endpoint.</p>
<pre><wsdl [uri="wsdl-uri"] service="qname" port/endpoint="qname">
<wsdl:definition>...</wsdl:definition>?
@@ -404,23 +546,22 @@
specifies the load balance policy (algorithm) to be used for selecting the
target endpoint. Currently only the roundRobin policy is supported. failover
attribute determines if the next endpoint should be selected once the
-currently selected endpoint has failed. Default is true. The set of endpoints
-among which the load is distributed can be listed under the loadBalance
-element. Those endpoints can belong to any endpoint type mentioned in this
-document. For example, failover endpoints can be listed inside the load
-balance endpoint to load balance between failover groups.</p>
+currently selected endpoint has failed, and defaults to true. The set of
+endpoints among which the load is distributed can be listed under the
+'loadBalance' element. Those endpoints can belong to any endpoint type
+mentioned in this document. For example, failover endpoints can be listed
+inside the load balance endpoint to load balance between failover groups
+etc.</p>
-<p></p>
-
-<p>The optional session element makes the endpoint a session affinity based
+<p>The optional 'session' element makes the endpoint a session affinity based
load balancing endpoint. If it is specified, sessions are bound to endpoints
in the first message and all successive messages for those sessions are
-directed to their associated endpoints. http sessions are supported
-currently, which identifies sessions based on http cookies. failover
+directed to their associated endpoints. Only http sessions are currently
+supported, and identifies sessions based on http cookies. The 'failover'
attribute mentioned above is not applicable for session affinity based
-endpoints and it is always set to false. If it is required to have failover
-behavior in session affinity based load balance endpoints, list failover
-endpoints as the target endpoints.</p>
+endpoints and it is always considered as set to false. If it is required to
+have failover behavior in session affinity based load balance endpoints, list
+failover endpoints as the target endpoints.</p>
<pre><session type="http"/>?
<loadBalance [policy="roundRobin"] [failover="true|false"]>
<endpoint .../>+
@@ -429,12 +570,12 @@
<h4><a name="fail-over-endpoint">Failover Endpoint</a></h4>
<p>Failover endpoints send messages to the listed endpoints with the
-following failover behavior. At the start, first listed endpoint is selected
-as the primary and all other endpoints are treated as backups. Incoming
-messages are always sent only to the primary endpoint. If the primary
-endpoint fails, next active endpoint is selected as the primary and failed
-endpoint is marked as inactive. Thus it sends messages successfully as long
-as there is at least one active endpoint among the listed endpoints.</p>
+following failover behavior. At the start, the first listed endpoint is
+selected as the primary and all other endpoints are treated as backups.
+Incoming messages are always sent only to the primary endpoint. If the
+primary endpoint fails, next active endpoint is selected as the primary and
+failed endpoint is marked as inactive. Thus it sends messages successfully as
+long as there is at least one active endpoint among the listed endpoints.</p>
<pre><failover>
<endpoint .../>+
</failover></pre>
@@ -442,7 +583,7 @@
<h2><a name="proxy">Proxy service</a></h2>
<p>A <proxy> element is used to define a Synapse Proxy service.</p>
-<pre> <proxy name="string" [transports="(http |https |jms )+|all"] [pinnedServers="(serverName)+"]>
+<pre> <proxy name="string" [transports="(http |https |jms |.. )+|all"] [pinnedServers="(serverName )+"]>
<description>...</description>?
<target [inSequence="name"] [outSequence="name"] [faultSequence="name"] [endpoint="name"]>
<inSequence>...</inSequence>?
@@ -452,33 +593,33 @@
</target>?
<publishWSDL key="string" uri="string">
<description>...</description> | <definitions>...</definitions>
- <publishWSDL>?
- <enableSec/>? // These two tags will removed after the recognition of the Security and RM can be done by looking at policy
+ </publishWSDL>?
+ <enableSec/>?
<enableRM/>?
- <policy key="string">...</policy>? // optional service level policies
- // (e.g. WS-Security and/or WS-RM policies)
- <parameter name="string"> // optional service parameters
- string | xml // (e.g. transport.jms.ConnectionFactory)
+ <policy key="string">...</policy>? // optional service level policies such as (e.g. WS-Security and/or WS-RM policies)
+ <parameter name="string"> // optional service parameters such as (e.g. transport.jms.ConnectionFactory)
+ string | xml
</parameter>
</proxy></pre>
<p>A proxy service is created and exposed on the specified transports through
-the underlying Axis2 instance, exposing service EPR's as per the standard
-Axis2 conventions - based on the service name. (Note: that currently Axis2
-does not allow custom URI's to be set for services on some transports.) The
-Proxy service could be exposed over all enabled Axis2 transports such as
-http, https, JMS etc. or on a subset of these. </p>
+the underlying Axis2 engine, exposing service EPR's as per the standard Axis2
+conventions - based on the service name. (Note: that currently Axis2 does not
+allow custom URI's to be set for services on some transports such as http/s)
+The Proxy service could be exposed over all enabled Axis2 transports such as
+http, https, JMS, Mail and File etc. or on a subset of these as specified
+with the optional 'transports' attribute.</p>
<p>You can give a list of synapse server names where this proxy service
-should be deployed using pinnedServers attribute. It takes the server names
+should be deployed using 'pinnedServers' attribute. It takes the server names
separated by comma or space character. If there is no pinned server list then
-proxy service will start in all server instances. If a pinned server names
-list is given it will only start in the given named Synapse server instances.
-The Synapse server name is taken as follows. First it looks for the system
-property SynapseServerName. If it is not found it will take the hostname of
-the machine. Otherwise it will default to name 'localhost'. You can give a
-name to the starting Synapse server instance using ./synapse.sh
--DSynapseServerName=<ServerName></p>
+proxy service will be started in all server instances. If a pinned server
+names list is given it will only start in the given named Synapse server
+instances. The Synapse server name picked up from the system property
+'SynapseServerName', failing which the hostname of the machine would be used
+or default to 'localhost'. You can give a name to a Synapse server instance
+as ./synapse.sh -DSynapseServerName=<ServerName> or by editing the
+wrapper.conf where Synapse is started as a service.</p>
<p>Each service could define the target for received messages as a named
sequence or a direct endpoint. Target inSequence or endpoint is required for
@@ -487,29 +628,60 @@
policies, and any service parameters could be passed into the proxy services'
AxisService instance using the parameter elements (e.g. the JMS destination
etc). If the proxy service should enable WS-Reliable Messaging or Security,
-the appropriate modules could be engaged, and specified policies will
-apply.</p>
+the appropriate modules could be engaged, and specified service level
+policies will apply.</p>
<p>A Dynamic Proxy may be defined by specifying the properties of the proxy
as dynamic entries by refering them with the key. (For example one could
-specify the inSequence or endpoint with the remote key, without defining it
-in the local configuration) As the remote registry entry changes, the
-properties of the proxy will dynamically be updated accordingly. (Note: proxy
-service definition itself can not be specified to be dynamic; i.e <proxy
+specify the inSequence or endpoint with a remote key, without defining it in
+the local configuration) As the remote registry entry changes, the properties
+of the proxy will dynamically be updated accordingly. (Note: proxy service
+definition itself can not be specified to be dynamic; i.e <proxy
key="string"/> is wrong)</p>
<p></p>
-<p>Transport specific parameters</p>
+<p>You can give the following as service parameters:</p>
-<table border="1" style="width: 100%">
+<table border="0" cellpadding="0" cellspacing="0" style="width: 100%"
+class="data-table">
<caption></caption>
<tbody>
<tr>
- <td>Transport</td>
- <td>Require</td>
- <td>Parameter</td>
- <td>Description</td>
+ <th>Parameter</th>
+ <th>Value</th>
+ <th>Default</th>
+ <th>Description</th>
+ </tr>
+ <tr>
+ <td>useOriginalwsdl</td>
+ <td>true|false</td>
+ <td>false</td>
+ <td>Use the given WSDL instead of generating the WSDL.</td>
+ </tr>
+ <tr>
+ <td>modifyUserWSDLPortAddress</td>
+ <td>true|false</td>
+ <td>true</td>
+ <td>(Effective only with useOriginalwsdl=true) If true (default) modify
+ the port addresses to current host.</td>
+ </tr>
+ </tbody>
+</table>
+
+<p></p>
+
+<p>Transport specific parameters that may be set as service parameters:</p>
+
+<table border="0" cellpadding="0" cellspacing="0" style="width: 100%"
+class="data-table">
+ <caption></caption>
+ <tbody>
+ <tr>
+ <th>Transport</th>
+ <th>Require</th>
+ <th>Parameter</th>
+ <th>Description</th>
</tr>
<tr>
<td>JMS</td>
@@ -522,15 +694,13 @@
<td></td>
<td>Optional</td>
<td>transport.jms.Destination</td>
- <td>The JMS destination name (Defaults to a Queue with the service
- name)</td>
+ <td>The JMS destination name (Defaults to the service name)</td>
</tr>
<tr>
<td></td>
<td>Optional</td>
<td>transport.jms.DestinationType</td>
- <td>The JMS destination type. Accept values 'queue' or 'topic'
- (default: queue)</td>
+ <td>The JMS destination type. Accept values 'queue' or 'topic'</td>
</tr>
<tr>
<td></td>
@@ -635,22 +805,19 @@
</tbody>
</table>
-<p>*VFS Transport URI examples</p>
-
-<p>file:///directory/filename.ext</p>
-
-<p>file:////somehost/someshare/afile.txt</p>
-
-<p>jar:../lib/classes.jar!/META-INF/manifest.mf</p>
-
-<p>jar:zip:outer.zip!/nested.jar!/somedir</p>
-
-<p>ftp://myusername:mypassword@somehost/pub/downloads/somefile.tgz[?vfs.passive=true]</p>
+<p>VFS Transport URI examples (See <a
+href="http://commons.apache.org/vfs/filesystems.html">http://commons.apache.org/vfs/filesystems.html
+for more samples</a>)</p>
+<pre>file:///directory/filename.ext
+file:////somehost/someshare/afile.txt
+jar:../lib/classes.jar!/META-INF/manifest.mf
+jar:zip:outer.zip!/nested.jar!/somedir
+ftp://myusername:mypassword@somehost/pub/downloads/somefile.tgz[?vfs.passive=true]</pre>
<h2><a name="task">Tasks</a></h2>
<p>A <task> element is used to define a Synapse Startup Task.</p>
-<pre> <task class="org.my.synapse.Task" name="string" [pinnedServers="(serverName)+"]>
+<pre> <task class="mypackage.MyTask" name="string" [pinnedServers="(serverName)+"]>
<property name="stringProp" value="String"/>
<property name="xmlProp">
<somexml>config</somexml>
@@ -658,8 +825,8 @@
<trigger ([[count="10"]? interval="1000"] | [cron="0 * 1 * * ?"] | [once=(true | false)])/>
</task></pre>
-<p>A task is created and scheduled to run at the specified time intervals or
-as specified by the cron expression. The Task class specifies the actual task
+<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>
@@ -668,7 +835,7 @@
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>
+task can be specified using a property with the name 'version')</p>
<p>There are three different trigger mechanisms to schedule tasks. A simple
trigger is specified specifying a 'count' and an 'interval', implying that
@@ -679,41 +846,47 @@
just after the initialization of Synapse</p>
<p>You can give a list of synapse server names where this task should be
-started using pinnedServers attribute. It takes the server names separated
-by comma or space character. If there is no pinned server list then task will
-start in all server instances. If a pinned server names list is given it
-will only start in the given named Synapse server instances. The Synapse
-server name is taken as follows. First it looks for the system property
-SynapseServerName. If it is not found it will take the hostname of the
-machine. Otherwise it will default to name 'localhost'. You can give a name
-to the starting Synapse server instance using ./synapse.sh
--DSynapseServerName=<ServerName></p>
+started using pinnedServers attribute. Refer to the explanation of this
+attribute under proxy services for more information.</p>
<h2><a name="mediator">Mediators</a></h2>
<p>A mediator token refers to any of the following tokens:</p>
-<pre><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="#makefault">makefault</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="#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> </pre>
+<pre><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="#makefault">makefault</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="#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> </pre>
<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.</p>
+MediatorFactory interface. The Class and POJO Command mediators allow custom
+Java code to be easily invoked during mediation, while the Script mediator
+allows Apache BSF scripts such as Javascript, Ruby, Groovy etc to be used for
+mediation.</p>
<h3>Core Mediators</h3>
<h4><a name="send">Send</a></h4>
-<p>The send token represents a <send> element. The <send> element
-is used to send messages out of Synapse to some endpoint, and stop further
-mediation of the message. The send mediator also copies any message context
-properties from the current message context to the reply message received on
-the execution of the send operation. This allows the reply messages to be
-correlated to the original messages in a flexible manner. Messages may be
-correlated by WS-A MessageID, or even simple custom text labels. Also see the
-property mediator.</p>
-
-<p>In the simplest case, the place to send the message to is implicit in the
-message (via a property of the message itself)- that is indicated by the
-following:</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 the execution of the send operation so that the response could be
+correlated 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>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
+client. Removing the 'To' address of a message targets it back to the client,
+and thus a request message received may be returned to the client after
+changing its direction. (Note: to mark a message as a response set the
+property RESPONSE to true)</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 message must be sent and then further processed (e.g. transformed).
+In such a scenario, it maybe required to first clone the message into two
+copies and then perform processing to avoid conflicts.</p>
<pre> <send/></pre>
<p>If the message is to be sent to one or more endpoints, then the following
@@ -725,18 +898,18 @@
<p>where the endpointref token refers to the following:</p>
<pre> <endpoint key="name"/></pre>
-<p>and the endpoint token refers to an anonymous endpoint defined.</p>
+<p>and the endpoint token refers to an anonymous endpoint definition.</p>
<p></p>
<h4><a name="drop">Drop</a></h4>
-<p>The drop token refers to a <drop> element which is used to drop a
-message:</p>
+<p>The drop token refers to a <drop> element which is used to stop
+further processing of a message:</p>
<pre> <drop/></pre>
<p>Once the <drop> mediator executes, further processing of the current
-message stops.</p>
+message stops. A the drop mediator does not necessarily close transports.</p>
<p></p>
@@ -771,29 +944,34 @@
<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 which does not specify the
-action thus set on the message context applies only to the current message
-and can be later retrieved through the synapse:get-property(prop-name)
-extension function. If a scope is specified for a property, the property
-could be set as a transport header property or an (underlying) Axis2 message
-context property, or as a Axis2 client option or as an Axis2 message context
-property. If a scope is not specified, it will default to the Synapse message
-context scope. Using the property element with action specified as "remove"
-you can remove the message context properties if available.</p>
+context flowing through Synapse. The properties set on a message can be later
+retrieved through the synapse:get-property(prop-name) XPath extension
+function. If a scope is specified for a property, the property could be set
+as a transport header property or an (underlying) Axis2 message context
+property, or as a Axis2 client option. If a scope is not specified, it will
+default to the Synapse message context scope. Using the property element with
+action specified as "remove" you can remove any existing message context
+properties.</p>
-<p>There are some well-defined properties that you can get/set:</p>
+<p>There are some well-defined properties that you can get/set on the Synapse
+message context scope:</p>
<ul>
- <li>RESPONSE - 'true' means the message is marked as a response message</li>
- <li>OUT_ONLY - 'true' means the message is marked as an out-only message
- that does not expect a response</li>
- <li>ERROR_CODE - this is set to any error message code encountered</li>
- <li>ERROR_MESSAGE - this is set to any error message text encountered</li>
- <li>ERROR_DETAIL - this is set to any error message detail text
- encountered</li>
+ <li>RESPONSE - 'true' means the message is to be marked as a response
+ message</li>
+ <li>OUT_ONLY - 'true' means the message is to be marked as an out-only
+ message that does not expect a response</li>
+ <li>ERROR_CODE - this is set to any error message code encountered during a
+ fault</li>
+ <li>ERROR_MESSAGE - this is set to any error message text encountered
+ during a fault</li>
+ <li>ERROR_DETAIL - this is set to any error message detail text encountered
+ during a fault</li>
+ <li>ERROR_EXCEPTION - this is set to any Java Exception encountered during
+ a fault</li>
</ul>
-<p>There are also some Axis2 and module properties that are useful to set
-(with scope="axis2"):</p>
+<p>There are some Axis2 and module properties that are useful which are set
+at scope="axis2"</p>
<ul>
<li>Sandesha2RMSpecVersion - can be '1.0' or '1.1'</li>
<li>Sandesha2SequenceKey - can be an identifier specifying an Sandesha
@@ -802,8 +980,47 @@
terminate the sequence</li>
</ul>
+<p>There are some Axis2 client side properties/options that are useful which
+are set at scope="axis2-client"</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>
+
+<h5>The synapse:get-property() XPath extension function</h5>
+
+<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,
+and/or information from the Synapse or Axis2 message contexts or transport
+header. The function accepts the scope as an optional parameter as shown
+below:</p>
+
+<p>synapse:get-property( [(axis2 | axis2-client | transport),]
+<property_name> [,<dateformat>] ) </p>
+
<p></p>
+<p>Some useful properties from the Synapse message context follows:</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.
+ synapse:get-property(SYSTEM_DATE, "yyyy.MM.dd G 'at' HH:mm:ss z") or
+ get-property(SYSTEM_DATE)</li>
+ <li>SYSTEM_TIME - Returns the current time in milliseconds. (i.e. the
+ difference, measured in milliseconds, between the current time and
+ midnight, January 1, 1970 UTC)</li>
+ <li>To, From, Action, FaultTo, ReplyTo, MessageID the message To and Action
+ and WS-Addressing properties</li>
+ <li>MESSAGE_FORMAT - returns the message format - i.e. returns pox, get,
+ soap11 or soap12</li>
+ <li>OperationName - returns the operation name for the message</li>
+</ul>
+
+<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>
+
<h4><a name="sequence_ref">Sequence</a></h4>
<pre> <sequence key="name"/></pre>
@@ -826,8 +1043,8 @@
attribute is not specified, the validation is performed against the first
child of the SOAP body of the current message. If the validation fails, the
on-fail sequence of mediators is executed. Properties could be used to turn
-on/off some of the underlying features of the validator (See
-http://xerces.apache.org/xerces2-j/features.html)</p>
+on/off some of the underlying features of the validator (See <a
+href="http://xerces.apache.org/xerces2-j/features.html">http://xerces.apache.org/xerces2-j/features.html</a>)</p>
<p></p>
@@ -846,26 +1063,27 @@
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 "faultTo" of the original message if such a header existed on the
-original message.</p>
+original message. If a 'version' attribute is specified, the created fault
+message will be created as a selected SOAP 1.1 or SOAP 1.2 fault.</p>
<p></p>
<h4><a name="xslt">XSLT</a></h4>
<pre> <xslt key="string" [source="xpath"]>
<property name="string" (value="literal" | expression="xpath")/>*
- <feature name="string" value="true| false" />
+ <feature name="string" value="true| false" />*
</xslt></pre>
<p>The <xslt> mediator applies the specified XSLT transformation to the
-given element. If the source element is not specified, it defaults to the
-first child of the soap body. Optionally parameters (XSLT) could be passed
-into the transformations through the <property> elements.The
-<feature> defines a any feature which should be set to the
-TransformerFactory by explicitly. The feature
+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
+parameters (XSLT) could be passed into the transformations through the
+'property' elements.The 'feature' elements defines any features which should
+be set to the TransformerFactory by explicitly. The feature
'http://ws.apache.org/ns/synapse/transform/feature/dom' turns on DOM based
transformations instead of serializing elements into Byte streams and/or
-temporary files. However, this may not prove to be stable for all scenarios -
-especially for large message transformation.</p>
+temporary files. Though this would be better in performance than using byte
+streams, sometimes it may not work for all transformations.</p>
<p></p>
@@ -874,7 +1092,7 @@
<header name="qname" action="remove"/></pre>
<p>The <header> mediator sets or removes a specified header from the
-current soap message. Currently the set header only supports simple valued
+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
embedding the XML content within the element itself. The optional action
attribute specifies whether the mediator should set or remove the header. If
@@ -891,8 +1109,9 @@
<p>The <filter> mediator either test the given xpath expression as a
boolean expression, or match the evaluation result of a source xpath
-expression against the given regular expression. If the test succeeds, the
-filter mediator will execute the enclosed mediators in sequence.</p>
+expression as a String against the given regular expression. If the test
+succeeds, the filter mediator will execute the enclosed mediators in
+sequence.</p>
<p></p>
@@ -952,7 +1171,7 @@
</connection>
<statement>
<sql>select something from table where something_else = ?</sql>
- <parameter [value="" | expression=""] type="int|string"/>*
+ <parameter [value="" | expression=""] type="CHAR|VARCHAR|LONGVARCHAR|NUMERIC|DECIMAL|BIT|TINYINT|SMALLINT|INTEGER|BIGINT|REAL|FLOAT|DOUBLE|DATE|TIME|TIMESTAMP"/>*
<result name="string" column="int|string"/>*
</statement>+
</dblookup></pre>
@@ -986,8 +1205,8 @@
</ul>
<p>More than one statement may be specified, and the SQL statement may
-specify parameters which could be specified as values or expressions. The
-types of parameters could be any valid SQL types. Only the first row of a
+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 will be considered and any others are ignored. The single
<result> element contains the 'name' and the column' attributes. The
'name' attribute defines the name under which the result is stored in the
@@ -1015,7 +1234,7 @@
</connection>
<statement>
<sql>insert into something values(?, ?, ?, ?)</sql>
- <parameter [value="" | expression=""] type="int|string"/>*
+ <parameter [value="" | expression=""] type="CHAR|VARCHAR|LONGVARCHAR|NUMERIC|DECIMAL|BIT|TINYINT|SMALLINT|INTEGER|BIGINT|REAL|FLOAT|DOUBLE|DATE|TIME|TIMESTAMP"/>*
</statement>+
</dblreport></pre>
@@ -1047,37 +1266,49 @@
<p></p>
<h4><a name="throttle">Throttle</a></h4>
-<pre><throttle [onReject="string"] [onAccept="string"] [id="string"]>
- <policy key="string"/> | <policy>..</policy>
- <onReject>..</onReject>
- <onAccept>..</onAccept>
+<pre><throttle [onReject="string"] [onAccept="string"] id="string">
+ (<policy key="string"/> | <policy>..</policy>)
+ <onReject>..</onReject>?
+ <onAccept>..</onAccept>?
</throttle></pre>
<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. The Throttle mediator could be
-added in the request path for rate limiting and concurrent access limitation.
-When using for concurrent access limitation, the same throttle mediator ID
-must be triggered on the response flow so that completed responses are
-deducted from the available limit. The acceptance or rejection sequence is
-executed depending on the evaluation of the throttling policy against the
-current message.</p>
+specified inline or loaded from the registry. Please refer to the samples
+document for sample throttling policies. The Throttle mediator could be added
+in the request path for rate limiting and concurrent access limitation. When
+using for concurrent access limitation, the same throttle mediator 'id' must
+be triggered on the response flow so that completed responses are deducted
+from the available limit. (i.e. two instances of the throttle mediator with
+the same 'id' attribute in the request and response flows). The 'onReject'
+and 'onAccept' sequence references or inline sequences define how accepted
+and rejected messages are to be handled.</p>
<h4><a name="xquery">XQuery</a></h4>
-<pre><xquery [key="string"] [target="xpath"]>
- <variable name="string" type="string" [key="string"] [expression="xpath"]/>?
+<pre><xquery key="string" [target="xpath"]>
+ <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
-'variable' elements define a variable that could be bound to the dynamic
-context of the XQuery engine in order to access those variables through the
-XQuery script . The name of the variable corresponds to the name of variable
-declaration in the XQuery script. The 'type' of the variable must be a valid
-type defined by the JSR-000225 (XQJ API). The supported types are:</p>
+'key' attribute specifies the XQuery transformation, and the optional
+'target' attribute specifies the node of the message that should be
+transformed. This defaults to the first child of the SOAP body of the
+payload. The 'variable' elements define a variable that could be bound to the
+dynamic context of the XQuery engine in order to access those variables
+through the XQuery script .</p>
+
+<p>It is possible to specify just a literal 'value', or an XPath expression
+over the payload, or even specify a registry key or a registry key combined
+with an XPath expression that selects the variable. The name of the variable
+corresponds to the name of variable declaration in the XQuery script. The
+'type' of the variable must be a valid type defined by the JSR-000225 (XQJ
+API). </p>
+
+<p>The supported types are:</p>
<ul>
<li>XQItemType.XQBASETYPE_INT -> INT</li>
<li>XQItemType.XQBASETYPE_INTEGER -> INTEGER</li>
@@ -1093,91 +1324,99 @@
<li>XQItemType.XQITEMKIND_ELEMENT -> ELEMENT</li>
</ul>
-<p>The expressions will be evaluated against the current SOAP envelope.</p>
-
<h4><a name="cache">Cache</a></h4>
-<pre> <cache (id="string")? hashGenerator="class" scope="string" timeout="seconds" collector=(true | false) maxMessageSize="in-bytes">
- <onCacheHit (sequence="key")?>
+<pre> <cache id="string" [hashGenerator="class"] [timeout="seconds"] [scope=(per-host | per-mediator)]
+ collector=(true | false) [maxMessageSize="in-bytes"]>
+ <onCacheHit [sequence="key"]>
(mediator)+
- </onCacheHit>
+ </onCacheHit>?
<implementation type=(memory | disk) maxSize="int"/>
</cache></pre>
-<p>The <cache> mediator will evaluate the hash value of the incoming
-message as described in the hash generator implementation (which should be a
-class implementing the org.wso2.caching.digest.DigestGenerator interface) and
-looks in a cache for a matching response. If the generated hash value has
+<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
+interface). The default hash generator is
+'org.wso2.caching.digest.DOMHashGenerator'. If the generated hash value has
been found in the cache then the cache mediator will execute the onCacheHit
-sequence which can be specified inline or refered to the registry. </p>
+sequence which can be specified inline or referenced. The cache mediator must
+be specified with an 'id' and two instances with this same 'id' that
+correlates the response message into the cache for the request message hash.
+The optional 'timeout' specifies the valid duration for cached elements, and
+the scope defines if mediator instances share a common cache per every host
+instance, or per every cache mediator pair (i.e. 'id') instance. The
+'collector' attribute 'true' specifies that the mediator instance is a
+response collection instance, and 'false' specifies that its a cache serving
+instance. The maximum size of a message to be cached could be specified with
+the optional 'maxMessageSize' attributes in bytes and defaults to unlimited.
+Finally the 'implementation' 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>
<h4><a name="clone">Clone</a></h4>
-<pre> <clone continueParent=(true | false)>
- <target to="uri" [soapAction="qname"] sequence="sequence_ref" endpoint="endpoint_ref">
+<pre> <clone [continueParent=(true | false)]>
+ <target [to="uri"] [soapAction="qname"] [sequence="sequence_ref"] [endpoint="endpoint_ref"]>
<sequence>
(mediator)+
- </sequence>
+ </sequence>?
<endpoint>
endpoint
- </endpoint>
- </target>
+ </endpoint>?
+ </target>+
</clone></pre>
-<p>The <clone> mediator closely resembles the Message Splitter EIP and
-will split the message into number of identical messages all of which are
-identical with the cloning message and processed parallelly using either the
-specified sequence or endpoint (or both). Cloning message (parent) can be
-continued or dropped depending on the boolean value of the continueParent
-attribute which defaults to false and drops the parent when false. This drop
-is not a general drop, rather stop the message processing but does not closes
-the transport channel, leaving the ability of one or a set of cloned message
-responses to be sent back to the caller</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>
<h4><a name="iterate">Iterate</a></h4>
-<pre> <iterate continueParent=(true | false) preservePayload=(true | false) (attachPath="xpath")? expression="xpath">
- <target to="uri" [soapAction="qname"] sequence="sequence_ref" endpoint="endpoint_ref">
+<pre> <iterate [continueParent=(true | false)] [preservePayload=(true | false)] (attachPath="xpath")? expression="xpath">
+ <target [to="uri"] [soapAction="qname"] [sequence="sequence_ref"] [endpoint="endpoint_ref"]>
<sequence>
(mediator)+
- </sequence>
+ </sequence>?
<endpoint>
endpoint
- </endpoint>
- </target>
+ </endpoint>?
+ </target>+
</iterate></pre>
-<p>The <iterate> mediator implements another EIP and will split the
-message in to number of different messages derived from the parent message by
-finding the matching elements of the XPATH expression specified in the
-configuration. New messages will be created for each and every matching
-element and processed parallelly using either the specified sequence or
-endpoint or both. Parent message can be continued or dropped in the same way
-as in the clone mediator. Iterate parent drop also is a channel blocking drop
-as per in the clone mediator.</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
+created for each and every matching element and processed in parallel using
+either the specified sequence or endpoint. Parent message can be continued or
+dropped in the same way as in the clone mediator. The 'preservePayload'
+attribute specifies if the original message should be used as a template when
+creating the splitted messages, and defaults to 'false', in which case the
+splitted messages would contain the split elements as the SOAP body.</p>
<h4><a name="aggregate">Aggregate</a></h4>
<pre> <aggregate>
- <corelateOn expression="xpath"/>
- <completeCondition timeout="time-in-seconds">
- <messageCount min="int-min" max="int-max"/>
- </completeCondition>
- <onComplete expression="xpath" sequence="sequence-ref">
+ <correlateOn expression="xpath"/>?
+ <completeCondition [timeout="time-in-seconds"]>
+ <messageCount min="int-min" max="int-max"/>?
+ </completeCondition>?
+ <onComplete expression="xpath" [sequence="sequence-ref"]>
(mediator +)?
</onComplete>
- <invalidate sequence="sequence-ref" timeout="time-in-seconds">
- (mediator +)?
- </invalidate>
</aggregate></pre>
-<p>The <aggregate> mediator implements the Message Aggregator EIP and
-will aggregate the messages splitted using either the clone or iterate
-mediators. At the same time it can aggregate messages on the presence of
-matching elements specified by the corelateOn XPATH expression. Aggregate
-will collect the messages coming in to that until the messages on the
-aggregation satisfies the complete condition. On completion of the
-aggregation it will execute the aggregated message using the onComplete
-sequence. Aggregated message will be created by combining the messages
-participating in the aggregation using the onComplete XPATH expression. If a
-particular aggregation fails to complete in a pre configured time, then that
-particular aggregation will be invalidated using the invalidate sequence.</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
+presence of matching elements specified by the correlateOn XPATH expression.
+Aggregate will collect the messages coming into it until the messages
+collected on the aggregation satisfies the complete condition. The completion
+condition can specify a minimum or maximum number of messages to be
+collected, or a timeout value in seconds, after which the aggregation
+terminates. On completion of the aggregation it will merge all of the
+collected messages and invoke the onComplete sequence on it. The merged
+message would be created using the XPath expression specified by the
+attribute 'expression' on the 'onComplete' element.</p>
<h3>Extension mediators</h3>
@@ -1188,7 +1427,7 @@
</property>
</class> </pre>
-<p>The <class> mediator creates an instance of the specified class and
+<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
@@ -1198,17 +1437,26 @@
<h4><a name="pojoCommand">POJOCommand</a></h4>
<pre> <pojoCommand name="class-name">
- <property name="string" value="literal">
+ (
+ <property name="string" value="string"/> |
+ <property name="string" context-name="literal" [action=(ReadContext | UpdateContext | ReadAndUpdateContext)]>
(either literal or XML child)
- </property>
- <property name="string" expression="xpath"/>
+ </property> |
+ <property name="string" expression="xpath" [action=(ReadMessage | UpdateMessage | ReadAndUpdateMessage)]/>
+ )*
</pojoCommand> </pre>
-<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 named "execute"). If any properties are
-specified, the corresponding setter methods are invoked on the class and
-called the execute method of the command executed.</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, the corresponding setter methods are invoked on the class
+before each message is executed. It should be noted that a new instance of
+the POJO Command class is created to process each message processed. After
+execution of the POJO Command mediator, depending on the 'action' attribute
+of the property, the new value returned by a call to the corresponding getter
+method is stored back to the message or to the context. The 'action'
+attribute may specify whether this behaviour is expected or not via the Read,
+Update and ReadAndUpdate properties.</p>
<p></p>
Modified: webservices/synapse/trunk/java/src/site/resources/Synapse_QuickStart.html
URL: http://svn.apache.org/viewvc/webservices/synapse/trunk/java/src/site/resources/Synapse_QuickStart.html?rev=615763&r1=615762&r2=615763&view=diff
==============================================================================
--- webservices/synapse/trunk/java/src/site/resources/Synapse_QuickStart.html (original)
+++ webservices/synapse/trunk/java/src/site/resources/Synapse_QuickStart.html Mon Jan 28 00:43:56 2008
@@ -101,7 +101,7 @@
</head>
<body>
-<h1>Quick start guide</h1>
+<h1>Quick Start Guide</h1>
<p>This guide will demonstrate two sample applications covering the basic and
the most common usage scenarios of Synapse; which is Message mediation and
@@ -131,17 +131,18 @@
<p>Our first task is to download Synapse. Open a web browser and access the
following URL: http://ws.apache.org/synapse/download.cgi. You will then see
-the list of available releases. Click on the 1.1 version, and you will be
-directed to the Synapse 1.1 release download page. Now download the 'Standard
+the list of available releases. Click on the latest version, and you will be
+directed to the Synapse release download page. Now download the 'Standard
binary distribution' ZIP or tar.gz archive compatible with your operating
system.</p>
<h3>Installation</h3>
<p>Synapse can be installed just by extracting the downloaded binary
-archive.. A directory named synapse-1.1 will be created in the selected
-parent directory, containing all the files required for Synapse. We will
-refer to this directory as <synapse-home> from now on.</p>
+archive.. A directory named synapse with the release number will be created
+in the selected parent directory, containing all the files required for
+Synapse. We will refer to this directory as <synapse-home> from now
+on.</p>
<h3>Running the sample</h3>
@@ -165,31 +166,31 @@
server. </p>
<p></p>
-<pre>user@host:/opt/synapse-1.1/samples/axis2Server$ cd src/SimpleStockQuoteService/
-user@host:/opt/synapse-1.1/samples/axis2Server/src/SimpleStockQuoteService$ ant
+<pre>user@host:/opt/synapse-1.2-SNAPSHOT/samples/axis2Server$ cd src/SimpleStockQuoteService/
+user@host:/opt/synapse-1.2-SNAPSHOT/samples/axis2Server/src/SimpleStockQuoteService$ ant
Buildfile: build.xml
clean:
init:
- [mkdir] Created dir: /opt/synapse-1.1/samples/axis2Server/src/SimpleStockQuoteService/temp
- [mkdir] Created dir: /opt/synapse-1.1/samples/axis2Server/src/SimpleStockQuoteService/temp/classes
- [mkdir] Created dir: /opt/synapse-1.1/samples/axis2Server/repository/services
+ [mkdir] Created dir: /opt/synapse-1.2-SNAPSHOT/samples/axis2Server/src/SimpleStockQuoteService/temp
+ [mkdir] Created dir: /opt/synapse-1.2-SNAPSHOT/samples/axis2Server/src/SimpleStockQuoteService/temp/classes
+ [mkdir] Created dir: /opt/synapse-1.2-SNAPSHOT/samples/axis2Server/repository/services
compile-all:
- [javac] Compiling 9 source files to /opt/synapse-1.1/samples/axis2Server/src/SimpleStockQuoteService/temp/classes
+ [javac] Compiling 9 source files to /opt/synapse-1.2-SNAPSHOT/samples/axis2Server/src/SimpleStockQuoteService/temp/classes
build-service:
- [mkdir] Created dir: /opt/synapse-1.1/samples/axis2Server/src/SimpleStockQuoteService/temp/SimpleStockQuote
- [mkdir] Created dir: /opt/synapse-1.1/samples/axis2Server/src/SimpleStockQuoteService/temp/SimpleStockQuote/META-INF
- [copy] Copying 1 file to /opt/synapse-1.1/samples/axis2Server/src/SimpleStockQuoteService/temp/SimpleStockQuote/META-INF
- [copy] Copying 1 file to /opt/synapse-1.1/samples/axis2Server/src/SimpleStockQuoteService/temp/SimpleStockQuote/META-INF
- [copy] Copying 9 files to /opt/synapse-1.1/samples/axis2Server/src/SimpleStockQuoteService/temp/SimpleStockQuote
- [jar] Building jar: /opt/synapse-1.1/samples/axis2Server/repository/services/SimpleStockQuoteService.aar
+ [mkdir] Created dir: /opt/synapse-1.2-SNAPSHOT/samples/axis2Server/src/SimpleStockQuoteService/temp/SimpleStockQuote
+ [mkdir] Created dir: /opt/synapse-1.2-SNAPSHOT/samples/axis2Server/src/SimpleStockQuoteService/temp/SimpleStockQuote/META-INF
+ [copy] Copying 1 file to /opt/synapse-1.2-SNAPSHOT/samples/axis2Server/src/SimpleStockQuoteService/temp/SimpleStockQuote/META-INF
+ [copy] Copying 1 file to /opt/synapse-1.2-SNAPSHOT/samples/axis2Server/src/SimpleStockQuoteService/temp/SimpleStockQuote/META-INF
+ [copy] Copying 9 files to /opt/synapse-1.2-SNAPSHOT/samples/axis2Server/src/SimpleStockQuoteService/temp/SimpleStockQuote
+ [jar] Building jar: /opt/synapse-1.2-SNAPSHOT/samples/axis2Server/repository/services/SimpleStockQuoteService.aar
BUILD SUCCESSFUL
Total time: 2 seconds
-user@host:/opt/synapse-1.1/samples/axis2Server/src/SimpleStockQuoteService$</pre>
+user@host:/opt/synapse-1.2-SNAPSHOT/samples/axis2Server/src/SimpleStockQuoteService$</pre>
<p>Now go to <synapse-home>/samples/axis2Server directory and start the
server using the following command. This will start Axis2 server on port 9000
@@ -202,14 +203,14 @@
</div>
<p>You will see the following messages on the console.</p>
-<pre>user@host:/opt/synapse-1.1/samples/axis2Server$ ./axis2server.sh
+<pre>user@host:/opt/synapse-1.2-SNAPSHOT/samples/axis2Server$ ./axis2server.sh
Using Bouncy castle JAR for Java 1.5
Using JAVA_HOME: /opt/jdk1.5_06
- Using AXIS2 Repository : /opt/synapse-1.1/samples/axis2Server/repository
- Using AXIS2 Configuration : /opt/synapse-1.1/samples/axis2Server/repository/conf/axis2.xml
+ Using AXIS2 Repository : /opt/synapse-1.2-SNAPSHOT/samples/axis2Server/repository
+ Using AXIS2 Configuration : /opt/synapse-1.2-SNAPSHOT/samples/axis2Server/repository/conf/axis2.xml
2007-11-05 14:36:41,462 [-] [main] INFO SimpleHTTPServer [SimpleAxisServer] Starting
-[SimpleAxisServer] Using the Axis2 Repository : /opt/synapse-1.1/samples/axis2Server/repository
-[SimpleAxisServer] Using the Axis2 Configuration File : /opt/synapse-1.1/samples/axis2Server/repository/conf/axis2.xml
+[SimpleAxisServer] Using the Axis2 Repository : /opt/synapse-1.2-SNAPSHOT/samples/axis2Server/repository
+[SimpleAxisServer] Using the Axis2 Configuration File : /opt/synapse-1.2-SNAPSHOT/samples/axis2Server/repository/conf/axis2.xml
2007-11-05 14:36:43,864 [-] [main] INFO HttpCoreNIOSender HTTPS Sender starting
2007-11-05 14:36:43,891 [-] [main] INFO HttpCoreNIOSender HTTP Sender starting
2007-11-05 14:36:44,288 [-] [main] INFO HttpCoreNIOListener HTTPS Listener starting on port : 9002
@@ -243,13 +244,13 @@
<p>Following messages will be displayed on the console to indicate the
successfull startup of Synapse.</p>
-<pre>user@host:/opt/synapse-1.1/bin$ ./synapse.sh -sample 0
+<pre>user@host:/opt/synapse-1.2-SNAPSHOT/bin$ ./synapse.sh -sample 0
Using Bouncy castle JAR for Java 1.5
Starting Synapse/Java ...
-Using SYNAPSE_HOME: /opt/synapse-1.1
+Using SYNAPSE_HOME: /opt/synapse-1.2-SNAPSHOT
Using JAVA_HOME: /opt/jdk1.5_06
-Using SYNAPSE_XML: -Dsynapse.xml=/opt/synapse-1.1/repository/conf/sample/synapse_sample_0.xml
-2007-11-05 14:58:55,029 [-] [main] INFO ServerManager Using the Axis2 Repository /opt/synapse-1.1/repository
+Using SYNAPSE_XML: -Dsynapse.xml=/opt/synapse-1.2-SNAPSHOT/repository/conf/sample/synapse_sample_0.xml
+2007-11-05 14:58:55,029 [-] [main] INFO ServerManager Using the Axis2 Repository /opt/synapse-1.2-SNAPSHOT/repository
2007-11-05 14:58:56,617 [-] [main] INFO SynapseInitializationModule Initializing Synapse at : Mon Nov 05 14:58:56 LKT 2007
2007-11-05 14:58:56,618 [127.0.1.1-asankha] [main] INFO SynapseInitializationModule Loading mediator extensions...
2007-11-05 14:58:56,619 [127.0.1.1-asankha] [main] INFO SynapseInitializationModule Initializing the Synapse configuration ...
@@ -275,14 +276,14 @@
<p>Now the final step, running the client. Go to
<synapse-home>/samples/axis2Client directory and type the following
command</p>
-<pre>user@host:/opt/synapse-1.1/samples/axis2Client$ ant stockquote -Daddurl=http://localhost:9000/soap/SimpleStockQuoteService -Dtrpurl=http://localhost:8080 -Dmode=quote -Dsymbol=IBM
+<pre>user@host:/opt/synapse-1.2-SNAPSHOT/samples/axis2Client$ ant stockquote -Daddurl=http://localhost:9000/soap/SimpleStockQuoteService -Dtrpurl=http://localhost:8080 -Dmode=quote -Dsymbol=IBM
Buildfile: build.xml
init:
- [mkdir] Created dir: /opt/synapse-1.1/samples/axis2Client/target/classes
+ [mkdir] Created dir: /opt/synapse-1.2-SNAPSHOT/samples/axis2Client/target/classes
compile:
- [javac] Compiling 10 source files to /opt/synapse-1.1/samples/axis2Client/target/classes
+ [javac] Compiling 10 source files to /opt/synapse-1.2-SNAPSHOT/samples/axis2Client/target/classes
stockquote:
[java] Standard :: Stock price = $91.09641757880443
@@ -497,7 +498,7 @@
<p></p>
<p>This quick guide illustrates the simple use case of proxy services. Please
-refer to samples #100 and above in the Samples guide, for in depth coverage
+refer to samples #150 and above in the Samples guide, for in depth coverage
of more advanced use cases.</p>
<p></p>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org