[MGNLREST-138] Cannot decorate the delivery endpoint Created: 30/Oct/17 Updated: 04/Dec/17 Resolved: 14/Nov/17 |
|
| Status: | Closed |
| Project: | Magnolia REST Framework |
| Component/s: | None |
| Affects Version/s: | 2.0 |
| Fix Version/s: | 2.0 |
| Type: | Bug | Priority: | Critical |
| Reporter: | Christopher Zimmermann | Assignee: | Mikaël Geljić |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | 0d | ||
| Time Spent: | 1d 7h | ||
| Original Estimate: | 4.5h | ||
| Attachments: |
|
||||||||||||||||
| Issue Links: |
|
||||||||||||||||
| Template: |
|
||||||||||||||||
| Acceptance criteria: |
Empty
|
||||||||||||||||
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
||||||||||||||||
| Bug DoR: |
[ ]*
Steps to reproduce, expected, and actual results filled
[ ]*
Affected version filled
|
||||||||||||||||
| Date of First Response: | |||||||||||||||||
| Epic Link: | REST Queries | ||||||||||||||||
| Sprint: | Saigon 120, Saigon 121, Saigon 122 | ||||||||||||||||
| Story Points: | 5 | ||||||||||||||||
| Description |
|
Attempts to decorate the delivery endpoint fail. Attempted configuration: Original config in module "rest-test":
class: info.magnolia.rest.delivery.jcr.v1.JcrDeliveryEndpointDefinition
params:
contacts:
workspace: contacts
nodeTypes:
0: mgnl:contact
# tours:
# workspace: tours
Attempt at decoration:
params:
tours:
workspace: tours
(See attachment for full configuration) Results in
Note: If I wrap the nodetypes in the original with quotes, then the definitions app displays the endpoint properly and I can expand it, there are no problems in the problems view, but the actual requests still fail with exceptions. |
| Comments |
| Comment by Christoph Meier [ 31/Oct/17 ] |
|
My findings are the followings: #1 You can decorate the endpoint, but you have to restart the server to make sure the endpoint is aware of the changes. #2 The endpoint-definition as known in the definitions-app gets properly updated when decorating - without a restart. #3 The decorating module (example-name: adapt-rest) should define a module dependency to the module with the endpoint-definition.yaml (example-module-name: define-rest) otherwise decoration may be applied or not (during start-up). Conclusion: The endpoint must read the endpoint-definition from the registry to make sure it always gets the latest state. |
| Comment by Christoph Meier [ 31/Oct/17 ] |
|
I have a "work-around" on a branch on my fork Since I inject EndpointDefinitionRegistry instead of extending AbstractEndpoint, constructor has changed - which also leads to changes on JcrDeliveryEndpointTest - which I have not done so far and which is fully commented atm. :-| Somebody else must decide whether my workaround could be a tmp.-solution for 2.0. I am unsure whether the issue can be fixed - without reading from the registry. |
| Comment by Christopher Zimmermann [ 01/Nov/17 ] |
|
I can confirm that after a restart my decoration is picked up!
(So the actual endpoint behaviour is out of sync with what is reflected in the definitions app.) |
| Comment by Mikaël Geljić [ 09/Nov/17 ] |
Unrelated issue in decoration—regular YamlReader doesn't seem to have any issue with numeral keys. Meanwhile quote your key or use the list syntax as the key is irrelevant anyway. |