graniteds.orgCommunity Documentation

Chapter 17. Configuration Reference

17.1. Framework Configuration
17.2. Application Configuration
17.2.1. Channels
17.2.2. Factories
17.2.3. Remoting destinations
17.2.4. Messaging destinations

The two main files used to configure GraniteDS are granite-config.xml and services-config.xml. By default these files should be present in the web archive in WEB-INF/granite/granite-config.xml and WEB-INF/flex/services-config.xml.

If absolutely needed, they can be placed in another location, but then you will have to specify two servlet parameters in web.xml to indicate GraniteDS where to look for them: 




<context-param>

    <param-name>servicesConfigPath</param-name>

    <param-value>/WEB-INF/flex/services-config.xml</param-value>

</context-param>

<context-param>

    <param-name>graniteConfigPath</param-name>

    <param-value>/WEB-INF/granite/granite-config.xml</param-value>

</context-param>

    

17.1. Framework Configuration

granite-config.xml contains all the internal configuration of the framework. It can contain the following sections:

17.2. Application Configuration

services-config.xml contains all the remoting and messaging configuration of the application. There are three main sections: channels, factories and services.

A channel definition mostly contains the endpoint url and the client channel implementation: 




<channels>

    <channel-definition id="my-graniteamf" class="mx.messaging.channels.AMFChannel">

        <endpoint

            uri="http://{server.name}:{server.port}/{context.root}/graniteamf/amf"

            class="flex.messaging.endpoints.AMFEndpoint"/>

    </channel-definition>

</channels>

            

GraniteDS provides 4 implementations of the Flex Channel:

A factory defines a way to tell GraniteDS how to route incoming remoting calls to a server component. A factory should implement org.granite.messaging.service.ServiceFactory. The factory definition can also have configuration options in the section properties: 




<factory id="myFactory" class="com.myapp.custom.MyServiceFactory">

    <properties>

        <service-exception-handler>com.myapp.custom.MyServiceExceptionHandler</service-exception-handler>

        <enable-exception-logging>true<enable-exception-logging>

    </properties>

</factory>

            

service-exception-handler: an exception handler should implement org.granite.messaging.service.ServiceExceptionHandler and will be called when an exception is thrown by the remote service. The default is DefaultServiceExceptionHandler for standard factories and ExtendedServiceExceptionHandler for Tide factories.

enable-exception-logging: enables (true) or disable (false) the logging of exceptions thrown by remote services. This can avoid double logging if the server application already logs everything. Default is true.

Other properties exist for the built-in service factories. You will get more details in the corresponding sections. For example EJB3 factories have a lookup and initial-context-environment properties.

Remoting destinations can be defined in a service definition with the class property value flex.messaging.services.RemotingService and the messageTypes value flex.messaging.messages.RemotingMessage. Destinations can also have a properties section and in general they will define at least the factory and the channels they are attached to. 




<services>

  <service

    id="granite-service"

    class="flex.messaging.services.RemotingService"

    messageTypes="flex.messaging.messages.RemotingMessage">

    <destination id="cars">

      <channels>

        <channel ref="my-graniteamf"/>

      </channels>

      <properties>

        <factory>guiceFactory</factory>

        <source>test.granite.guice.services.Cars</source>

      </properties>

    </destination>

  </service>

</services>

            

You can define multiple channels for the same destination to handle failover. Wwhen the first channel cannot be accessed, the remote object will try the next one in the list.

The property source is often used to determine the target component and its value depend on the server framework. In this example with Guice this is the class name of the target bean.

A destination can also define a list of security roles that are allowed to access the remote component. See Remoting security.

Messaging destinations can be defined in a service definition with the class property value flex.messaging.services.MessagingService and the messageTypes value flex.messaging.messages.AsyncMessage. Destinations can also have a properties section that is used for example with the JMS adapter.

A messaging service can also define a list of service adapters that define how messages are routed and each destination can reference one of the configured adapters. 




<service id="gravity-service"

    class="flex.messaging.services.MessagingService"

    messageTypes="flex.messaging.messages.AsyncMessage">

    <adapters>

        <adapter-definition id="simple" class="org.granite.gravity.adapters.SimpleServiceAdapter"/>

        <!--adapter-definition id="jms" class="org.granite.gravity.adapters.JMSServiceAdapter"/-->

    </adapters>



    <destination id="addressBookTopic">

        <properties>

          <!--jms>

            <destination-type>Topic</destination-type>

            <connection-factory>ConnectionFactory</connection-factory>

            <destination-jndi-name>topic/testTopic</destination-jndi-name>

            <destination-name>dataTopic</destination-name>

            <acknowledge-mode>AUTO_ACKNOWLEDGE</acknowledge-mode>

            <transacted-sessions>true</transacted-sessions>

            <no-local>true</no-local>

          </jms-->

          <no-local>true</no-local>

          <session-selector>true</session-selector>

        </properties>

        <channels>

            <channel ref="gravityamf"/>

        </channels>

        <adapter ref="simple"/>

        <!--adapter ref="jms"/-->

    </destination>

</service>

            

You can define multiple channels for the same destination to handle failover. When the first channel cannot be accessed, the remote object will try the next one in the list.

A destination can also define a list of security roles that are allowed to access the remote component. See Messaging Security.