graniteds.orgCommunity Documentation

Chapter 3. Project Setup

3.1. Server libraries
3.2. Configuring web.xml
3.3. Framework configuration
3.4. Application configuration
3.5. Client libraries
3.6. Developing with Maven

GraniteDS consists in a set of client libraries and a set of server libraries. It is designed to be deployed in a Java application server and packaged in a standard Java Web application, either as a WAR file or as an EAR file. The configuration of a GraniteDS project will generally involve the following steps :

  1. Add the GraniteDS jars to the WEB-INF/lib folder of the WAR file or the lib folder of the EAR file

  2. Add the GraniteDS listener, servlets and filters in the standard WEB-INF/web.xml configuration file

  3. Define the internal configuration of GraniteDS in the WEB-INF/granite/granite-config.xml file

  4. Define the application configuration of GraniteDS (remoting destinations, messaging topics...) in the WEB-INF/flex/services-config.xml

  5. Build you Java client project with the GraniteDS libraries

Depending on which framework and application server you use on the server (Spring, Seam...) and on the client, some of these steps may be completely omitted, or implemented differently. For example, when using the Spring framework on the server, almost all the configuration can be defined in the standard Spring context instead of the granite-config.xml and services-config.xml files. GraniteDS tries to be as transparent and integrated as possible with the application environment, however it can be useful to know how things work at the lower level if you have specific requirements.

The GraniteDS jars are available from the build folder of the distribution. You will always need granite.jar. Additionally you will have to include the jar corresponding to your server framework (granite-spring.jar for Spring for example), the jar for your JPA provider (granite-hibernate.jar for Hibernate) and the granite-beanvalidation.jar if you want to benefit from the integration with the Bean Validation API on the server.

