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. For production environments, Coherence includes implementations for the Grizzly HTTP server, the Simple HTTP server, and the Jetty HTTP server. These servers are supported in Jersey. 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>
Coherence REST provides a Simple HTTP server implementation (com.tangosol.coherence.rest.server.SimpleHttpServer) that can be used instead of the default HTTP server. For more information on the Simple framework see:
http://www.simpleframework.org/
The Simple HTTP 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.SimpleHttpServer
</class-name>
...
</http-acceptor>
</acceptor-config>
<autostart>true</autostart>
</proxy-scheme>
Coherence REST provides a Jetty HTTP server implementation (com.tangosol.coherence.rest.server.JettyHttpServer) that can be used instead of the default HTTP server. For more information on the Jetty HTTP server, see:
The Jetty 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.JettyHttpServer
</class-name>
...
</http-acceptor>
</acceptor-config>
<autostart>true</autostart>
</proxy-scheme>