[ https://jira.jboss.org/jira/browse/DNA-312?page=com.atlassian.jira.plugin... ] Randall Hauch updated DNA-312: ------------------------------ Fix Version/s: 0.5 Targeting to the next release (currently named 0.5) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/DNA-312?page=com.atlassian.jira.plugin... ] Brian Carothers updated DNA-312: -------------------------------- Attachment: DNA-312_for_review.patch Attaching a preliminary patch for review that provides most of the required functionality for the JSON-encoding of a DNA RESTful server (as I understand the requirements), albeit with big holes around PUT support (easy to add), JAAS integration (easy to add poorly), bulk operations over disjoint trees (pretty darn hard to add), and general ease-of-configuration (easy to add). I am throwing this out there in the hopes that it can pass a sanity check from someone else. In lieu of a design document, here are the supported URI patterns, relative to the servlet context in which the WAR is installed. All results are JSON-encoded. / - GET - returns the list of JCR repositories on the server. Example Response (GET - 200): {"JCR%20Repository": {"repository": { "name": "JCR%20Repository", "resources": {"workspaces": "\/resources\/JCR%20Repository"} }}} Note that the response includes a RESTful link to the available resources within the returned repository. /{repositoryName} - GET - returns the list of available workspaces under the given repository. Example Response (GET - 200): {"%3cdefault%3e": {"workspace": { "name": "%3cdefault%3e", "resources": {"items": "\/resources\/JCR%20Repository\/%3cdefault%3e\/items"} }}} Note again the RESTful link to the available resources under the workspace. This could quickly be expanded to support REST-based locking/unlocking and lookup by UUID. Note too the redundant return of the workspace name ("<default>" as URL-encoded). This could easily be changed to return a simple array of workspaces instead of a mapping from the workspace name to the workspace information if that is the desired API. /{repositoryName}/{workspaceName}/items/{path} - GET, POST, DELETE, PUT (future) - reads, inserts, or removes the item at the given path respectively. Example Response (GET - 200): { "properties": {"jcr:primaryType": "dna:system"}, "children": {"dna:namespaces": { "properties": {"jcr:primaryType": "dna:namespaces"}, "children": [ "jcr", "mix", "nt", "dna", "xsd", "sv", "xml", "xmlns", "xsi", "dnaint" ] }} } Note the encoding format - each node contains a hash of properties and a either a hash of nested child nodes or an array of child node names. I had considered having a single for all child items of a node, but there needed to be a way to discriminate between properties and child nodes that have the same name. The example above used the query parameter dna:depth=1 to indicate that one level of child nodes below the requested node should also be returned. Example Request Body (POST) { "properties": { "jcr:primaryType": "nt:unstructured", "testProperty": "testValue", "multiValuedProperty": [ "value1", "value2" ] }, "children": {"childNode": {"properties": {"nestedProperty": "nestedValue"}}} } Example Response (POST - 201) { "properties": { "testProperty": "testValue", "jcr:primaryType": "nt:unstructured", "multiValuedProperty": [ "value1", "value2" ] }, "children": {"childNode": {"properties": { "nestedProperty": "nestedValue", "jcr:primaryType": "nt:unstructured" }}} } Note that the response includes the nested nodes that were created as well as the parent. Note also how the jcr:primaryType property was filled in for the nested child node. Since no primary type was specified for the child node in the request, Session.addNode(String) was called internally and the default primary type was used. Example Reponse Body (DELETE - 204) Deletes do not return a response. A successful delete can be determined by a 204 (NO CONTENT) response code. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/DNA-312?page=com.atlassian.jira.plugin... ] Brian Carothers updated DNA-312: -------------------------------- Attachment: DNA-312_final_review.patch Same as previous patch, except for: - PUT item implemented - SPI created for repository providers, allowing this service to be used with other JCR providers with a minimum of coding - Split into two projects - dna-web-jcr-rest provides a JAR with all of the required classes. dna-web-jcr-rest-war wraps the jar with a war and provides in-container testing. The idea behind the split was to give users the option of either deploying our existing default settings, or changing the configuration by adding one class , modifying the web.xml, and warring that with the existing JAR. This way, we're never telling users that step N of the install process is to crack one of our wars open and edit a file inside. - Exception handling cleaned up - getAvailableWorkspaces removed from JcrRepository - existing JcrWorkspace.getAvaliableWorkspaceNames used instead - Minor cleanup and commenting If no one objects tomorrow, I'll commit this and close down all of the subtasks under DNA-55 except for the documentation/examples/tutorial subtask and will either add a new task or a new subtask to DNA-55 to capture that security is currently hardcoded in this implementation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira