xan/awips2
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
awips2/edexOsgi/build.edex/opt/esb/bin/mule-1.4.0-spring-configuration.dtd
root 8e80217e59 Initial revision of AWIPS2 11.9.0-7p5 
Former-commit-id: a02aeb236c [formerly 9f19e3f712] [formerly 06a8b51d6d [formerly 64fa9254b946eae7e61bbc3f513b7c3696c4f54f]]
Former-commit-id: 06a8b51d6d
Former-commit-id: 3360eb6c5f
2012-01-06 08:55:05 -06:00

1947 lines
70 KiB
DTD
Raw Blame History

<!--
Copyright (c) MuleSource, Inc. All rights reserved. http://www.mulesource.com
The software in this package is published under the terms of the MuleSource MPL
license, a copy of which has been included with this distribution in the
LICENSE.txt file.
This DTD describes the grammar of the Mule configuration properties.
$Date: 2007-04-06 20:29:19 +0200 (Fri, 06 Apr 2007) $
$Revision: 5910 $
@root mule-configuration
-->
<!ELEMENT mule-configuration (description?,environment-properties?,mule-environment-properties?,container-context*,security-manager?,
transaction-manager?,agents?,connector*,endpoint-identifiers?,transformers?,global-endpoints?,
interceptor-stack*,model*,(import | alias | bean)*)>
<!--
The id attribute allows for a unique id for this file as it is often the case that
distributed Mule environments have their own properties
-->
<!ATTLIST mule-configuration id NMTOKEN #IMPLIED>
<!--
The version attribute is used to bind a mule_props.xml
file to a given version of this dtd. This will help to
avoid versions conflicts.
-->
<!ATTLIST mule-configuration version (1.0) #REQUIRED>
<!--
<i>mule-environment-params</i> are prarameters used by the Mule run-time. If none or not all
parameters are specified defaults will be used
-->
<!ELEMENT mule-environment-properties (threading-profile*, pooling-profile?, queue-profile?, persistence-strategy?, connection-strategy?)>
<!--
Specifies whether mule should process messages sysnchonously, i.e. that a mule-model
can only processone message at a time, or asynchonously. The default value is
'false'.
-->
<!ATTLIST mule-environment-properties synchronous (true | false) "false">
<!--
A property file can specify more than one mule-model. In the situation when more than
one is difined this property tells Mule which model to load. If this is not specifed
the first model is used.
<strong>This property currently is not used</strong>
-->
<!ATTLIST mule-environment-properties model CDATA #IMPLIED>
<!--
The directory where mule can write any temporary files or persist messages
-->
<!ATTLIST mule-environment-properties workingDirectory CDATA "./.mule">
<!--
When running sychonously, return events can be received over transports that support ack or replyTo
This property determines how long to wait for a receive
-->
<!ATTLIST mule-environment-properties synchronousEventTimeout NMTOKEN #IMPLIED>
<!--
Added default encoding to use for general parsing of strings
-->
<!ATTLIST mule-environment-properties encoding CDATA #IMPLIED>
<!--
Default transaction timeout
-->
<!ATTLIST mule-environment-properties transactionTimeout NMTOKEN #IMPLIED>
<!--
Determines whether when running synchronously, return events are received before
returning the call. i.e. in jms wait for a replyTo. Vm queues do this automatically
-->
<!ATTLIST mule-environment-properties remoteSync (true | false) "false">
<!--
Determines if Mule is running embedded and can be used to disable certain services and also hide the
start splash
-->
<!ATTLIST mule-environment-properties embedded (true | false) "false">
<!--
Is the default endpointUri where Mule can receive Action requests such as running a
send, dispatch or receive request from a remote client. If not specified the default will
be used of tcp://localhost:60504.
Note users can explicitly configure the MuleManagerComponent that serves these type of
requests and this variable need not be set. Setting this to an empty string
"" will disable the server admin component. Often client only and test configurations
will want to do this.
-->
<!ATTLIST mule-environment-properties serverUrl CDATA #IMPLIED>
<!--
Determines whether Mule's internal queues are persisted. If the server dies unexpectedly Mule
can resume processing when the server starts
-->
<!ATTLIST mule-environment-properties recoverableMode (true | false) "false">
<!--
Determines whether Mule amule instance is runnig in client mode. client mode means that
certain Mule Manager services are not started suhc as the the Admin component and the Server
event manager. The only time a user would need to set variable explicitly is if they
where configuring a Mule instance via Xml config for client-only usage.
-->
<!ATTLIST mule-environment-properties clientMode (true | false) "false">
<!--
Whether mule should fire message events for every message sent and received
-->
<!ATTLIST mule-environment-properties enableMessageEvents (true | false) "false">
<!--
The type of model used for the internal system model where system created services are registered
-->
<!ATTLIST mule-environment-properties systemModelType CDATA "seda">
<!--
A pooling profile is used to configure the pooling behaviour of UMO components.
each descriptor can set it's own pooling profile or a default one can be set
on the mule-configuration.
-->
<!ELEMENT pooling-profile EMPTY>
<!--
Controls the maximum number of Mule UMOs that can be borrowed from a Session at one time.
When non-positive, there is no limit to the number of components that may be active at one time.
When maxActive is exceeded, the pool is said to be exhausted.
You can specify this value on the descriptor declaration. If none is set this value
will be used.
-->
<!ATTLIST pooling-profile maxActive NMTOKEN #IMPLIED>
<!--
Controls the maximum number of Mule UMOs that can sit idle in the pool at any time. When non-positive,
there is no limit to the number of Mule UMOs that may be idle at one time.
You can specify this value on the descriptor declaration. If none is set this value
will be used.
-->
<!ATTLIST pooling-profile maxIdle NMTOKEN #IMPLIED>
<!--
Determines how components in a pool should be initialised. the possible values are -
<ul>
<li>INITIALISE_NONE : Will not load any components in the pool on startup</li>
<li>INITIALISE_FIRST : Will load only the first component in the pool on startup</li>
<li>INITIALISE_ALL : Will load all components in the pool on startup</li>
</ul>
The default for this value is INITIALISE_FIRST.
-->
<!ATTLIST pooling-profile initialisationPolicy (INITIALISE_NONE | INITIALISE_FIRST | INITIALISE_ALL) "INITIALISE_FIRST">
<!--
Specifies the behaviour of the Mule UMO pool when the pool is exhausted:
<p/>
0 (WHEN_EXHAUSTED_FAIL) : will throw a NoSuchElementException
1 (WHEN_EXHAUSTED_BLOCK): will block (invoke Object.wait(long) until a new or idle object is available.
2 (WHEN_EXHAUSTED_GROW) : will create a new Mule and return it(essentially making maxActive meaningless.)
<p/>
If a positive maxWait value is supplied, it will block for at most that many milliseconds,
after which a NoSuchElementException will be thrown. If maxThraedWait is non-positive, it will block
indefinitely.
-->
<!ATTLIST pooling-profile exhaustedAction (GROW | WAIT | FAIL) "GROW">
<!--
Specifies the number of milliseconds to wait for a pooled component to become available
when the pool is exhausted and the exhaustedAction is set to 'wait'.
-->
<!ATTLIST pooling-profile maxWait NMTOKEN #IMPLIED>
<!--
A fully qualified classname of the pool factory to use with this pool profile.
Implementations must implement org.mule.umo.UMOPoolFactory.
-->
<!ATTLIST pooling-profile factory NMTOKEN "org.mule.config.pool.CommonsPoolFactory">
<!ELEMENT threading-profile EMPTY>
<!--
The threading profile system id. This is used to identify which system
component should use the profile. This attribute is only used when declaring profiles on
the mule-evironment-properties element and on connector components where 'messageReceiver'
or 'messageSender' can be used. For all other cases it can be set to 'default'.
-->
<!ATTLIST threading-profile id (receiver|dispatcher|component|default) "default">
<!--
Controls the maximum number of threads that can be executed at any one time in a
thread pool
-->
<!ATTLIST threading-profile maxThreadsActive NMTOKEN #IMPLIED>
<!--
Controls the maximum number threads that can be inactive or idle in a thread pool before
they are destroyed.
-->
<!ATTLIST threading-profile maxThreadsIdle NMTOKEN #IMPLIED>
<!--
Detemines how long an inactive thread is kept in the pool before being discarded
-->
<!ATTLIST threading-profile threadTTL NMTOKEN #IMPLIED>
<!--
If the maximum pool size or queue size is bounded, then it is possible for incoming execute requests to block.
There are five supported policies for handling this situation.
<ol>
<li>RUN (the default) - The thread making the execute request runs the task itself.
This policy helps guard against lockup.
</li>
<li>WAIT - Wait until a thread becomes available (or until the configurable timeout expires).
This policy should, in general, not be used if the minimum number of of threads is zero, in
which case a thread may never become available.
</li>
<li>ABORT - Throw a RuntimeException
</li>
<li>DISCARD - Throw away the current request and return.
</li>
<li>DISCARD_OLDEST - Throw away the oldest request and return.
</li></ol>
-->
<!ATTLIST threading-profile poolExhaustedAction (WAIT | DISCARD | DISCARD_OLDEST | ABORT | RUN) "RUN">
<!--
Allows configuration of a waiting timeout for threads that are blocked when WAIT
has been configured as poolExhaustedAction
-->
<!ATTLIST threading-profile threadWaitTimeout NMTOKEN #IMPLIED>
<!--
Determines whether threading is enabled for a connector. It's useful to set this to false
when testing. Setting it on the defaultThreadingProfile on the Mule configuration will disable
threading in every connector
-->
<!ATTLIST threading-profile doThreading (true | false) "true">
<!--
Determines how many requests if any are queue when the pool is at maximum
usage capacity. The buffer is used as an overflow.
-->
<!ATTLIST threading-profile maxBufferSize NMTOKEN #IMPLIED>
<!--
A Queue Profile is used to describe the the properties of an internal Mule queue. Internal queues are used to
queue events for each component managed by Mule.
-->
<!ELEMENT queue-profile (properties?)>
<!--
Defines the maximum number of message that can be queued.
-->
<!ATTLIST queue-profile maxOutstandingMessages NMTOKEN #IMPLIED>
<!--
Defines if this queue is persistent or not
-->
<!ATTLIST queue-profile persistent (true | false) "false">
<!--
A persistence strategy defines the mechanism used to store Mule events to a persistent store. Primarily, this
is used for for persisting queued events to disk so that the servers internal state is mirrored on disk in case
the server fails and needs to be restarted.
-->
<!ELEMENT persistence-strategy (properties?)>
<!--
A fully qualified class name of the org.mule.util.queue.PersistenceStrategy implementation to use to store
mule events.
-->
<!ATTLIST persistence-strategy className NMTOKEN #REQUIRED>
<!--
The environment-param element allows to add custom properties. These are accessible
from the MuleManager getProperty method
-->
<!ELEMENT environment-properties ((property | factory-property | system-property | map | list | file-properties)+)>
<!--
This element specifies the transaction manager to use (if any) in the Mule Server
The configuration must specify a factory attribute which is a fully qualified class
name of a Transaction factory that implements org.mule.umo.manager.UMOTransactionManagerFactory
-->
<!ELEMENT transaction-manager (properties?)>
<!--
The <i>factory</i> specifies the transaction manager factory to use to
create a transaction manager for the Mule server
The <i>property</i> element allows to add custom attributes. Each of the
key value pair attributes will be passed to the connection as a HashMap
The connection implementation will then handle how these properties are set.
-->
<!ATTLIST transaction-manager factory NMTOKEN #IMPLIED>
<!--
The ref name of this object if it is to be loaeded from a container such as spring or
Jndi
-->
<!ATTLIST transaction-manager ref CDATA #IMPLIED>
<!--
This element specifies the security manager to use (if any) for this Mule Server instance
The security manager is responsible for managing one or more security providers that can
validate user credentials
-->
<!ELEMENT security-manager (security-provider*, encryption-strategy*)>
<!--
The <i>className</i> is optional and specifies the security manager to use.
-->
<!ATTLIST security-manager className NMTOKEN #IMPLIED>
<!--
The ref name of this object if it is to be loaeded from a container such as spring or
Jndi
-->
<!ATTLIST security-manager ref CDATA #IMPLIED>
<!--
A security provider allows credentials to be authenticated against various credential
providers.
-->
<!ELEMENT security-provider (properties?)>
<!--
A fully qualified class name of the security provider to use
-->
<!ATTLIST security-provider className NMTOKEN #IMPLIED>
<!--
The ref name of this object if it is to be loaeded from a container such as spring or
Jndi
-->
<!ATTLIST security-provider ref CDATA #IMPLIED>
<!--
A unique name that identifies the security provider
-->
<!ATTLIST security-provider name ID #REQUIRED>
<!--
A encryption strategy is a encryption configuration object that
can be used by mule components to perform en/decryption. The main
components that will use these strategies are security filters and
transformers
-->
<!ELEMENT encryption-strategy (properties?)>
<!--
A fully qualified class name of the encryption strategy to use
-->
<!ATTLIST encryption-strategy className NMTOKEN #REQUIRED>
<!--
A unique name that identifies the encryption strategy
-->
<!ATTLIST encryption-strategy name ID #REQUIRED>
<!--
The <i>connector</i> element specifies one or more message
connections for Mule components.
-->
<!ELEMENT connector (properties?, threading-profile?, exception-strategy?, connection-strategy?)>
<!--
The name attribute is used to bind a connection to a logical name in the system
This must be unique for each Mule instance
-->
<!ATTLIST connector name ID #REQUIRED>
<!--
The fully qualified classname to instanciate the connector with
-->
<!ATTLIST connector className NMTOKEN #IMPLIED>
<!--
The ref name of this object if it is to be loaeded from a container such as spring or
Jndi
-->
<!ATTLIST connector ref CDATA #IMPLIED>
<!--
The <i>connection-strategy</i> element specifies a strategy implementation used when making
a connection to the underlying resource
-->
<!ELEMENT connection-strategy (properties?)>
<!--
The fully qualified classname to instanciate the connector strategy. This class must
implement <i>org.mule.providers.ConnectionStrategy</i>
-->
<!ATTLIST connection-strategy className NMTOKEN #REQUIRED>
<!--
This is a grouping element for individual <i>endpoint-identifier</i> instances
-->
<!ELEMENT endpoint-identifiers (endpoint-identifier+)>
<!--
A <i>endpoint-identifier</i> is a mapping between an endpoint and a logical name. The MuleManager
provides an interface to lookup these endpoints. Essentially this is just a key value
pair i.e. you may map -
<ul>
<li>Fault Email -&gt; smtp://admin&#64;mycompany.com</li>
<li>Shipping Manager -&gt; jms://shipping.orders.topic</li>
<li>Administrators Mobile -&gt; sms://+447910010010</li>
</ul>
-->
<!ELEMENT endpoint-identifier EMPTY>
<!--
name
The logical endpoint name
-->
<!ATTLIST endpoint-identifier name CDATA #REQUIRED>
<!--
value
The corresponding endpoint value
-->
<!ATTLIST endpoint-identifier value CDATA #REQUIRED>
<!--
A grouping element for all transformer declarations
-->
<!ELEMENT transformers (transformer+)>
<!--
Transformers are used to convert objects from one type to another. mule-descriptors
can be associated with two transformers: one for inbound messages and one of
outbound messages.
All transformers must implement <i>org.mule.transformers.Transformer</i>
The <i>org.mule.doCompression</i> property determines whether a transformer should
compress/uncompress its data. This attribute is ignored unless the
transformer named in the className attribute extends
<i>org.mule.transformers.compression.AbstractCompressionTransformer</i>
This is a fairlycommon property but must be specified on the transformer
declaration as a property i.e.
<code>
&lt;transformer name="ObjectToJMSMessage" className="org.mule.transformers.ObjectToJMSMessage" returnClass="javax.jms.BytesMessage"&gt;
&lt;properties&gt;
&lt;property name="org.mule.doCompression" value="true"/&gt;
&lt;/properties&gt;
&lt;/transformer&gt;
</code>
-->
<!ELEMENT transformer (properties?)>
<!--
name
The logical name for the transformer. When the transformer is
registered it's name will be used to reference the transformer.
If this attibute is not set then it will default to it's class
name without the pakage prefix.
-->
<!ATTLIST transformer name ID #REQUIRED>
<!--
The className attribute represents the full qualified class name
of the Transformer implementation
-->
<!ATTLIST transformer className NMTOKEN #IMPLIED>
<!--
The ref name of this object if it is to be loaeded from a container such as spring or
Jndi
-->
<!ATTLIST transformer ref CDATA #IMPLIED>
<!--
The returnClass attribute represents the full qualified class name
of the expected return Object of the Transformer implementation. if none is
specified java.lang.Object is used by default. However, by suppling a returnClass
the transformer can validate that the returnObject is of expected type before return
to the callee.
-->
<!ATTLIST transformer returnClass CDATA "java.lang.Object">
<!--
Determines whether the tranformer should through an exception if an incompatible source type
is received or whether to ignore it so that the next transformer can be invoked
-->
<!ATTLIST transformer ignoreBadInput (true|false) #IMPLIED>
<!--
<i>global-endpoints</i> are endpoint configurations made available to all components in
a model through the MuleManager. This is a grouping element for individual
<i>endpoint</i> instances
-->
<!ELEMENT global-endpoints (endpoint+)>
<!--
A <i>endpoint</i> are communication channel definitions to some message system. These
are used to publish and subscibe messages in and outside of Mule
If the endpoint is of type receiver The filter is used to filter incoming
events. Not all endpoint providers support filtering so if a filter is set on an endpoint
that uses a provider that doesn't support filtering an UnsupportedOperationException
is thrown.
The property element allows to add custom attributes to the endpoint.
-->
<!ELEMENT endpoint ((transaction)?, (filter)?, (security-filter)?, (properties)?)>
<!--
The name attribute is used to bind a <i>endpoint</i> to a logical name in the system
This must be unique for each Mule instance. If not set one will be generated
-->
<!ATTLIST endpoint name ID #IMPLIED>
<!--
The ref name of this object if it is to be loaeded from a container such as spring or
Jndi
-->
<!ATTLIST endpoint ref CDATA #IMPLIED>
<!--
This specifes the communication endpoint. This will have a different format depending
on the transport protocol being used i.e.
<ul>
<li>smtp -&gt; admin&#64;mycompany.com</li>
<li>jms -&gt; shipping.orders.topic</li>
<li>sms -&gt; +447910010010</li>
</ul>
if an endpoint address is not specifed it will be assumed that it will be determined at run-time
by the calling application. The endpoint address must be a URI address or it can be a logical name for an
endpoint as long as it is declared in a <i>endpoint</i> block.
Example uris are:
<ul>
<li>vm://test.queue?transformers=ObjectToXml</li>
<li>pop3://ross:password@mail.muleumo.org?createConnector=ALWAYS</li>
<li>file:///C:/temp/mule?transformers=FileMessageToObject</li>
</ul>
-->
<!ATTLIST endpoint address CDATA #REQUIRED>
<!--
The name of connector to use for this endpoint. The protocol of the connector
named must match the protocol of the endpoint address. If this value is not set
the first connector found with the correct protocol will be used
-->
<!ATTLIST endpoint connector CDATA #IMPLIED>
<!--
Determines whether the endpoint provider is a sender, receiver or a senderAndReceiver.
An endpoint can be senderAndReceiver meaning that there is no difference for the endpoint
configuration if it is used as a sender or receiver.
-->
<!ATTLIST endpoint type (sender | receiver | senderAndReceiver) "senderAndReceiver">
<!--
Is responsible for transforming data when it is received or sent by the UMO
(depending on whether this endpoint is a receiver or not). A tranformation for an
inbound event can be forced by the user by calling the inbound event.getTransformedMessage().
A tranformation for an outbound event is called or when the UMO dispatchEvent()
or sendEvent() methods are called.
-->
<!ATTLIST endpoint transformers CDATA #IMPLIED>
<!--
Is responsible for transforming data when it is returned from a request/response
invocation. If the endpoint is a receiver the responseTransformers is ignored.
-->
<!ATTLIST endpoint responseTransformers CDATA #IMPLIED>
<!--
synchronous
determines if requests received on this endpoint execute within a single thread
if not set the MuleManager synchronous property will be used
-->
<!ATTLIST endpoint synchronous (true|false) #IMPLIED>
<!--
remoteSync
Determines whether when running synchronously, return events are received before
returning the call. i.e. in jms wait for a replyTo or tcp/http reply on the outputStream.
Vm queues do this automatically
-->
<!ATTLIST endpoint remoteSync (true|false) #IMPLIED>
<!--
remote-sync-timeout
How long to block for a remote sync operation
-->
<!ATTLIST endpoint remoteSyncTimeout NMTOKEN #IMPLIED>
<!--
encoding
explicitly specify the encoding used by this endpoint
-->
<!ATTLIST endpoint encoding CDATA #IMPLIED>
<!--
Deterimes how mule will allocate a connector for this endpoint. By default
Mule will look for a connector with a protocol matching the protocol of the address
of this endpoint. If a match is found that connector will be used, otherwise a new
connector will be created. Users can specify ALWAYS to aleways create a new connector
or NEVER which will require a connector to be pre-configured.
-->
<!ATTLIST endpoint createConnector (GET_OR_CREATE | ALWAYS_CREATE | NEVER_CREATE) #IMPLIED>
<!--
A global endpoint reference
-->
<!ELEMENT global-endpoint (transaction?, filter?, security-filter?, properties*)>
<!--
name
The name of the global referene to use
-->
<!ATTLIST global-endpoint name CDATA #REQUIRED>
<!--
address
Used to override the address on the global endpoint
-->
<!ATTLIST global-endpoint address CDATA #IMPLIED>
<!--
address
Used to override the transformers on the global endpoint
-->
<!ATTLIST global-endpoint transformers CDATA #IMPLIED>
<!--
Is responsible for transforming data when it is returned from a request/response
invocation. If the endpoint is a receiver the responseTransformers is ignored.
-->
<!ATTLIST global-endpoint responseTransformers CDATA #IMPLIED>
<!--
synchronous
determines if requests received on this endpoint execute within a single thread
if not set the MuleManager synchronous property will be used
-->
<!ATTLIST global-endpoint synchronous (true|false) #IMPLIED>
<!--
remote-sync
Determines whether when running synchronously, return events are received before
returning the call. i.e. in jms wait for a replyTo or tcp/http reply on the outputStream.
Vm queues do this automatically
-->
<!ATTLIST global-endpoint remoteSync (true|false) #IMPLIED>
<!--
remote-sync-timeout
How long to block for a remote sync operation
-->
<!ATTLIST global-endpoint remoteSyncTimeout NMTOKEN #IMPLIED>
<!--
encoding
explicitly specify the encoding used by this endpoint
-->
<!ATTLIST endpoint encoding CDATA #IMPLIED>
<!--
A security filter ensures that all requestsmade via an endpoint will be authenticated
-->
<!ELEMENT security-filter (properties?)>
<!--
By default, all providers registered with the security manager will be
authenticated against. However a space separated list of provider names can
be specified to change the order or the restrict the list of security
providers used.
-->
<!ATTLIST security-filter useProviders CDATA #IMPLIED>
<!--
A fully qualified classname of the security filter to use on this endpoint
-->
<!ATTLIST security-filter className NMTOKEN #REQUIRED>
<!--
Defines transactional behaviour for this endpoint
-->
<!ELEMENT transaction (constraint?)>
<!--
The factory attribute defines the <i>UMOTransactionFactory</i> to use when creating new
transactions. This is only require when the transaction config is declared on an inbound
provider.
-->
<!ATTLIST transaction factory NMTOKEN #IMPLIED>
<!--
The Action attribute determise the way that the provider demarcates
transactions when it receives an event.
NONE - tells the provider not to do anything regarding transaction management.
ALWAYS_BEGIN - Will always start a new transaction when an event is received.
BEGIN_OR_JOIN - Will join the transaction if one is in progress otherwise one will be started.
ALWAYS_JOIN - Expects a transaction to be in progress and joins it.
JOIN_IF_POSSIBLE - Will join a transaction if one is in progress others just continues processing.
-->
<!ATTLIST transaction action (NONE | ALWAYS_BEGIN |
BEGIN_OR_JOIN | ALWAYS_JOIN |
JOIN_IF_POSSIBLE ) #IMPLIED>
<!--
The commitAction attribute determines how transactions are managed when an event is published.
NONE - tells the provider not to do anything regarding transaction management.
ALWAYS_COMMIT - Will expect a transaction to be in process and will commit it.
JOIN_IF_POSSIBLE - Will commit a transaction if one is in progress others just continues processing.
-->
<!--<!ATTLIST transaction commitAction (NONE | ALWAYS_COMMIT | COMMIT_IF_POSSIBLE ) #IMPLIED>-->
<!--
Transaction timeout for transactions initiated from the endpoint associated with
this transaction config.
-->
<!ATTLIST transaction timeout NMTOKEN #IMPLIED>
<!--
Constraints can be defined on a send provider to control how and when a transaction
gets committed. For example, to commit a transaction once 3 jms messages have been
processed you can define a BatchConstraint on the transaction and set the batch size to 3.
These constraints work the same way as filters and properties on the filters can be set
as attributes on the filter xml element.
-->
<!ELEMENT constraint (left-filter?,right-filter?, filter?)>
<!--
className
A fully qualified class name of the filter Constraint to use. Implementations should always
implement <i>org.mule.umo.UMOFilter</i>.
-->
<!ATTLIST constraint className NMTOKEN #REQUIRED>
<!--
because I can't find a way of allowing arbitary attributes on an element,
I am going to define a common set of attributes for filters but users can add their own
or relax dtd validation on their parser.
-->
<!ATTLIST constraint batchSize NMTOKEN #IMPLIED>
<!ATTLIST constraint frequency CDATA #IMPLIED> <!-- milliseconds -->
<!ATTLIST constraint expectedType CDATA #IMPLIED>
<!ATTLIST constraint path CDATA #IMPLIED>
<!ATTLIST constraint pattern CDATA #IMPLIED>
<!ATTLIST constraint expression CDATA #IMPLIED>
<!--
Interceptors can be executed in sequence before and/or after the Mule component.
A <i>interceptor-stack/i> is a stack of interceptors that can be assigned to multiple
Mule components to provide standard functionality.
-->
<!ELEMENT interceptor-stack (interceptor+)>
<!--
The idenfying name for the interceptor stack
-->
<!ATTLIST interceptor-stack name ID #REQUIRED>
<!--
Agents is a collection of one or more agent configurations
-->
<!ELEMENT agents (agent+)>
<!--
An agent is a server plugin that can be initialised stated and destroyed along with the UMOManager itself.
Agents can initialise or bind to external services such as Jmx server
-->
<!ELEMENT agent (properties?)>
<!--
Unique name for the agent
-->
<!ATTLIST agent name CDATA #REQUIRED>
<!--
The fully qualified classname of the Agent
-->
<!ATTLIST agent className NMTOKEN #IMPLIED>
<!--
The ref name of this object if it is to be loaeded from a container such as spring or
Jndi
-->
<!ATTLIST agent ref CDATA #IMPLIED>
<![IGNORE[
<!ELEMENT configuration>
]]>
<!--
A Container context is used to retrieve object properties from the container.
A container property is referenced using the container-property element.
There are different implementations for different containers
such as PicoContainer or Spring
-->
<!ELEMENT container-context (properties?)>
<!--
The fully qualified class name of the container context. Customer contexts must implement
<i>org.mule.umo.UMOContainerContext</i>.
Configuration of the container itself should be provided though properties on this
element.
-->
<!ATTLIST container-context className NMTOKEN #REQUIRED>
<!--
The name of this container context. Containers have a default name, which
is usually the the name of the container implementation
-->
<!ATTLIST container-context name CDATA #IMPLIED>
<!--
The <i>model</i> defines the components and interations between components in the Mule
run-time environment. Here is specified which components exist in the system and how they
should behave.
-->
<!ELEMENT model (description?, entry-point-resolver?, component-factory?, component-lifecycle-adapter-factory?, component-pool-factory?, exception-strategy?, mule-descriptor*, bean*)>
<!--
The name to associate this mule-model with
-->
<!ATTLIST model name CDATA #REQUIRED>
<!--
The type of Model to use for component processing for this Mule instance. The different types of model are described
at http://mule.mulesource.org/wiki/display/MULE/Models
The custom model can be used to specify a custom model type. In which case you must supply a className.
-->
<!ATTLIST model type (seda | direct | pipeline | jms | streaming | inherited | custom) "seda">
<!--
The class used for instanciate the model if a custom model type is being used. The class must implement
org.mule.umo.model.UMOModel.
-->
<!ATTLIST model className NMTOKEN #IMPLIED>
<!--
The ref name of this object if it is to be loaeded from a container such as spring or
Jndi
-->
<!ATTLIST model ref CDATA #IMPLIED>
<!--
An entry Point resolver is used to determine which method on a UMO object
should receive events
-->
<!ELEMENT entry-point-resolver (properties?)>
<!--
The fully qualified class name of the resolver to use on this model
-->
<!ATTLIST entry-point-resolver className NMTOKEN #REQUIRED>
<!--
A Lifecycle adapter factory for creating a LifecycleAdapter for UMO componenets.
This allows customer lifecycle event behaviour for UMO components.
-->
<!ELEMENT component-lifecycle-adapter-factory EMPTY>
<!--
The fully qualified class name of the lifecycle adapterfactory. Custom lifecycle adapters
must implement <i>org.mule.umo.lifecycle.UMOLifecycleAdapterFactory</i>
-->
<!ATTLIST component-lifecycle-adapter-factory className NMTOKEN #REQUIRED>
<!--
A component factory is used to create UMOComponent instances. These are used to
wrap business objects and controls how events are managed for the object
-->
<!ELEMENT component-factory EMPTY>
<!--
The fully qualified class name of the component factory implementation.
Custom component factories must implement
<i>org.mule.umo.UMOcomponentFactory</i>
-->
<!ATTLIST component-factory className NMTOKEN #REQUIRED>
<!--
An component pool factory is used to determine what pool implementation should be used by mule to
pool UMOComponent instances. Mule ships with Pico pool (picoContainer) and commons pool(jakarta)
implementations
-->
<!ELEMENT component-pool-factory (properties?)>
<!--
The fully qualified class name of the component pool factory to use on this model
-->
<!ATTLIST component-pool-factory className NMTOKEN #REQUIRED>
<!--
A <i>mule-descriptor</i> describes a single mule component, a MuleUMO. a component is an autonomous
unit that executes a particular function by receiving an input doing some processing
on the input and outputig a result, thus triggering futher events in the system.
-->
<!ELEMENT mule-descriptor ((inbound-router)?, (nested-router)?, (outbound-router)?, (response-router)?, (interceptor)*, (threading-profile)?, (pooling-profile)?, (queue-profile)?, (exception-strategy)?, (properties)?, (bean)*)>
<!--
name
The name to associate with the mule-descriptor
-->
<!ATTLIST mule-descriptor name CDATA #REQUIRED>
<!--
The ref name of this object if it is to be loaded from a container such as spring or
Jndi
-->
<!ATTLIST mule-descriptor ref CDATA #IMPLIED>
<!--
The transformer to use when receiving events on the specified inboundProvider.
-->
<!ATTLIST mule-descriptor inboundTransformer CDATA #IMPLIED>
<!--
The transformer to use when receiving events on the specified outboundProvider.
-->
<!ATTLIST mule-descriptor outboundTransformer CDATA #IMPLIED>
<!--
The transformer to use when sending events back.
-->
<!ATTLIST mule-descriptor responseTransformer CDATA #IMPLIED>
<!--
The class of the object or an object reference of the component being registered as an UMO.
If the implementation is an object reference then it will be resolved using the component resolver
configured on the model
-->
<!ATTLIST mule-descriptor implementation CDATA #REQUIRED>
<!--
The default subject that the Mule UMO sends events.
-->
<!ATTLIST mule-descriptor inboundEndpoint CDATA #IMPLIED>
<!--
The default subject that the Mule UMO receive events.
-->
<!ATTLIST mule-descriptor outboundEndpoint CDATA #IMPLIED>
<!--
The version on the Mule UMO. This is currently not used by the mule run-time but may
be used in future
-->
<!ATTLIST mule-descriptor version NMTOKEN #IMPLIED>
<!--
If an IoC container is being used this property can be set to determine if this component
is constructed (and contained in) the container or is instanciated by Mule.
This is being deprecated in favour of the 'ontainer' property below.
-->
<!ATTLIST mule-descriptor containerManaged (true | false) "true">
<!--
If an IoC container is being used this property can be set to determine which container explicitly
the component should be loaded from. Also you can specify to not load the component from a Container
context by setting this value to 'none'.
-->
<!ATTLIST mule-descriptor container NMTOKEN #IMPLIED>
<!--
Determines if only a single instance of this component is created. This is useful when a
component hands off event processing to another engine such as Rules processing or Bpel
and the processing engine allocates and manages its own threads.
-->
<!ATTLIST mule-descriptor singleton (true | false) "false">
<!--
Determines the running state of a component when the model starts up
-->
<!ATTLIST mule-descriptor initialState (started | stopped ) "started">
<!--
A message router configures different routing paths for events that are dispatched for a UMO
component. An outbound router is concerned with messages/events being sent out from a UMO component.
You can specify diferent routing rules for different providers configured on the
mule-descriptor. You can also chain routers together by embedding one router declaration inside
the other
-->
<!ELEMENT outbound-router (catch-all-strategy?, router+)>
<!--
Whether every configured router will be matched against
-->
<!ATTLIST outbound-router matchAll (true | false) "false">
<!--
A message router configures different routing paths for events that are dispatched for a UMO
component. An inbound router is concerned with messages/events being received by providers configured
on the mule-descriptor.
-->
<!ELEMENT inbound-router ((catch-all-strategy)?,(endpoint)*,(global-endpoint)*,(router)*)>
<!--
Whether every configured router will be matched
-->
<!ATTLIST inbound-router matchAll (true | false) "false">
<!--
A message router configures how a resonse message will be routed to a client when
using request/response message processing.
-->
<!ELEMENT response-router ((endpoint)*,(global-endpoint)*,(router)*)>
<!--
This attibute defines the response transformers (if any) that will be applied
to the response message before returning to the client. Developers can define
a response-router with only a transformer and no actual routers to configure a
response transformer. Note that the connector can have a default Response transformer
associated with it meaning that marshaling from transport specific MEssage types such as
Jms will be done automatically.
-->
<!--
Defines the timeout for routers configure on this response-router
-->
<!ATTLIST response-router timeout CDATA #IMPLIED>
<!--
//TODO
If a timeout occurs, should an error be thorwn or allow the events to be passed on regardless
-->
<!--<!ATTLIST response-router failOnTimeout (true | false) "true">-->
<!--
A nested router allows for mule orchestration of component dependencies
-->
<!ELEMENT nested-router ((binding)*)>
<!--
Configuration that binds and endpoint to an interface
-->
<!ELEMENT binding ((endpoint | global-endpoint))>
<!--
The fully qualified name of the interface class that will be proxied to call out to an endpoint
if the interface has more than one method then the method param must also be set.
-->
<!ATTLIST binding interface NMTOKEN #REQUIRED>
<!--
The name of the method that will be bound to the endpoint
-->
<!ATTLIST binding method NMTOKEN #IMPLIED>
<!--
A catch-all-strategy is invoked to route an event when an event is not accepted by any of the configured
routers.
-->
<!ELEMENT catch-all-strategy ((endpoint?|global-endpoint?), (properties)?)>
<!--
endpoint
Refers to an optional uri that can be resolvered as a provider. This attribute functions the same
way as the provider attribute
-->
<!--
className
Is a fully qualified class name of the catch all strategy class
-->
<!ATTLIST catch-all-strategy className NMTOKEN #REQUIRED>
<!--
A router with route an event based on some criteria configured by the route, this criteria may be based
on the content of the event, the type of event, metadata, etc.
It is possible to chain routers together to combine different routing logic to a single
event. to chain routers you must define once router inside another.
-->
<!ELEMENT router (endpoint*, global-endpoint*, reply-to?, transaction?, filter?, properties?)>
<!--
className
A fully qualified class name of the Router to use. Implementations must
use org.mule.umo.routing.UMOOutboundRouter
-->
<!ATTLIST router className NMTOKEN #REQUIRED>
<!--
transformer
This is the transformer chain to apply to the message before it is checked for a match. This is useful
where you want to filter on a subset of the message and cannot query it using a filter.
-->
<!ATTLIST router transformer CDATA #IMPLIED>
<!--
enableCorrelation
This is used by outbound routers to determine if a correlationId should be set
on the message being routed. By default the correlationId is set as the current
message id
-->
<!ATTLIST router enableCorrelation (ALWAYS | NEVER | IF_NOT_SET) "IF_NOT_SET">
<!--
propertyExtractor
Is a fully qualified classname of a class that implements org.mule.util.properties.PropertyExtractor
This object will be used to extract properties such as CorrelationId from the incoming message
-->
<!ATTLIST router propertyExtractor NMTOKEN #IMPLIED>
<!ELEMENT reply-to EMPTY>
<!--
address
A replyTo address that should be used once a message has been processed. This
property only applies to outbound-routers.
-->
<!ATTLIST reply-to address CDATA #REQUIRED>
<!--
filters are used to determine whether the router should accept the current
message.
Note that any properties on the filter can be set by setting attributes
on the filter element. The properties names are the bean properties names
without the 'set'.
You can also define two filters on a filter, the left filter and right filter
these can be used when using logic filters to join filters.
-->
<!ELEMENT filter (properties?, filter?, left-filter?, right-filter?)>
<!--
className
A fully qualified class name of the Filter to use. Implementations must
use org.mule.umo.UMOFilter.
-->
<!ATTLIST filter className NMTOKEN #REQUIRED>
<!--
because I can't find a way of allowing arbitary attributes on an element,
I am going to define a common set of attributes for filters but users can add their own
or relax dtd validation on their parser
Since Mule 1.1: Arbitary bean properties can be set on a filter using the
<properties> element. The parameters listed below on the filter still work and provider a
short hand way of setting these properties
-->
<!ATTLIST filter pattern CDATA #IMPLIED>
<!ATTLIST filter expression CDATA #IMPLIED>
<!ATTLIST filter configFile CDATA #IMPLIED>
<!ATTLIST filter expectedType CDATA #IMPLIED>
<!ATTLIST filter path CDATA #IMPLIED>
<!-- see explanation for 'filter' element -->
<!ELEMENT left-filter (properties?, filter?, left-filter?, right-filter?)>
<!-- see explanation for 'filter' element -->
<!ATTLIST left-filter className NMTOKEN #REQUIRED>
<!--
because I can't find a way of allowing arbitary attributes on an element,
I am going to define a common set of attributes for filters but users can add their own
or relax dtd validation on their parser
-->
<!ATTLIST left-filter pattern CDATA #IMPLIED>
<!ATTLIST left-filter expression CDATA #IMPLIED>
<!ATTLIST left-filter configFile CDATA #IMPLIED>
<!ATTLIST left-filter expectedType CDATA #IMPLIED>
<!ATTLIST left-filter path CDATA #IMPLIED>
<!-- see explanation for 'filter' element -->
<!ELEMENT right-filter (properties?, filter?, left-filter?, right-filter?)>
<!-- see explanation for 'filter' element -->
<!ATTLIST right-filter className NMTOKEN #REQUIRED>
<!--
because I can't find a way of allowing arbitary attributes on an element,
I am going to define a common set of attributes for filters but users can add their own
or relax dtd validation on their parser
-->
<!ATTLIST right-filter pattern CDATA #IMPLIED>
<!ATTLIST right-filter expression CDATA #IMPLIED>
<!ATTLIST right-filter configFile CDATA #IMPLIED>
<!ATTLIST right-filter expectedType CDATA #IMPLIED>
<!ATTLIST right-filter path CDATA #IMPLIED>
<!--
Interceptors can be executed in sequence before and/or after the Mule component.
-->
<!ELEMENT interceptor (properties?)>
<!--
The fully qualified class name of the interceptor to use. This must implement
<i>org.mule.UMOInterceptor</i>.
-->
<!ATTLIST interceptor className NMTOKEN #IMPLIED>
<!--
The name of a registered interceptor stack.
-->
<!ATTLIST interceptor name NMTOKEN #IMPLIED>
<!--
An exception strategy overrides the default exceptionStrategy in order to control the
exception handling beaviour in the system. The class specified must implement
<i>org.mule.exception.ExceptionStrategy</i>.
-->
<!ELEMENT exception-strategy (endpoint*, global-endpoint*, properties?)>
<!--
An endpoint to dispatch ExceptionMessages (including the Message being processed)
-->
<!--
The fully qualified class name of the exception handler to use. This must implement
org.mule.exception.ExceptionHandler.
-->
<!ATTLIST exception-strategy className NMTOKEN #REQUIRED>
<!--
A collection of properties for the parent component
-->
<!ELEMENT properties ((property | factory-property | container-property | system-property | map | list | file-properties | text-property | bean | spring-property)*)>
<!--
An property element allows arbitrary name/value pairs.
-->
<!ELEMENT property EMPTY>
<!--
The name identifies the name of the attribute.
-->
<!ATTLIST property name CDATA #REQUIRED>
<!--
The value identifies the value of the attribute.
-->
<!ATTLIST property value CDATA #REQUIRED>
<!--
An property element allows for an object to be constructed based on the fully
qualified classname in the factory attribute.
Note that if the class specified extends <i>org.mule.config.PropertyFactory</a> the factory
will be used to create the object.
-->
<!ELEMENT factory-property EMPTY>
<!--
The name identifies the name of the attribute.
-->
<!ATTLIST factory-property name CDATA #REQUIRED>
<!--
A fully qualified classname of the factory to use.
-->
<!ATTLIST factory-property factory CDATA #REQUIRED>
<!--
A property element allows properties to be set from from an IoC contianer
configured on the Model
-->
<!ELEMENT container-property EMPTY>
<!--
The name identifies the name of the attribute on the current object
-->
<!ATTLIST container-property name CDATA #REQUIRED>
<!--
The key identifier for the object to use in the container
-->
<!ATTLIST container-property reference CDATA #REQUIRED>
<!--
The container name to look up the reference in. If this is not
specified all containers are queried. An exception will be thrown
if this property is set but the reference was not found in the container
-->
<!ATTLIST container-property container CDATA #IMPLIED>
<!--
Whether an exception should be thrown if the component is not in the container.
the default is true
-->
<!ATTLIST container-property required (true | false) "true">
<!--
A property element allows properties to be set from the System properties
-->
<!ELEMENT system-property EMPTY>
<!--
The name identifies the name of the attribute on the object being configured
-->
<!ATTLIST system-property name CDATA #REQUIRED>
<!--
The system property key to use when lookin up the property
-->
<!ATTLIST system-property key CDATA #REQUIRED>
<!--
The default value will be used of the system property is not set.
-->
<!ATTLIST system-property defaultValue CDATA #IMPLIED>
<!--
Defines a set of properties for a map property
-->
<!ELEMENT map ((property | factory-property | container-property | system-property | map | list | file-properties)*)>
<!--
the name of the map property
-->
<!ATTLIST map name NMTOKEN #REQUIRED>
<!--
Defines a list of properties for a list property
-->
<!ELEMENT list ((entry | factory-entry | system-entry | container-entry)*)>
<!--
the name of the list property
-->
<!ATTLIST list name CDATA #REQUIRED>
<!--
Defines an entry for a list or array property
-->
<!ELEMENT entry EMPTY>
<!--
the value of the entry
-->
<!ATTLIST entry value CDATA #REQUIRED>
<!--
Defines an factory entry for a list or array property
-->
<!ELEMENT factory-entry EMPTY>
<!--
the factory class to use to create the entry
-->
<!ATTLIST factory-entry factory NMTOKEN #REQUIRED>
<!--
Defines an entry for a list or array property where the value is obtained
from a container such as Spring
-->
<!ELEMENT container-entry EMPTY>
<!--
the reference of the object in the container
-->
<!ATTLIST container-entry reference CDATA #REQUIRED>
<!--
determines if the object must be present in the container for configuration to
succeed
-->
<!ATTLIST container-entry required (true | false) "true">
<!--
Defines an entry for a list or array property
-->
<!ELEMENT system-entry EMPTY>
<!--
the key of the system property
-->
<!ATTLIST system-entry key CDATA #REQUIRED>
<!--
a default value if the property is not found
-->
<!ATTLIST system-entry defaultValue CDATA #IMPLIED>
<!--
Loads properies from a java.properties file
-->
<!ELEMENT file-properties EMPTY>
<!--
The path to the properties file on the classpath or local file system
-->
<!ATTLIST file-properties location CDATA #REQUIRED>
<!--
Whether the properties in the properties file override properties already set on this object
-->
<!ATTLIST file-properties override (true | false) "true">
<!--
An property element allows to embed arbitary text as a property, such as script or xml
-->
<!ELEMENT text-property (#PCDATA)>
<!--
The name identifies the name of the attribute.
-->
<!ATTLIST text-property name CDATA #REQUIRED>
<!--
Optional description of the enclosing element.
Used for user documentation of XML bean definition documents.
-->
<!ELEMENT description (#PCDATA)>
<!--
============================================================================
== Spring Configuration ==
============================================================================
-->
<!--
Specifies an XML bean definition resource to import.
-->
<!ELEMENT import EMPTY>
<!--
The relative resource location of the XML bean definition file to import,
for example "myImport.xml" or "includes/myImport.xml" or "../myImport.xml".
-->
<!ATTLIST import resource CDATA #REQUIRED>
<!--
Defines an alias for a bean, which can reside in a different definition file.
-->
<!ELEMENT alias EMPTY>
<!--
The name of the bean to define an alias for.
-->
<!ATTLIST alias name CDATA #REQUIRED>
<!--
The alias name to define for the bean.
-->
<!ATTLIST alias alias CDATA #REQUIRED>
<!--
Defines a single named bean.
-->
<!ELEMENT bean (
description?,
(constructor-arg | spring-property | lookup-method | replaced-method)*
)>
<!--
Beans can be identified by an id, to enable reference checking.
There are constraints on a valid XML id: if you want to reference your bean
in Java code using a name that's illegal as an XML id, use the optional
"name" attribute. If neither given, the bean class name is used as id.
-->
<!ATTLIST bean id ID #IMPLIED>
<!--
Optional. Can be used to create one or more aliases illegal in an id.
Multiple aliases can be separated by any number of spaces or commas.
-->
<!ATTLIST bean name CDATA #IMPLIED>
<!--
Each bean definition must specify the FQN of the class,
or the name of the parent bean from which the class can be worked out.
Note that a child bean definition that references a parent will just
add respectively override property values and be able to change the
singleton status. It will inherit all of the parent's other parameters
like lazy initialization or autowire settings.
-->
<!ATTLIST bean class CDATA #IMPLIED>
<!--
Optionally specify a parent bean definition.
Will use the bean class of the parent if none specified, but can
also override it. In the latter case, the child bean class must be
compatible with the parent, i.e. accept the parent's property values
and constructor argument values, if any.
A child bean definition will inherit constructor argument values,
property values and method overrides from the parent, with the option
to add new values. If init method, destroy method, factory bean and/or factory
method are specified, they will override the corresponding parent settings.
The remaining settings will always be taken from the child definition:
depends on, autowire mode, dependency check, singleton, lazy init.
-->
<!ATTLIST bean parent CDATA #IMPLIED>
<!--
Is this bean "abstract", i.e. not meant to be instantiated itself but
rather just serving as parent for concrete child bean definitions.
Default is false. Specify true to tell the bean factory to not try to
instantiate that particular bean in any case.
-->
<!ATTLIST bean abstract (true | false) "false">
<!--
Is this bean a "singleton" (one shared instance, which will
be returned by all calls to getBean() with the id),
or a "prototype" (independent instance resulting from each call to
getBean(). Default is singleton.
Singletons are most commonly used, and are ideal for multi-threaded
service objects.
-->
<!ATTLIST bean singleton (true | false) "true">
<!--
If this bean should be lazily initialized.
If false, it will get instantiated on startup by bean factories
that perform eager initialization of singletons.
-->
<!ATTLIST bean lazy-init (true | false | default) "default">
<!--
Optional attribute controlling whether to "autowire" bean properties.
This is an automagical process in which bean references don't need to be coded
explicitly in the XML bean definition file, but Spring works out dependencies.
There are 5 modes:
1. "no"
The traditional Spring default. No automagical wiring. Bean references
must be defined in the XML file via the <ref> element. We recommend this
in most cases as it makes documentation more explicit.
2. "byName"
Autowiring by property name. If a bean of class Cat exposes a dog property,
Spring will try to set this to the value of the bean "dog" in the current factory.
3. "byType"
Autowiring if there is exactly one bean of the property type in the bean factory.
If there is more than one, a fatal error is raised, and you can't use byType
autowiring for that bean. If there is none, nothing special happens - use
dependency-check="objects" to raise an error in that case.
4. "constructor"
Analogous to "byType" for constructor arguments. If there isn't exactly one bean
of the constructor argument type in the bean factory, a fatal error is raised.
5. "autodetect"
Chooses "constructor" or "byType" through introspection of the bean class.
If a default constructor is found, "byType" gets applied.
The latter two are similar to PicoContainer and make bean factories simple to
configure for small namespaces, but doesn't work as well as standard Spring
behaviour for bigger applications.
Note that explicit dependencies, i.e. "property" and "constructor-arg" elements,
always override autowiring. Autowire behaviour can be combined with dependency
checking, which will be performed after all autowiring has been completed.
-->
<!ATTLIST bean autowire (no | byName | byType | constructor | autodetect | default) "default">
<!--
Optional attribute controlling whether to check whether all this
beans dependencies, expressed in its properties, are satisfied.
Default is no dependency checking.
"simple" type dependency checking includes primitives and String
"object" includes collaborators (other beans in the factory)
"all" includes both types of dependency checking
-->
<!ATTLIST bean dependency-check (none | objects | simple | all | default) "default">
<!--
The names of the beans that this bean depends on being initialized.
The bean factory will guarantee that these beans get initialized before.
Note that dependencies are normally expressed through bean properties or
constructor arguments. This property should just be necessary for other kinds
of dependencies like statics (*ugh*) or database preparation on startup.
-->
<!ATTLIST bean depends-on CDATA #IMPLIED>
<!--
Optional attribute for the name of the custom initialization method
to invoke after setting bean properties. The method must have no arguments,
but may throw any exception.
-->
<!ATTLIST bean init-method CDATA #IMPLIED>
<!--
Optional attribute for the name of the custom destroy method to invoke
on bean factory shutdown. The method must have no arguments,
but may throw any exception. Note: Only invoked on singleton beans!
-->
<!ATTLIST bean destroy-method CDATA #IMPLIED>
<!--
Optional attribute specifying the name of a static factory method to use
to create this object. Use constructor-arg elements to specify arguments
to the factory method, if it takes arguments. Autowiring does not
apply to factory methods.
The factory method will be on the class specified by the "class" attribute
on this bean definition. Often this will be the same class as that of the
constructed object - for example, when the factory method is used as an
alternative to a constructor. However, it may be on a different class. In
that case, the created object will *not* be of the class specified in
the "class" attribute. This is analogous to FactoryBean behaviour.
The factory method can have any number of arguments. Autowiring is not supported.
Use indexed constructor-arg elements in conjunction with the factory-method
attribute.
Setter Injection can be used in conjunction with a factory method.
Method Injection cannot, as the factory method returns an instance, which
will be used when the container creates the bean.
-->
<!ATTLIST bean factory-method CDATA #IMPLIED>
<!--
Alternative to class attribute for factory-method usage.
If this is specified, no class attribute should be used.
This should be set to the name of a bean in the current or
ancestor factories that contains the relevant factory method.
This allows the factory itself to be configured using Dependency
Injection, and an instance (rather than static) method to be used.
-->
<!ATTLIST bean factory-bean CDATA #IMPLIED>
<!--
Bean definitions can specify zero or more constructor arguments.
They correspond to either a specific index of the constructor argument list
or are supposed to be matched generically by type.
This is an alternative to "autowire constructor".
constructor-arg elements are also used in conjunction with the factory-method
element to construct beans using static factory methods.
-->
<!ELEMENT constructor-arg (
description?,
(bean | ref | CDATA | value | null | spring-list | set | spring-map | props)
)>
<!--
The constructor-arg tag can have an optional index attribute,
to specify the exact index in the constructor argument list. Only needed
to avoid ambiguities, e.g. in case of 2 arguments of the same type.
-->
<!ATTLIST constructor-arg index CDATA #IMPLIED>
<!--
The constructor-arg tag can have an optional type attribute,
to specify the exact type of the constructor argument. Only needed
to avoid ambiguities, e.g. in case of 2 single argument constructors
that can both be converted from a String.
-->
<!ATTLIST constructor-arg type CDATA #IMPLIED>
<!--
A short-cut alternative to a child element "ref bean=".
-->
<!ATTLIST constructor-arg ref CDATA #IMPLIED>
<!--
A short-cut alternative to a child element "value".
-->
<!ATTLIST constructor-arg value CDATA #IMPLIED>
<!--
Mule-specific spring-property element used to differenciate between Mule property element
and springs
Bean definitions can have zero or more properties.
Property elements correspond to JavaBean setter methods exposed
by the bean classes. Spring supports primitives, references to other
beans in the same or related factories, lists, maps and properties.
-->
<!ELEMENT spring-property (
description?,
(bean | ref | CDATA | value | null | spring-list | set | spring-map | props)
)>
<!--
The property name attribute is the name of the JavaBean property.
This follows JavaBean conventions: a name of "age" would correspond
to setAge()/optional getAge() methods.
-->
<!ATTLIST spring-property name CDATA #REQUIRED>
<!--
A short-cut alternative to a child element "ref bean=".
-->
<!ATTLIST property ref CDATA #IMPLIED>
<!--
A short-cut alternative to a child element "value".
-->
<!ATTLIST property value CDATA #IMPLIED>
<!--
A lookup method causes the IoC container to override the given method and return
the bean with the name given in the bean attribute. This is a form of Method Injection.
It's particularly useful as an alternative to implementing the BeanFactoryAware
interface, in order to be able to make getBean() calls for non-singleton instances
at runtime. In this case, Method Injection is a less invasive alternative.
-->
<!ELEMENT lookup-method EMPTY>
<!--
Name of a lookup method. This method should take no arguments.
-->
<!ATTLIST lookup-method name CDATA #IMPLIED>
<!--
Name of the bean in the current or ancestor factories that the lookup method
should resolve to. Often this bean will be a prototype, in which case the
lookup method will return a distinct instance on every invocation. This
is useful for single-threaded objects.
-->
<!ATTLIST lookup-method bean CDATA #IMPLIED>
<!--
Similar to the lookup method mechanism, the replaced-method element is used to control
IoC container method overriding: Method Injection. This mechanism allows the overriding
of a method with arbitrary code.
-->
<!ELEMENT replaced-method (
(arg-type)*
)>
<!--
Name of the method whose implementation should be replaced by the IoC container.
If this method is not overloaded, there's no need to use arg-type subelements.
If this method is overloaded, arg-type subelements must be used for all
override definitions for the method.
-->
<!ATTLIST replaced-method name CDATA #IMPLIED>
<!--
Bean name of an implementation of the MethodReplacer interface
in the current or ancestor factories. This may be a singleton or prototype
bean. If it's a prototype, a new instance will be used for each method replacement.
Singleton usage is the norm.
-->
<!ATTLIST replaced-method replacer CDATA #IMPLIED>
<!--
Subelement of replaced-method identifying an argument for a replaced method
in the event of method overloading.
-->
<!ELEMENT arg-type (#PCDATA)>
<!--
Specification of the type of an overloaded method argument as a String.
For convenience, this may be a substring of the FQN. E.g. all the
following would match "java.lang.String":
- java.lang.String
- String
- Str
As the number of arguments will be checked also, this convenience can often
be used to save typing.
-->
<!ATTLIST arg-type match CDATA #IMPLIED>
<!--
Defines a reference to another bean in this factory or an external
factory (parent or included factory).
-->
<!ELEMENT ref EMPTY>
<!--
References must specify a name of the target bean.
The "bean" attribute can reference any name from any bean in the context,
to be checked at runtime.
Local references, using the "local" attribute, have to use bean ids;
they can be checked by this DTD, thus should be preferred for references
within the same bean factory XML file.
-->
<!ATTLIST ref bean CDATA #IMPLIED>
<!ATTLIST ref local CDATA #IMPLIED>
<!ATTLIST ref parent CDATA #IMPLIED>
<!--
Defines a string property value, which must also be the id of another
bean in this factory or an external factory (parent or included factory).
While a regular 'value' element could instead be used for the same effect,
using CDATA in this case allows validation of local bean ids by the xml
parser, and name completion by helper tools.
-->
<!ELEMENT CDATA EMPTY>
<!--
ID refs must specify a name of the target bean.
The "bean" attribute can reference any name from any bean in the context,
potentially to be checked at runtime by bean factory implementations.
Local references, using the "local" attribute, have to use bean ids;
they can be checked by this DTD, thus should be preferred for references
within the same bean factory XML file.
-->
<!ATTLIST CDATA bean CDATA #IMPLIED>
<!ATTLIST CDATA local CDATA #IMPLIED>
<!--
Contains a string representation of a property value.
The property may be a string, or may be converted to the
required type using the JavaBeans PropertyEditor
machinery. This makes it possible for application developers
to write custom PropertyEditor implementations that can
convert strings to objects.
Note that this is recommended for simple objects only.
Configure more complex objects by populating JavaBean
properties with references to other beans.
-->
<!ELEMENT value (#PCDATA)>
<!--
The value tag can have an optional type attribute, to specify the
exact type that the value should be converted to. Only needed
if the type of the target property or constructor argument is
too generic: for example, in case of a collection element.
-->
<!ATTLIST value type CDATA #IMPLIED>
<!--
Denotes a Java null value. Necessary because an empty "value" tag
will resolve to an empty String, which will not be resolved to a
null value unless a special PropertyEditor does so.
-->
<!ELEMENT null (#PCDATA)>
<!--
A list can contain multiple inner bean, ref, collection, or value elements.
Java lists are untyped, pending generics support in Java 1.5,
although references will be strongly typed.
A list can also map to an array type. The necessary conversion
is automatically performed by the BeanFactory.
-->
<!ELEMENT spring-list (
(bean | ref | CDATA | value | null | spring-list | set | spring-map | props)*
)>
<!--
A set can contain multiple inner bean, ref, collection, or value elements.
Java sets are untyped, pending generics support in Java 1.5,
although references will be strongly typed.
-->
<!ELEMENT set (
(bean | ref | CDATA | value | null | spring-list | set | spring-map | props)*
)>
<!--
A Spring map is a mapping from a string key to object.
Maps may be empty.
-->
<!ELEMENT spring-map (
(spring-entry)*
)>
<!--
A map entry can be an inner bean, ref, collection, or value.
The name of the property is given by the "key" attribute.
-->
<!ELEMENT spring-entry (
key?,
(bean | ref | CDATA | value | null | spring-list | set | spring-map | props)
)>
<!--
Each map element must specify its key.
-->
<!ATTLIST spring-entry key CDATA #REQUIRED>
<!--
A short-cut alternative to a "key" element with a "ref bean=" child element.
-->
<!ATTLIST spring-entry key-ref CDATA #IMPLIED>
<!--
A short-cut alternative to a child element "value".
-->
<!ATTLIST spring-entry value CDATA #IMPLIED>
<!--
A short-cut alternative to a child element "ref bean=".
-->
<!ATTLIST spring-entry value-ref CDATA #IMPLIED>
<!--
A key element can contain an inner bean, ref, value, or collection.
-->
<!ELEMENT key (
(bean | ref | CDATA | value | null | spring-list | set | spring-map | props)
)>
<!--
Props elements differ from map elements in that values must be strings.
Props may be empty.
-->
<!ELEMENT props (
(prop)*
)>
<!--
Element content is the string value of the property.
Note that whitespace is trimmed off to avoid unwanted whitespace
caused by typical XML formatting.
-->
<!ELEMENT prop (#PCDATA)
>
<!--
Each property element must specify its key.
-->
<!ATTLIST prop key CDATA #REQUIRED>
Reference in a new issue View git blame Copy permalink