This design is intended to address the following issues:
KNOX-195@jira: Simple way to introduce new service without requiring code
The basic issue is that the development and delivery of code is currently required to add a new Service into Knox.
This results in a barrier to entry for integrating new services with Knox.
The design below is intended to introduce a very simple configuration based mechanism to accomplish this.
Naturally this will only cover very simple use-cases.
More advanced requirements will still require the development of a ServiceDeploymentContributor.
A topology file sketch containing a use of the "default" service.
<topology> ... <service> <role>...</role> <name>generic</name> <url>...</url> <param> <name>pattern</name> <value>custom/v1/**?**</value> </param> <param> <name>rewrite</name> <value>custom-rewrite-rules.xml</value> </param> </service> </topology>
Note: Something isn't quite right with the above. Basically I'd prefer if there were a way to specify a chain per pattern but this doesn't support that.
public class DefaultServiceDeploymentContributor { String getRole() { return "*"; // The "*" will require special handling in the framework. String getName() { return "generic"; } void initializeContribution( DeploymentContext context ) { // NoOp } void contributeService( DeploymentContext context, Service service ) throws Exception { ResourceDescriptor resource = context.getGatewayDescriptor().addResource(); resource.role( service.getRole() ); resource.pattern( service.getParam( "pattern" ); UrlRewriteRulesDescriptor serviceRules = loadRules( service.getParam( "rewrite" ) ); UrlRewriteRulesDescriptor clusterRules = context.getDescriptor( "rewrite" ); clusterRules.addRules( serviceRules ); } // Called after all contributors and before provider finalizeContribution methods. void finalizeContribution( DeploymentContext context ) { // NoOp } }