graniteds.orgCommunity Documentation

Chapter 13. Configuration Reference

13.1. Framework Configuration
13.2. Application Configuration
13.2.1. Factories
13.2.2. Remoting destinations
13.2.3. 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>

    

13.1. Framework Configuration

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

13.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 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>

            

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.