At the most basic level, GraniteDS is implemented as a servlet (in fact a servlet and a filter) and thus has to be configured in web.xml. Here is a typical code snippet that maps the GraniteDS AMF servlet to /graniteamf/*. Of course it's possible to define a different URL mapping if required. It is also highly recommended to also add the configuration listener that will release resources on application undeployment.



<listener>
    <listener-class>org.granite.config.GraniteConfigListener</listener-class>
</listener>

<filter>
    <filter-name>AMFMessageFilter</filter-name>
    <filter-class>org.granite.messaging.webapp.AMFMessageFilter</filter-class>
</filter>
<filter-mapping>
    <filter-name>AMFMessageFilter</filter-name>
    <url-pattern>/graniteamf/*</url-pattern>
</filter-mapping>

<servlet>
    <servlet-name>AMFMessageServlet</servlet-name>
    <servlet-class>org.granite.messaging.webapp.AMFMessageServlet</servlet-class>
    <load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
    <servlet-name>AMFMessageServlet</servlet-name>
    <url-pattern>/graniteamf/*</url-pattern>
</servlet-mapping>
        

The configuration of the various GraniteDS parts is done in the file WEB-INF/granite/granite-config.xml. There are many options that can be defined here, you can refer to the configuration reference.

As a starting point, you can create an empty file :



<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE granite-config PUBLIC "-//Granite Data Services//DTD granite-config internal//EN"
    "http://www.graniteds.org/public/dtd/3.0.0/granite-config.dtd">

<granite-config/>
        

Or much easier a configuration that will use class scanning to determine the default setup.



<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE granite-config PUBLIC "-//Granite Data Services//DTD granite-config internal//EN"
    "http://www.graniteds.org/public/dtd/3.0.0/granite-config.dtd">

<granite-config scan="true"/>
        

The last thing to define on the server is the application configuration in WEB-INF/flex/services-config.xml. This is for example the place where you will define which elements of your application you will expose to GraniteDS remoting, or the topic for messaging. You can refer to the configuration reference for more details.

For example a simple configuration for an EJB 3 service would look like :



<services-config>
    <services>
        <service id="granite-service"
            class="flex.messaging.services.RemotingService"
            messageTypes="flex.messaging.messages.RemotingMessage">

            <destination id="example">
                <channels>
                    <channel ref="graniteamf"/>
                </channels>
                <properties>
                    <factory>ejbFactory</factory>
                </properties>
            </destination>
        </service>
    </services>

    <factories>
        <factory id="ejbFactory" class="org.granite.messaging.service.EjbServiceFactory">
            <properties>
                <lookup>myapp/{capitalized.destination.id}ServiceBean/local</lookup>
            </properties>
        </factory>
    </factories>

    <channels>
        <channel-definition id="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>
</services-config>
        

This configuration file declares 3 differents things, let's list them in the reverse order :

  • Channel endpoint : this defines the uri on which the remote service can be accessed though GraniteDS remoting. This should match the servlet url mapping defined previously in web.xml.

  • Service factories : here the configuration defines an EJB 3 factory, meaning that destinations using this factory will route incoming remote calls to EJB 3. GraniteDS provides factories for all popular server frameworks. Most factories require specific properties, here for example the JNDI format for EJB lookup.

  • Service/destinations : this section defines a remoting service (described by its class and message type) and one destination interpreted as an EJB 3 as indicated by the factory property.

Depending on the kind of framework integration that is used, the services-config.xml file may not be necessary and can be omitted. With Spring and Seam for example, everything can be defined in the respective framework configuration files instead of services-config.xml.

GraniteDS comes with 3 client jar libraries. First granite-client.jar, a stripped down version of the core granite.jar that includes the minimal core of GraniteDS. Then granite-java-client.jar that includes the Java client library, and finally granite-javafx-client.jar that contains the specific integration for JavaFX.

The GraniteDS client also depends on the small class scanning library extcos. For remoting and Comet, the GraniteDS client requires the Apache Asynchronous HTTP client, and for WebSocket, the Jetty WebSocket client. All these jars can be found in the libs folder of the Java client distribution.

You simply have to add the necessary GraniteDS jars and dependencies to your application classpath.

Maven is a popular build tool. Though GraniteDS is not itself built with Maven, its artifacts are available in the Maven central repository and can thus be easily added as dependencies to any Maven project.

The Java dependencies for the server application are in the group org.graniteds.



<dependency>
    <groupId>org.graniteds</groupId>
    <artifactId>granite-core</artifactId>
    <version>${graniteds.version}</version>
    <type>jar</type>
</dependency>

<dependency>
    <groupId>org.graniteds</groupId>
    <artifactId>granite-hibernate</artifactId>
    <version>${graniteds.version}</version>
    <type>jar</type>
</dependency>

...
        

The dependencies for the Java client application are as follows:



<dependency>
    <groupId>org.graniteds</groupId>
    <artifactId>granite-client</artifactId>
    <version>${graniteds.version}</version>
    <type>jar</type>
</dependency>

<dependency>
    <groupId>org.graniteds</groupId>
    <artifactId>granite-java-client</artifactId>
    <version>${graniteds.version}</version>
    <type>jar</type>
</dependency>

<!-- Only for JavaFX integration -->
<dependency>
    <groupId>org.graniteds</groupId>
    <artifactId>granite-javafx-client</artifactId>
    <version>${graniteds.version}</version>
    <type>jar</type>
</dependency>

<!-- Default dependencies -->
<dependency>
    <groupId>net.sf.extcos</groupId>
    <artifactId>extcos</artifactId>
    <version>0.3b</version>
    <type>jar</type>
</dependency>

<!-- Apache HTTP client dependencies (remoting, Comet) -->
<dependency>
    <groupId>org.apache.httpcomponents</groupId>
    <artifactId>httpasyncclient</artifactId>
    <version>4.0-beta1</version>
    <type>jar</type>
</dependency>

<!-- Jetty WebSocket client dependencies (WebSocket) -->
<dependency>
    <groupId>org.eclipse.jetty</groupId>
    <artifactId>jetty-client</artifactId>
    <version>8.1.5.v20120716</version>
    <type>jar</type>
</dependency>
<dependency>
    <groupId>org.eclipse.jetty</groupId>
    <artifactId>jetty-websocket</artifactId>
    <version>8.1.5.v20120716</version>
    <type>jar</type>
</dependency>