This chapter provides instructions for changing the default behavior of the Coherence REST implementation.
This chapter includes the following sections:
Custom providers and resources can be created as required. This section demonstrates how to register custom providers, and how to override Coherence's default root resource.
The com.tangosol.coherence.rest.server.DefaultResourceConfig class supports package scanning, which can be used to register custom providers or resources. The following example demonstrates registering a custom provider and resource using package scanning:
public class MyResourceConfig extends DefaultResourceConfig
{
public MyResourceConfig()
{
super("com.my.providers;com.my.resources");
}
}
As an alternative, the following example demonstrates how to override one or more of the register methods defined in the DefaultResourceConfig class in order to use custom providers, a custom root resource, or to add filters and filter factories.
Note:
Never override (unregister) Coherence default Providers without overriding the root resource class as well (the DefaultRootResource class depends on the default providers to provide the necessary dependencies and configuration).
public class MyResourceConfig extends DefaultResourceConfig
{
protected void registerRootResource()
{
// remove if you don't want Coherence defaults to be registered
super.registerRootResource();
getClasses().add(MyRootResource.class);
}
protected void registerProviders()
{
// remove if you don't want Coherence defaults to be registered
super.registerProviders();
getSingletons().add(new MyProvider());
}
protected void registerContainerRequestFilters()
{
// remove if you don't want Coherencedefaults to be registered
super.registerContainerRequestFilters();
getContainerRequestFilters().add(new MyRequestFilter());
}
protected void registerContainerResponseFilters()
{
// remove if you don't want Coherence defaults to be registered
super.registerContainerResponseFilters();
getContainerResponseFilters().add(new MyResponseFilter());
}
protected void registerResourceFilterFactories()
{
// remove if you don't want Coherence defaults to be registered
super.registerResourceFilterFactories();
getResourceFilterFactories().add(new MyResourceFilterFactory());
}
}
Custom resource configuration class are enabled in the cache configuration file by adding the fully qualified name of the class using the <resource-config> element within an HTTP acceptor configuration. The class is mapped to a specific context path. For example:
<proxy-scheme>
<service-name>ExtendHttpProxyService</service-name>
<acceptor-config>
<http-acceptor>
...
<resource-config>
<context-path>/MyApplicationContext</context-path>
<instance>
<class-name>package.MyResourceConfig</class-name>
</instance>
</resource-config>
</http-acceptor>
</acceptor-config>
<autostart>true</autostart>
</proxy-scheme>
The default context path (/) is used if no context path is provided. Multiple resource configuration class definitions can be added and mapped to different context paths.
Coherence REST uses Oracle's lightweight HTTP server by default to handle requests. However, the implementation is not recommended for production environments and is typically used during development and testing. As an alternative, Coherence includes a Grizzly HTTP server implementation and the Simple HTTP server can be used as well. Refer to the Jersey documentation for instructions on integrating additional HTTP servers, which are beyond the scope of this documentation.
The following topics are included in this section:
Coherence REST provides a Grizzly 2 HTTP server implementation (com.tangosol.coherence.rest.server.GrizzlyHttpServer) that can be used instead of the default HTTP server. For more information on the Grizzly HTTP server see:
The Grizzly server is enabled in the cache configuration file by adding the fully qualified name of the implementation as a value of the <class-name> element within an HTTP acceptor configuration. For example:
<proxy-scheme>
<service-name>ExtendHttpProxyService</service-name>
<acceptor-config>
<http-acceptor>
<class-name>com.tangosol.coherence.rest.server.GrizzlyHttpServer
</class-name>
...
</http-acceptor>
</acceptor-config>
<autostart>true</autostart>
</proxy-scheme>
The Simple framework can be used as an embedded HTTP server since it's supported within Jersey. For more information on the Simple framework see:
http://www.simpleframework.org/
To use the Simple framework as an embedded HTTP server, extend the com.tangosol.coherence.rest.server.AbstractHttpServer class and then enable the class in the cache configuration file.
The following example creates a SimpleHttpServer class:
public class SimpleHttpServer extends AbstractHttpServer
{
public void start()
{
Closeable connection = m_connection;
if (connection == null)
{ try
{
connection = SimpleServerFactory.create("http://" +
getLocalAddress() + ":" + getLocalPort(),getResourceConfig());
}
catch (IOException e)
{
throw new WrapperException(e);
}
m_connection = connection;
}
}
public void stop()
{
Closeable connection = m_connection;
if (connection != null)
{
try
{
connection.close();
}
catch (IOException e)
{
throw new WrapperException(e);
}
finally
{
m_connection = null;
}
}
}
protected Closeable m_connection;
}
The SimpleHttpServer class must be enabled in the cache configuration file by adding the fully qualified name as a value of the <class-name> element within an HTTP acceptor configuration. For example:
<proxy-scheme>
<service-name>ExtendHttpProxyService</service-name>
<acceptor-config>
<http-acceptor>
<class-name>package.SimpleHttpServer</class-name>
...
</http-acceptor>
</acceptor-config>
<autostart>true</autostart>
</proxy-scheme>