As a customer I can expose custom web service using configuration
(MGNLREST-14)
|
|
| Status: | Closed |
| Project: | Magnolia REST Framework |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 1.0 |
| Type: | Sub-task | Priority: | Neutral |
| Reporter: | Tobias Mattsson | Assignee: | Philip Mundt |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Template: |
|
| Sprint: | 5.2-rc1 |
| Description |
|
We're using this pattern extensively, for instance in TemplateDefinitionRegistry where the registry maps ids to providers. Observing the JCR configuration and registering whats configured there is done by ConfiguredTemplateDefinitionManager. Note that it calls unregisterAndRegister to not clear the registry and not leave anything in the registry that has been removed in JCR. |
| Comments |
| Comment by Tobias Mattsson [ 24/Oct/13 ] |
|
ConfiguredEndpointDefinition should be enabled by default ConfiguredEndpointDefinitionManager needs to be more tolerant to incomplete configurations, i.e. must not fail if there's a node without the required properties, the reload can happen while the user is not done configuring EndpointDefinition should allow specifying the class that implements the service. RepositoryEndpoint and CommandEndpoint should not extend ConfiguredEndpointDefinition, they should instead be referenced in the definition this way. Instantiating the service should be using the component provider and passing the definition to make it available for injection. |