| <?xml version="1.0" encoding="UTF-8"?> | |
| <!-- | |
| Licensed to the Apache Software Foundation (ASF) under one or more | |
| contributor license agreements. See the NOTICE file distributed with | |
| this work for additional information regarding copyright ownership. | |
| The ASF licenses this file to You under the Apache License, Version 2.0 | |
| (the "License"); you may not use this file except in compliance with | |
| the License. You may obtain a copy of the License at | |
| http://www.apache.org/licenses/LICENSE-2.0 | |
| Unless required by applicable law or agreed to in writing, software | |
| distributed under the License is distributed on an "AS IS" BASIS, | |
| WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. | |
| See the License for the specific language governing permissions and | |
| limitations under the License. | |
| --> | |
| <services-config> | |
| <!-- Example services-config.xml --> | |
| <services> | |
| <!-- | |
| Individual services may be defined in this file or broken into their own file. We've chosen to include | |
| a separate configuration file for each type of service. Please see those files for more details on the | |
| configuration specific to each of those types of service. | |
| --> | |
| <service-include file-path="remoting-config.xml" /> | |
| <service-include file-path="proxy-config.xml" /> | |
| <service-include file-path="messaging-config.xml" /> | |
| <!-- | |
| You can include a collection of service include files in a directory, | |
| The directory is relative to the location of this file. | |
| All files with a ".xml" extenstion will be included. | |
| --> | |
| <service-include directory-path="services"/> | |
| <!-- | |
| Custom bootstrap services can be defined here. Bootstrap services are used to dynamically create services, | |
| destinations, and adapters at server startup. | |
| --> | |
| <service id="bootstrap1" class="my.company.BootstrapService1"/> | |
| <service id="bootstrap2" class="my.company.BootstrapService2"> | |
| <!-- Bootstrap services can also have custom properties that can be processed in initialize method --> | |
| <properties> | |
| <prop1>value1</prop1> | |
| <prop2>value2</prop2> | |
| </properties> | |
| </service> | |
| <!-- | |
| Set the application level default channels to use as transport for all services. | |
| Default channels can also be defined individually for each service and in that | |
| case, application level default channels are overwritten by the service level | |
| default channels. Application level default channels are necessary when | |
| a dynamic destination is being used and no ChannelSet has been defined for | |
| the destination. In that case, application level default channels will be | |
| used to contact the destination. | |
| --> | |
| <default-channels> | |
| <channel ref="my-amf"/> | |
| </default-channels> | |
| </services> | |
| <security> | |
| <login-command class="flex.messaging.security.TomcatLoginCommand" server="Tomcat"> | |
| <!-- per-client-authentication is false by default. Setting it to true allows | |
| multiple clients sharing the same session to have distinct authentication states. | |
| Two windows of the same browser for example could then authenticate users | |
| independently. Note that if this flag is true, a custom LoginCommand must be used | |
| and an application server based LoginCommand cannot be used. | |
| --> | |
| <per-client-authentication>false</per-client-authentication> | |
| </login-command> | |
| <!-- Uncomment the correct app server. Add per-client-authentication="true". | |
| Note that if server is set to "all" for a login command, that login | |
| command will be used regardless of the application server in use. For JBoss | |
| releases 4.2 and higher server should be set to JBoss; for earlier release of JBoss | |
| use Tomcat as the server value. Note that you may have more than one login-command | |
| specified and the one corresponding to your server will be used. | |
| <login-command class="flex.messaging.security.TomcatLoginCommand" server="JBoss"> | |
| <login-command class="flex.messaging.security.JRunLoginCommand" server="JRun"> | |
| <login-command class="flex.messaging.security.WeblogicLoginCommand" server="Weblogic"/> | |
| <login-command class="flex.messaging.security.WebSphereLoginCommand" server="WebSphere"/> | |
| <login-command class="flex.messaging.security.OracleLoginCommand" server="Oracle"/> | |
| --> | |
| <security-constraint id="basic-read-access"> | |
| <auth-method>Basic</auth-method> | |
| <roles> | |
| <role>guests</role> | |
| <role>accountants</role> | |
| <role>employees</role> | |
| <role>managers</role> | |
| </roles> | |
| </security-constraint> | |
| <security-constraint id="sample-users"> | |
| <auth-method>Custom</auth-method> | |
| <roles> | |
| <role>sampleusers</role> | |
| </roles> | |
| </security-constraint> | |
| <!-- | |
| Multiple constraints may be specified either in this file | |
| or they could be broken into their own file. | |
| To collect multiple constrains in a single file, wrap them in a <security-constraints> tag | |
| --> | |
| <constraint-include file-path="my-constraint.xml"/> | |
| <!-- This will include all *.xml files in the directory 'my-constraints'. --> | |
| <constraint-include directory-path="my-constraints"/> | |
| <!-- Optional, default is false. When enabled, upon successful login the | |
| HTTP FlexSession is invalidated and recreated in order to prevent | |
| session fixation attacks. | |
| --> | |
| <recreate-httpsession-after-login>false</recreate-httpsession-after-login> | |
| </security> | |
| <!-- | |
| You can add your own component factory to BlazeDS. When BlazeDS wants an | |
| instance of a component for a particular remote object or FDMS | |
| destination, it will call a method on your class which implements | |
| flex.messaging.FlexFactory instead of creating this component itself. | |
| This mechanism is designed to allow a more seamless integration of 3rd | |
| party component management systems like Spring, EJB, etc. Your factory | |
| itself can take initialization properties for the factory as a whole as | |
| specified in the properties tag under the factory tag. Each instance | |
| that uses that factory can also take additional configuration properties | |
| via the properties tag for the destination that uses that factory. This | |
| configuration sample simply registers the default java factory under a | |
| name. | |
| --> | |
| <factories> | |
| <factory id="myJavaFactory" class="flex.messaging.factories.JavaFactory" /> | |
| </factories> | |
| <!-- | |
| Channels define how clients communicate with server endpoints. A channel | |
| that makes use of a servlet mapping (such as an HTTP or AMF channel) | |
| must ensure an endpoint URL is distinguished by path info. A channel | |
| that makes use of a direct socket connection (such as an RTMP channel) | |
| must ensure an endpoint URL has a unique port number. | |
| --> | |
| <channels> | |
| <channel-definition id="my-amf" class="mx.messaging.channels.AMFChannel"> | |
| <endpoint url="http://{server.name}:{server.port}/{context.root}/messagebroker/amf" class="flex.messaging.endpoints.AMFEndpoint"/> | |
| <properties> | |
| <polling-enabled>false</polling-enabled> | |
| <!-- Optional piggybacking setting. Enable to support piggybacking queued messaging | |
| and data management subscription data along with responses to any messages the | |
| client sends to the server over this channel. --> | |
| <piggybacking-enabled>true</piggybacking-enabled> | |
| <!-- Optional serialization properties. --> | |
| <serialization> | |
| <!-- create-asobject-for-missing-type is false by default. | |
| When true, instead of throwing a resource not found error, | |
| endpoint simply creates an ASObject for the missing type. | |
| --> | |
| <create-asobject-for-missing-type>false</create-asobject-for-missing-type> | |
| <!-- enable-small-messages is true by default. If enabled, | |
| messages will be sent using an alternative smaller form if | |
| one is available and is supported by the endpoint. | |
| --> | |
| <enable-small-messages>true</enable-small-messages> | |
| <!-- include-read-only is false by default. It determines | |
| if the read-only properties should be serialized back | |
| to the client. | |
| --> | |
| <include-read-only>false</include-read-only> | |
| <!-- ignore-property-errors is true by default. It determines | |
| if the endpoint should throw an error when an incoming | |
| client object has unexpected properties that cannot be | |
| set on the server object. | |
| --> | |
| <ignore-property-errors>true</ignore-property-errors> | |
| <!-- log-property-errors is false by default. When true, | |
| unexpected property errors are logged. | |
| --> | |
| <log-property-errors>false</log-property-errors> | |
| <!-- To support legacy AMF type serialization used in earlier | |
| versions of Flex, you can set legacy properties. | |
| --> | |
| <!-- legacy-collection is false by default. When true, during client to | |
| server deserialization, instances of Actionscript arrays are | |
| deserialized into Java Lists, as opposed to Java Object arrays. | |
| During server to client serialization, when true, instances of | |
| java.util.Collection are returned as ActionScript Arrays, as opposed | |
| to mx.collections.ArrayCollection (part of Flex 2 collections API). | |
| --> | |
| <legacy-collection>false</legacy-collection> | |
| <!-- legacy-dictionary is false by default. When true, during server to | |
| client serialization, instances of java.util.Dictionary are serialized | |
| as anonymous Object rather than flash.utils.Dictionary type. | |
| --> | |
| <legacy-dictionary>false</legacy-dictionary> | |
| <!-- legacy-map is false by default. When true, java.util.Map | |
| instances are serialized as an ECMA Array or | |
| "associate array" instead of an anonymous Object. | |
| --> | |
| <legacy-map>false</legacy-map> | |
| <!-- legacy-xml is false by default. When true, | |
| org.w3c.dom.Document instances are serialized as | |
| flash.xml.XMLDocument instances instead of intrinsic | |
| XML (E4X capable) instances. | |
| --> | |
| <legacy-xml>false</legacy-xml> | |
| <!-- legacy-xml-namespaces is false by default. When true, | |
| XML Documents created on server during deserialization | |
| of XML passed-in from the client are NOT namespace aware. | |
| --> | |
| <legacy-xml-namespaces>false</legacy-xml-namespaces> | |
| <!-- legacy-throwable is false by default. When true, | |
| java.lang.Throwable instances are serialized as AMF | |
| status-info objects (instead of normal bean serialization | |
| including read-only properties). | |
| --> | |
| <legacy-throwable>false</legacy-throwable> | |
| <!-- legacy-externalizable is false by default. When true, | |
| java.io.Externalizable types (that extend standard Java | |
| classes like Date, Number, String) are not serialized as | |
| custom objects (eg. MyDate will be serialized as Date | |
| instead of MyDate). Note that this setting overwrites | |
| any other legacy settings. For example, if legacy-collection | |
| is true but the collection implements java.io.Externalizable, | |
| then the collection will be returned as custom object without | |
| taking legacy-collection into account. | |
| --> | |
| <legacy-externalizable>false</legacy-externalizable> | |
| <!-- type-marshaller specifies the implementation that | |
| translates an object into an instance of a desired | |
| class. This is used when invoking a Java method or | |
| populating a Java instance and the type of the input | |
| object from deserialization (e.g. an ActionScript | |
| anonymous Object is always deserialized as a | |
| java.util.HashMap) doesn't match the destination API | |
| (e.g. java.util.SortedMap) so the type can be marshaled | |
| into the desired type. | |
| --> | |
| <!-- prefer-vectors is false by default. When true, Java | |
| Arrays and Lists (except byte and character arrays) are | |
| serialized as Flash Vector instead of Flash Array and | |
| Flex ArrayCollection. | |
| --> | |
| <prefer-vectors>false</prefer-vectors> | |
| <!-- restore-references is false by default. This is an | |
| advanced switch that asks the deserializer to keep track | |
| of object references when a type translation has to be | |
| made (i.e. when an anonymous Object is sent for a | |
| property of type java.util.SortedMap, the Object is first | |
| deserialized to a java.util.Map as normal, and then | |
| translated to a suitable implementation of SortedMap | |
| (i.e. java.util.TreeMap). If other objects pointed to the | |
| same anonymous Object in an object graph, this setting | |
| restores those references instead of creating new | |
| SortedMap implementations everywhere. This can significantly | |
| slow down performance for large amounts of data, however. | |
| --> | |
| <restore-references>false</restore-references> | |
| <!-- instantiate-types is true by default. This is an | |
| advanced switch that asks the deserializer to not create | |
| new instances of strongly typed objects but instead | |
| retains the type info and deserializes the raw | |
| properties in a Map implementation, namely | |
| flex.messaging.io.ASObject. Note that any classes under | |
| flex.* package will always be instantiated. | |
| --> | |
| <instantiate-types>true</instantiate-types> | |
| <!-- Optional. The max collection nest level determines how many nested levels of collection | |
| objects are supported in the object graph. Deeply nested collections can lead to performance | |
| issues especially when the collection is assigned to a Set type on the server as this triggers | |
| the hashcode to be calculated for all objects in the object graph. It is recommended that | |
| this number be kept relatively small. By default, it is set to 15. | |
| --> | |
| <max-collection-nest-level>15</max-collection-nest-level> | |
| <!-- Optional. The max object nest level determines how many nested levels of objects are | |
| supported in the object graph. As serialization walks recursively into the object graph, the | |
| max object nest limit can prevent a recursion stack overflow. By default, it is set to 512. | |
| --> | |
| <max-object-nest-level>512</max-object-nest-level> | |
| <!-- | |
| Per default the expansion of external entities in xml is disabled for | |
| security reasons. If you require them to be expanded, turn this option | |
| to true. See also: | |
| https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing | |
| --> | |
| <allow-xml-external-entity-expansion>true</allow-xml-external-entity-expansion> | |
| </serialization> | |
| <!-- Optional. Use this to limit the client channel's connect attempt | |
| to the specified time interval. | |
| <connect-timeout-seconds>5</connect-timeout-seconds> | |
| --> | |
| <!-- Optional. If enabled, when a disconnect message is received from a | |
| client channel the corresponding server session will be invalidated. | |
| If the client is closed without first disconnecting its channel, no | |
| disconnect message is sent and the server session will invalidate | |
| after its idle timeout has elapsed. | |
| This is disabled by default. | |
| <invalidate-session-on-disconnect>true</invalidate-session-on-disconnect> | |
| --> | |
| <!-- Optional. Default is true. If disabled, session rewriting is not allowed | |
| which means that the client needs to have session cookies enabled and the | |
| server will not allow session identifier to be added to the HTTP request URL | |
| <session-rewriting-enabled>true</session-rewriting-enabled> | |
| --> | |
| </properties> | |
| </channel-definition> | |
| <!-- An AMF channel that uses HTTPS for secure communication can use | |
| the {server.port} token as a SWF must be loaded via a secure URL | |
| in order to make secure connections. | |
| --> | |
| <channel-definition id="my-secure-amf" class="mx.messaging.channels.SecureAMFChannel"> | |
| <endpoint url="https://{server.name}:{server.port}/{context.root}/messagebroker/amfsecure" class="flex.messaging.endpoints.SecureAMFEndpoint"/> | |
| <properties> | |
| <!--HTTPS requests on some browsers do not work when pragma "no-cache" are set--> | |
| <add-no-cache-headers>false</add-no-cache-headers> | |
| <!-- Optional. Use this to limit the client channel's connect attempt | |
| to the specified time interval. | |
| <connect-timeout-seconds>5</connect-timeout-seconds> | |
| --> | |
| </properties> | |
| </channel-definition> | |
| <channel-definition id="my-polling-amf" class="mx.messaging.channels.AMFChannel"> | |
| <endpoint url="http://{server.name}:{server.port}/{context.root}/messagebroker/amfpolling" class="flex.messaging.endpoints.AMFEndpoint"/> | |
| <properties> | |
| <polling-enabled>true</polling-enabled> | |
| <!-- Optional. Default is 3000. This parameter specifies the number | |
| of milliseconds the client waits before polling the server | |
| again. When polling-interval-millis is 0, the client polls | |
| as soon as it receives a response from the server with no delay. | |
| --> | |
| <polling-interval-millis>3000</polling-interval-millis> | |
| <!-- Optional. Default is 0. This parameter specifies the number of milliseconds the | |
| server poll response thread will wait for new messages to arrive when the server | |
| has no messages for the client at the time of poll request handling. 0 means | |
| that server does not wait for new messages for the client and returns an empty | |
| acknowledgment as usual. -1 means that server waits indefinitely until new | |
| messages arrive for the client before responding the client poll request. This | |
| setting requires a max-waiting-poll-requests greater than 0 in order to take | |
| effect. When parking requests, ie. not using a wait-interval of 0, the | |
| recommended server wait time is between 1 and 5 minutes. The reason waiting | |
| indefinitely is not recommended is to keep connections alive when they’re | |
| traversing a network component (firewall/proxy) that auto-closes connections | |
| that appear to be idle or connections where an HTTP request has not received a | |
| response within some time limit defined by a proxy in the network path. By | |
| limiting the server wait to just a minute or a few minutes, you drastically reduce | |
| the amount of busy polling happening on quiet connections, but the request-reply | |
| circuit for long polls is completing quickly enough to avoid potential network | |
| issues. | |
| --> | |
| <wait-interval-millis>0</wait-interval-millis> | |
| <!-- Optional. Default is 0. This parameter specifies the maximum | |
| number of server poll response threads that can be in wait | |
| state. When this limit is reached, the subsequent poll requests | |
| will be treated as having zero wait-interval-millis. | |
| --> | |
| <max-waiting-poll-requests>0</max-waiting-poll-requests> | |
| <!-- Optional. Default is 0. This parameter specifies the number of milliseconds the | |
| client will wait after it receives a poll response from the server that involved | |
| a server wait. 0 means that the client will use its configured polling-interval-millis | |
| value to determine the wait until its next poll. Otherwise, this value will override | |
| the client's default polling interval. Setting this value to 1 will allow clients that | |
| poll the server with wait to poll immediately upon receiving a poll response, providing | |
| a real-time message stream from the server to the client. Any clients that poll the | |
| server and are not serviced with a server wait will use the polling-interval-millis value. | |
| Use this setting in conjunction with the wait-interval-millis setting. | |
| --> | |
| <client-wait-interval-millis>0</client-wait-interval-millis> | |
| <!-- Optional. Default is false. Setting this flag to true will cause clients | |
| to automatically attempt to re-authenticate themselves with the server when | |
| they send a message that fails because credentials have been reset due to server | |
| session timeout. The failed message will be resent after re-authentication making the | |
| session timeout transparent to the client with respect to authentication. | |
| --> | |
| <login-after-disconnect>false</login-after-disconnect> | |
| <!-- Optional. Use this to manage messaging quality of service for subscribers. | |
| Every client that subscribes to the server over this channel will have a unique instance | |
| of the specified outbound queue processor implementation that will manage the flow of | |
| messages to the client. This may include message conflation, filtering, scheduled delivery | |
| and load shedding. Configuration properties may be defined, and if so, they are used to | |
| configure each new queue processor instance that is created. Here's an example. | |
| <flex-client-outbound-queue-processor class="my.company.QoSQueueProcessor"> | |
| <properties> | |
| <custom-property>5000</custom-property> | |
| </properties> | |
| </flex-client-outbound-queue-processor> | |
| --> | |
| <!-- Optional. Use this to limit the client channel's connect attempt | |
| to the specified time interval. | |
| <connect-timeout-seconds>5</connect-timeout-seconds> | |
| --> | |
| <!-- Optional. If enabled, when a disconnect message is received from a | |
| client channel the corresponding server session will be invalidated. | |
| If the client is closed without first disconnecting its channel, no | |
| disconnect message is sent and the server session will invalidate | |
| after its idle timeout has elapsed. | |
| This is disabled by default. | |
| <invalidate-session-on-disconnect>true</invalidate-session-on-disconnect> | |
| --> | |
| <!-- Optional. Default values are as shown. User agents are used to customize | |
| a long-polling or streaming endpoints for specific browsers. Long-polling | |
| and streaming endpoints require persistent HTTP connections which are | |
| limited differently by different browsers per session. | |
| A single long-poll connection requires two browser HTTP connections in | |
| order to send data in both directions. One for the streamed response from the server | |
| to the client that the channel hangs on to, and a second transient connection, drawn | |
| from the browser pool only when data needs to be sent to the server and this second | |
| transient connection is then immediately released back to the browser's connection pool. | |
| In order for client applications to function properly, the number of HTTP connections | |
| made by all clients running in the same session (keep in mind that clients running in | |
| separate browser windows can share the same HTTP session) needs to stay within the limit | |
| established by the browser. The max-persistent-connections-per-session setting is used to | |
| limit the number of long-polling or streaming connections that can be made from clients | |
| in the same browser session. | |
| The special match string "*" will define a default to be used if no string matches. | |
| The match strings "MSIE" and "Firefox" are always defined and must be specified | |
| here explicitly to override the default settings, specifying "*" does not do so. | |
| If you are using streaming channels, you should configure both the streaming and polling | |
| channels to the same values. | |
| --> | |
| <user-agent-settings> | |
| <!-- MSIE 5, 6, 7 limit is 2. | |
| <user-agent match-on="MSIE" max-persistent-connections-per-session="1" kickstart-bytes="2048"/> | |
| --> | |
| <!-- MSIE 8 limit is 6. | |
| <user-agent match-on="MSIE 8" max-persistent-connections-per-session="5" kickstart-bytes="2048"/> | |
| --> | |
| <!-- Firefox 1, 2 limit is 2. | |
| <user-agent match-on="Firefox" max-persistent-connections-per-session="1"/> | |
| --> | |
| <!-- Firefox 3 limit is 6. | |
| <user-agent match-on="Firefox/3" max-persistent-connections-per-session="5"/> | |
| --> | |
| <!-- Safari 3, 4 limit is 4. | |
| <user-agent match-on="Safari" max-persistent-connections-per-session="3"/> | |
| --> | |
| <!-- Chrome 0, 1, 2 limit is 6. | |
| <user-agent match-on="Chrome" max-persistent-connections-per-session="5"/> | |
| --> | |
| <!-- Opera 7, 9 limit is 4. | |
| <user-agent match-on="Opera" max-persistent-connections-per-session="3"/> | |
| --> | |
| <!-- Opera 8 limit is 8. | |
| <user-agent match-on="Opera 8" max-persistent-connections-per-session="7"/> | |
| --> | |
| <!-- Opera 10 limit is 8. | |
| <user-agent match-on="Opera/9.8" max-persistent-connections-per-session="7"/> | |
| --> | |
| </user-agent-settings> | |
| </properties> | |
| </channel-definition> | |
| <!-- A streaming AMF channel definition. Streaming AMF/HTTP channels are similar | |
| to polling channels but instead of polling, a seperate HTTP connection | |
| is opened for the streaming endpoint to push messages to the client. | |
| This offers performance advantages over polling when the client is receiving | |
| a steady, rapid stream of pushed messages. Note that streaming channels might not | |
| work through some proxy servers due to proxy buffering of chunked responses used by streaming | |
| channels. Therefore it is a best practice to use a polling channel as a backup for a streaming | |
| channel and set connect-timeout-seconds of streaming channel to a reasonable value (eg. 5 secs) | |
| so that the streaming channel can fall back to polling channel in a reasonable amount of time. | |
| --> | |
| <channel-definition id="my-streaming-amf" class="mx.messaging.channels.StreamingAMFChannel"> | |
| <endpoint url="http://{server.name}:{server.port}/{context.root}/messagebroker/streamingamf" class="flex.messaging.endpoints.StreamingAMFEndpoint"/> | |
| <properties> | |
| <!-- Optional. Default value is 0. This parameter specifies the number of minutes | |
| that a streaming channel is allowed to remain idle before being closed. | |
| Setting connection-idle-timeout-minutes to 0 will disable the timeout. | |
| Note that this is a potential security concern. | |
| <connection-idle-timeout-minutes>0</connection-idle-timeout-minutes> | |
| --> | |
| <!-- Optional. Default value is 10. Limits the number of streaming Flex clients | |
| using this endpoint. This should be adjusted by taking the number of threads | |
| available on the server as each streaming connection open between the FlexClient | |
| and the streaming endpoints uses a thread on the server. | |
| <max-streaming-clients>10</max-streaming-clients> | |
| --> | |
| <!-- Optional. Default value is 5000. This is the the number of milliseconds | |
| the server will wait before writing a single null byte to the streaming | |
| connection to make sure the client is still available. This is important | |
| to determine when a client is gone so its associated thread on the server | |
| can be cleaned up. Note that this functionality will keep the session alive. | |
| A non-positive value disables this functionality. | |
| <server-to-client-heartbeat-millis>5000</server-to-client-heartbeat-millis> | |
| --> | |
| <!-- Optional. Default is false. If enabled, when the streaming connection is closed for | |
| whatever reason (eg. client is gone), client's associated MessageClient on the server | |
| is invalidated right away. This is useful in scenarios where there's a constant stream | |
| of messages, the client is gone, the streaming connection is closed, but the session | |
| has not timed out on the server yet. In that case, enabling this property will prevent | |
| messages accumulating on the session on behalf of the MessageClient that will invalidate. | |
| Important: You should not enable this property when reliable messaging is used, otherwise | |
| reliable reconnect attempts will not happen correctly. | |
| <invalidate-messageclient-on-streaming-close>false</invalidate-messageclient-on-streaming-close> | |
| --> | |
| <!-- Optional. Default values are as shown. User agents are used to customize | |
| a long-polling or streaming endpoints for specific browsers. Long-polling | |
| and streaming endpoints require persistent HTTP connections which are | |
| limited differently by different browsers per session. | |
| A single long-poll connection requires two browser HTTP connections in | |
| order to send data in both directions. One for the streamed response from the server | |
| to the client that the channel hangs on to, and a second transient connection, drawn | |
| from the browser pool only when data needs to be sent to the server and this second | |
| transient connection is then immediately released back to the browser's connection pool. | |
| In order for client applications to function properly, the number of HTTP connections | |
| made by all clients running in the same session (keep in mind that clients running in | |
| separate browser windows can share the same HTTP session) needs to stay within the limit | |
| established by the browser. The max-persistent-connections-per-session setting is used to | |
| limit the number of long-polling or streaming connections that can be made from clients | |
| in the same browser session. | |
| The special match string "*" will define a default to be used if no string matches. | |
| The match strings "MSIE" and "Firefox" are always defined and must be specified | |
| here explicitly to override the default settings, specifying "*" does not do so. | |
| If you are using streaming channels, you should configure both the streaming and polling | |
| channels to the same values. | |
| --> | |
| <user-agent-settings> | |
| <!-- MSIE 5, 6, 7 limit is 2. | |
| <user-agent match-on="MSIE" max-persistent-connections-per-session="1" kickstart-bytes="2048"/> | |
| --> | |
| <!-- MSIE 8 limit is 6. | |
| <user-agent match-on="MSIE 8" max-persistent-connections-per-session="5" kickstart-bytes="2048"/> | |
| --> | |
| <!-- Firefox 1, 2 limit is 2. | |
| <user-agent match-on="Firefox" max-persistent-connections-per-session="1"/> | |
| --> | |
| <!-- Firefox 3 limit is 6. | |
| <user-agent match-on="Firefox/3" max-persistent-connections-per-session="5"/> | |
| --> | |
| <!-- Safari 3, 4 limit is 4. | |
| <user-agent match-on="Safari" max-persistent-connections-per-session="3"/> | |
| --> | |
| <!-- Chrome 0, 1, 2 limit is 6. | |
| <user-agent match-on="Chrome" max-persistent-connections-per-session="5"/> | |
| --> | |
| <!-- Opera 7, 9 limit is 4. | |
| <user-agent match-on="Opera" max-persistent-connections-per-session="3"/> | |
| --> | |
| <!-- Opera 8 limit is 8. | |
| <user-agent match-on="Opera 8" max-persistent-connections-per-session="7"/> | |
| --> | |
| <!-- Opera 10 limit is 8. | |
| <user-agent match-on="Opera 10" max-persistent-connections-per-session="7"/> | |
| --> | |
| </user-agent-settings> | |
| <!-- Optional. If enabled, when a disconnect message is received from a | |
| client channel the corresponding server session will be invalidated. | |
| If the client is closed without first disconnecting its channel, no | |
| disconnect message is sent and the server session will invalidate | |
| after its idle timeout has elapsed. | |
| This is disabled by default. | |
| <invalidate-session-on-disconnect>true</invalidate-session-on-disconnect> | |
| --> | |
| <!-- Optional. Use this to limit the client channel's connect attempt | |
| to the specified time interval. This is especially important if | |
| the streaming channel is going through proxy servers. | |
| <connect-timeout-seconds>5</connect-timeout-seconds> | |
| --> | |
| </properties> | |
| </channel-definition> | |
| <!-- You can use the HTTP and secure HTTP channels to connect to the HTTP endpoint, which | |
| supports HTTP requests and responses. These channels use a text-based (XML) message format. | |
| This channel definition also uses the remote attribute which can be used to mark the endpoint | |
| as remote. In that case, the endpoint is not started on this server and it is assumed that | |
| the client will connect to a remote symmetric endpoint on another server. This is useful when | |
| the client is compiled against this configuration but some of the endpoints live on a remote server. | |
| --> | |
| <channel-definition id="my-http" class="mx.messaging.channels.HTTPChannel" remote="false"> | |
| <endpoint url="http://{server.name}:{server.port}/{context.root}/messagebroker/http" class="flex.messaging.endpoints.HTTPEndpoint"/> | |
| <properties> | |
| <!-- Optional piggybacking setting. Enable to support piggybacking queued messaging | |
| and data management subscription data along with responses to any messages the | |
| client sends to the server over this channel. --> | |
| <piggybacking-enabled>true</piggybacking-enabled> | |
| <!-- Optional. If enabled, when a disconnect message is received from a | |
| client channel the corresponding server session will be invalidated. | |
| If the client is closed without first disconnecting its channel, no | |
| disconnect message is sent and the server session will invalidate | |
| after its idle timeout has elapsed. | |
| This is disabled by default. | |
| <invalidate-session-on-disconnect>true</invalidate-session-on-disconnect> | |
| --> | |
| <!-- Optional. Client load balancing can be used to randomly distribute client connections across available LCDS servers | |
| in the absence of a load balancer. Client applications compiled against an endpoint configuration with client-load-balancing | |
| will use this set of URLs for connectivity rather than the url specified for the endpoint. The endpoint URL value | |
| will not be compiled into the swf. Before the client initially connects, it will shuffle this full set of URLS and assign | |
| one at random as the primary URL for its Channel and assign the remainder to the failoverURIs property on its Channel. | |
| <client-load-balancing> | |
| <url>http://edge1.adobe.com:1935</url> | |
| <url>http://edge2.adobe.com:1935</url> | |
| <url>http://edge3.adobe.com:1935</url> | |
| </client-load-balancing> | |
| --> | |
| <!-- Optional. Adds specified headers to the HTTP response. The only exception is that access control headers (Access-Control-*) | |
| are sent only if there is an Origin header in the request. | |
| <http-response-headers> | |
| <header>CustomHeader1: Value1</header> | |
| <header>CustomerHeader2: Value2</header> | |
| </http-response-headers> | |
| --> | |
| </properties> | |
| </channel-definition> | |
| <!-- HTTPS based channels can use the {server.port} token as a SWF | |
| must be loaded via a secure URL in order to make secure | |
| connections. | |
| --> | |
| <channel-definition id="my-secure-http" class="mx.messaging.channels.SecureHTTPChannel"> | |
| <endpoint url="https://{server.name}:{server.port}/{context.root}/messagebroker/httpsecure" class="flex.messaging.endpoints.SecureHTTPEndpoint"/> | |
| <properties> | |
| <!--HTTPS requests on some browsers do not work when pragma "no-cache" are set--> | |
| <add-no-cache-headers>false</add-no-cache-headers> | |
| </properties> | |
| </channel-definition> | |
| <!-- A polling HTTP channel, similar to polling AMF channels. | |
| --> | |
| <channel-definition id="my-polling-http" class="mx.messaging.channels.HTTPChannel"> | |
| <endpoint url="http://{server.name}:{server.port}/{context.root}/messagebroker/httppolling" class="flex.messaging.endpoints.HTTPEndpoint"/> | |
| <properties> | |
| <polling-enabled>true</polling-enabled> | |
| <polling-interval-millis>2000</polling-interval-millis> | |
| </properties> | |
| </channel-definition> | |
| <!-- | |
| Channels may be broken in to their own file | |
| To collect multiple channel-definitions in a single file, wrap them in a <channels> tag | |
| --> | |
| <channel-include file-path="my-channel.xml"/> | |
| <!-- This will include all *.xml files in the directory 'my-constraints'. --> | |
| <channel-include directory-path="my-channels"/> | |
| </channels> | |
| <logging> | |
| <!-- | |
| Configuration for server-side logging | |
| target class possible values: | |
| flex.messaging.log.ConsoleTarget - logs to System.out | |
| flex.messaging.log.ServletLogTarget - logs to the servlet logger | |
| level possible values: None|Fatal|Error|Warn|Info|Debug|All | |
| NOTE: Debug level logging should not be used in production environment | |
| for performance and security reasons (it can contain sensitive information | |
| such as username and password). | |
| --> | |
| <target class="flex.messaging.log.ConsoleTarget" level="Error"> | |
| <properties> | |
| <prefix>[BlazeDS] </prefix> | |
| <includeDate>false</includeDate> | |
| <includeTime>false</includeTime> | |
| <includeLevel>false</includeLevel> | |
| <includeCategory>false</includeCategory> | |
| </properties> | |
| <filters> | |
| <!-- | |
| Possible values: | |
| Client.* | |
| Client.FlexClient | |
| Client.MessageClient | |
| Configuration | |
| Endpoint.* | |
| Endpoint.General | |
| Endpoint.AMF | |
| Endpoint.FlexSession | |
| Endpoint.HTTP | |
| Endpoint.Type | |
| Message.* | |
| Message.General | |
| Message.Command.* | |
| Message.Command.(operation-name) | |
| where operation-name is one of subscribe, unsubscribe, poll, poll_interval, client_sync, | |
| server_ping, client_ping, cluster_request, login, logout | |
| Message.coldfusion | |
| Message.Remoting | |
| Message.RPC | |
| Message.Selector | |
| Message.Timing | |
| Resource | |
| Protocol.* | |
| Service.* | |
| Service.Cluster | |
| Service.HTTP | |
| Service.Message | |
| Service.Message.* | |
| Service.Message.JMS | |
| Service.Remoting | |
| Security | |
| Startup.* | |
| Startup.MessageBroker | |
| Startup.Service | |
| Startup.Destination | |
| Timeout | |
| --> | |
| <pattern>Endpoint.*</pattern> | |
| <pattern>Service.*</pattern> | |
| <pattern>Configuration</pattern> | |
| </filters> | |
| </target> | |
| <!-- For security reasons you may want to exclude the printing of | |
| of the property values of certain property names such as "password". | |
| List all such property names in th exclude-properties section --> | |
| <properties> | |
| <exclude-properties> | |
| <property>oldPassword</property> | |
| <property>password</property> | |
| </exclude-properties> | |
| </properties> | |
| </logging> | |
| <!-- | |
| BlazeDS software cluster definition. | |
| To enable this feature, jgroups.jar should be copied from {blazeds_install}/resources/clustering | |
| folder to WEB-INF/lib folder. And, jgroups-default.xml and/or jgroups-tcp.xml should be copied from | |
| {blazeds_install}/resources/clustering folder to WEB-INF/flex folder. | |
| --> | |
| <clusters> | |
| <cluster id="default-cluster" properties="jgroups-default.xml"> | |
| <properties> | |
| <!-- Optional. Properties that can be set on the JGroups channel, | |
| namely Channel.BLOCK, Channel.AUTO_GETSTATE, Channel.AUTO_RECONNECT, | |
| and Channel.LOCAL. Consult the JGroups documentation for details. | |
| <channel-block>false</channel-block> | |
| <channel-auto-getstate>false</channel-auto-getstate> | |
| <channel-auto-reconnect>false</channel-auto-reconnect> | |
| <channel-local>false</channel-local> | |
| --> | |
| </properties> | |
| </cluster> | |
| <cluster id="another-cluster" properties="jgroups-tcp.xml" /> | |
| <!-- | |
| This tag defines a cluster which is enabled by default and disables the url-load-balancing. | |
| By default when you use a cluster in BlazeDS, it gathers the endpoint URLs from all servers | |
| and sends them to the clients so the clients can implement failover between servers with | |
| different domain names. If you are using HW load balancing for HTTP and RTMP connections | |
| you can disable this logic by setting url-load-balancing=false. In this mode, the client | |
| connects to each channel using the same URL and the load balancer routes you to an | |
| available server. When url-load-balancing is true (the default), you cannot use | |
| {server.name} and {server.port} tokens in your URLs. Instead, you must specify the | |
| unique server name and port clients will use to reach each server in that server's configuration. | |
| --> | |
| <!-- <cluster id="default-cluster" properties="jgroups-tcp.xml" default="true" url-load-balancing="false"> --> | |
| </clusters> | |
| <system> | |
| <!-- | |
| Optional. Default is false. When a destination is accessed over a channel, MessageBroker validates | |
| that the destination accepts requests over that channel. However, this validation can be disabled by | |
| the client if the client has a null id for its channel. When this setting is true, MessageBroker | |
| performs the endpoint validation, even if the client channel has a null id. | |
| --> | |
| <enforce-endpoint-validation>false</enforce-endpoint-validation> | |
| <!-- | |
| Support for localization of server-side fault messages. | |
| If the resource in the specified default locale is not available, the default system locale will | |
| be used, otherwise, a core set of error messages in US English is used. | |
| --> | |
| <locale> | |
| <default-locale>en</default-locale> | |
| </locale> | |
| <!-- | |
| Optional. Default is true. Determines whether MessageBroker is manageable or not. | |
| --> | |
| <manageable>true</manageable> | |
| <!-- | |
| Support for web application redeploy when configuration files are updated. | |
| This works with the J2EE appplication server web application redeployment. | |
| The watch-file and touch-file must start with {context.root} or be an absolute path. | |
| The touch-file is the file used by your application server to force web redeployment. | |
| Check the application server to confirm what the touch-file should be. | |
| --> | |
| <redeploy> | |
| <enabled>true</enabled> | |
| <watch-interval>20</watch-interval> | |
| <watch-file>{context.root}/WEB-INF/flex/services-config.xml</watch-file> | |
| <watch-file>{context.root}/WEB-INF/flex/proxy-config.xml</watch-file> | |
| <watch-file>{context.root}/WEB-INF/flex/remoting-config.xml</watch-file> | |
| <watch-file>{context.root}/WEB-INF/flex/messaging-config.xml</watch-file> | |
| <touch-file>{context.root}/WEB-INF/web.xml</touch-file> | |
| </redeploy> | |
| <!-- | |
| Optional. By default MessageBroker uses UUIDUtils#createUUID to generate | |
| NIO-HTTP session cookie value and FlexClient id generation. One can implement | |
| UUIDGenerator interface and reference it from here to get MessageBroker use | |
| that custom UUID generator for NIO-HTTP session cookie and FlexClient id values. | |
| --> | |
| <uuid-generator class="my.company.MyUUIDGenerator"/> | |
| </system> | |
| <flex-client> | |
| <!-- | |
| Optional setting that is applied to SWFs compiled against this services-config.xml | |
| file that controls whether the client application will issue periodic heartbeat | |
| requests to the server to keep an idle connection alive and to detect loss of | |
| connectivity. | |
| The default value of 0 disables this functionality. | |
| If the application sets this value it should prefer a longer rather than | |
| shorter interval, to avoid placing unnecessary load on the remote host. | |
| As an illustrative example, low-level TCP socket keep-alives generally | |
| default to an interval of 2 hours. That is a longer interval than most | |
| applications that enable heartbeats will likely want to use, but it serves | |
| as a clear precedent to prefer a longer interval over a shorter interval. | |
| --> | |
| <!-- <heartbeat-interval-millis>0</heartbeat-interval-millis> --> | |
| <!-- | |
| Each Flex application that connects to the server triggers the creation of a | |
| FlexClient instance that represents the remote client application. If timeout-minutes | |
| is left undefined or set to 0, FlexClient instances on the server are shutdown once | |
| all associated FlexSessions (corresponding to connections between the client and server) | |
| are shutdown. | |
| If this value is defined, FlexClient instances will be kept alive for this amount of | |
| idle time. Only define this for applications that use HTTP-based channels (which are not | |
| scoped to a specific client swf) where you want to aggressively clean up idle FlexClient | |
| instances but the client browser will continue to interact with the server and prevent | |
| the HttpSession from timing out. | |
| --> | |
| <!-- <timeout-minutes>5</timeout-minutes> --> | |
| </flex-client> | |
| <!-- | |
| Message filters are registered with the Message broker and provide the opportunity | |
| to pre-process incoming messages and post-process reply messages and pushed messages. | |
| Message filters are expected to implement flex.messaging.filters.MessageFilter interface, | |
| and they can be chained. | |
| --> | |
| <message-filters> | |
| <message-filter class="my.company.filters.TestFilter"/> | |
| <message-filter class="my.company.filters.SecondaryTestFilter"/> | |
| </message-filters> | |
| <!-- | |
| A deserialization validator is registered with the Message broker and provides | |
| the opportunity to validate the creation of classes and the assignment of a property | |
| of an instance to a value for incoming (client-to-server) deserialization. A deserialization | |
| validator is expected to implement the flex.messaging.validators.DeserializationValidator | |
| interface, and only one deserialization validator can be set per MessageBroker. | |
| The flex.messaging.validators.ClassDeserializationValidator is provided as the default | |
| implementation. | |
| --> | |
| <validators> | |
| <!-- | |
| Default implementation of DeserializationValidator that supports | |
| allow and disallow classes. | |
| --> | |
| <validator class="flex.messaging.validators.ClassDeserializationValidator"> | |
| <properties> | |
| <!-- Explicitly disallow the following classes/packages. Note that if any packages/classes | |
| are in the allow list, all other classes/packages will be dissalowed. --> | |
| <disallow-classes> | |
| <class name="my.secret1.CustomerClass"/> | |
| <class name="my.secret2.*"/> | |
| </disallow-classes> | |
| <!-- Allow the following classes/packages --> | |
| <allow-classes> | |
| <!-- Any custom types that are sent between the client and the server should | |
| be included here. --> | |
| <class name="my.public1.CustomerClass"/> | |
| <class name="my.public2.*"/> | |
| <!-- The following classes/packages are used internally by BlazeDS/LCDS and | |
| are allowed by default unless explicitly disallowed. Note that disallowing | |
| any of these packages/classes may results in errors during deserialization. | |
| <class name="flex.data.*"/> | |
| <class name="flex.messaging.**"/> | |
| <class name="java.lang.Boolean"/> | |
| <class name="java.lang.Byte"/> | |
| <class name="java.lang.Double"/> | |
| <class name="java.lang.Float"/> | |
| <class name="java.lang.Integer"/> | |
| <class name="java.lang.Long"/> | |
| <class name="java.lang.Object"/> | |
| <class name="java.lang.Short"/> | |
| <class name="java.lang.String"/> | |
| <class name="java.io.Externalizable"/> | |
| <class name="java.util.*"/> | |
| <class name="org.w3c.dom.Document"/> | |
| <class name="\[B"/> | |
| <class name="\[Ljava.lang.Object;"/> | |
| --> | |
| </allow-classes> | |
| </properties> | |
| </validator> | |
| <!-- | |
| A custom implementation of DeserializationValidator. | |
| <validator class="my.company.validators.TestDeserializationValidator"/> | |
| --> | |
| </validators> | |
| </services-config> |