Clone Tools
  • last updated a few minutes ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Debugging test case that fails on server.

MODE-1211 Changed the NodeTypeSchemata to treat NAME and PATH as STRING

  1. … 6 more files in changeset.
MODE-1211 Changed the NodeTypeSchemata to treat NAME and PATH as STRING

  1. … 6 more files in changeset.
MODE-1162 Added ability to expose repository metadata

After quite a bit of discussion with Brian about possible ways to implement this, we settled upon the following.

GET /

will return information about each of the repositories, and in each will be a new "metadata" value with all of the JCR repository's descriptor key-value pairs. For example:

{

"mode:repository":{

"repository": {

"name":"mode:repository",

"resources":{"workspaces":"<URL>"}

"metadata" : {

"jcr.specification.name" : "Content Repository for Java Technology API",

"jcr.specification.version" : "2.0",

"jcr.repository.name" : "ModeShape JCR Repository",

"jcr.repository.vendor.url" : "http://www.modeshape.org",

"jcr.repository.version" : "2.6.0.FINAL",

"option.versioning.supported" : "true",

... etc. ...

}

}

}

}

Note the addition of the "metadata" section.

The RESTful Client API was changed to support reading these if there, and will populate an immutable Map returned by a new Repository.getMetadata() method. If the metadata is not returned by the server, this map will be empty (but not null).

These changes were made to the codebase, and several unit tests were modified to verify this behavior. The Reference Guide was also updated to reflect this change. All unit and integration tests pass.

  1. … 13 more files in changeset.
MODE-1146 REST Servlet Ignores Servlet Mappings Other Than /*

Attached patch that corrects the way that the REST server produces URIs when querying the server-level resource and the repository-level resource. Higher-level resources are not affected by this issue, because we use relative URIs for node children. The patch remaps the servlet in the tests from /* to /test/* and slightly modifies some test scripts accordingly.

  1. … 4 more files in changeset.
MODE-1130 Corrected how the REST service updates versionable files

Added the test provided by Dan, and added a second test that was very similar (but not versionable). The versionable test failed, as Dan reported.

The REST service was not properly using the JCR 'checkout, modify, save, checkin' pattern. Instead, it was using 'checkout, modify, checkin, save'. Obviously this was wrong.

Once this was fixed (and a few changes were made to do only one session.save even if multiple versionable nodes are updated in one request), the new tests all work fine and all unit and integration tests pass.

  1. … 4 more files in changeset.
MODE-1131 Corrected REST query handling of null values in query results

The QueryHandler logic was always presuming there would be a non-null Value object in all query results. Obviously, this is wrong.

Added unit and integration tests to verify that using the REST API to issue queries where the results do contain null values does indeed result in the same exceptions. This required changing the 'modeshape-web-jcr-rest-war' module's JCR configuration to add initial content (with one node that had no value for an optional property).

Then, corrected the logic to look for null values and not record a value for the column name in the JSON response. Also verified that the JsonRestClient class is properly handling such missing name/value pairs, while still properly containing the name of the columns.

Verified that the new unit and integration tests pass with the fixes. Indeed, all unit and integration tests pass.

  1. … 7 more files in changeset.
MODE-919 Getting a broken pipe exception when publishing the attached DDL file

Applied patch that adds a new, optional query parameter (mode:includeNode) to POSTs of JCR items. If this parameter is passed in with a value that equates to true, then only the path of the new item is returned in the response. If this parameter is not set or is set but does not evalute to true, then the prior behavior of returning a JSON-encoded version of the newly created node is used.

git-svn-id: https://svn.jboss.org/repos/modeshape/branches/2.2.x@2504 76366958-4244-0410-ad5e-bbfabb93f86b

  1. … 4 more files in changeset.
MODE-919 Getting a broken pipe exception when publishing the attached DDL file

Applied patch that adds a new, optional query parameter (mode:includeNode) to POSTs of JCR items. If this parameter is passed in with a value that equates to true, then only the path of the new item is returned in the response. If this parameter is not set or is set but does not evalute to true, then the prior behavior of returning a JSON-encoded version of the newly created node is used.

git-svn-id: https://svn.jboss.org/repos/modeshape/trunk@2503 76366958-4244-0410-ad5e-bbfabb93f86b

  1. … 4 more files in changeset.
MODE-912 changed so that the workspace isnt needed on the url in order to request node types

git-svn-id: https://svn.jboss.org/repos/modeshape/trunk@2488 76366958-4244-0410-ad5e-bbfabb93f86b

  1. … 3 more files in changeset.
MODE-912 changed so that the workspace isnt needed on the url in order to request node types

git-svn-id: https://svn.jboss.org/repos/modeshape/branches/2.2.x@2485 76366958-4244-0410-ad5e-bbfabb93f86b

  1. … 3 more files in changeset.
MODE-919 Adding Van's patch, but currently marked '@Ignore' as the test successfully uploads the file and verifies the file is uploaded, but RESTEasy is logging the error internally.

git-svn-id: https://svn.jboss.org/repos/modeshape/branches/2.2.x@2375 76366958-4244-0410-ad5e-bbfabb93f86b

  1. … 1 more file in changeset.
MODE-919 Adding Van's patch, but currently marked '@Ignore' as the test successfully uploads the file and verifies the file is uploaded, but RESTEasy is logging the error internally.

git-svn-id: https://svn.jboss.org/repos/modeshape/trunk@2374 76366958-4244-0410-ad5e-bbfabb93f86b

  1. … 1 more file in changeset.
MODE-878 One of the major issues was that the REST client library was not properly representing the node types and type inheritance, making it difficult (if not impossible) for the JDBC metadata to properly create the table and column metadata. Also, the mapping of nodes w/ properties to tables w/ columns was slightly incorrect in its handling of residual properties and multi-valued properties (neither of which should not be mapped into columns). This filtering was done in the REST client, but should have instead been done inside the JDBC driver.

The attached patch fixes the REST client's handling node types, adopting the JCR interfaces for node types, property definitions, and child node definitions. This has a couple of advantages: the REST client doesn't need to duplicate the non-trivial interfaces and semantics; and the JDBC driver uses the REST client for remote access and the JCR interfaces for local access, and the same node type interfaces are used in both and fairly significantly simplify the JDBC metadata logic. The only disadvantage is that the JCR API library is now a dependency of the REST client, but it's small and has no other dependencies, so this is not really that bad of a change. The benefits greatly outweigh the disadvantages.

The two methods in the IRestClient interface that deal with node types also didn't really work, and we could not maintain backward compatibility because of a change in the return type. (The existing methods could have been left, but could not have been implemented correctly without duplicating a lot of code.) Therefore, the 'getNodeTypes(...)' method signature was changed to work with the usage of the JCR interfaces and the removal of unnecessary parameters.

Additionally, the 'getNodeType(...)' method that returned a single node type could not functionally work without a lot of effort and potentially numerous remote calls. Because of this, and because the return type needed to be changed and would result in no benefit over the 'getNodeTypes(...)' method, this method was simply removed.

The attached patch also changes the JDBC driver to use the new REST client's 'getNodeTypes' method and the JCR node type interfaces. The former change corrected the fundamental problem reported by this defect, while the latter allowed the REST-oriented mechanism to directly expose the JCR node type interfaces (just like the other mechanisms) and allowed for removal of a lot of code.

The result appears to be that the REST client is now returning accurate and complete representations of the node types, and the JDBC driver is now returning accurate database metadata descriptions of the available tables and columns.

git-svn-id: https://svn.jboss.org/repos/modeshape/branches/2.2.x@2272 76366958-4244-0410-ad5e-bbfabb93f86b

    • -0
    • +97
    ./NodeTypeNodeTest.java
  1. … 21 more files in changeset.
MODE-878 One of the major issues was that the REST client library was not properly representing the node types and type inheritance, making it difficult (if not impossible) for the JDBC metadata to properly create the table and column metadata. Also, the mapping of nodes w/ properties to tables w/ columns was slightly incorrect in its handling of residual properties and multi-valued properties (neither of which should not be mapped into columns). This filtering was done in the REST client, but should have instead been done inside the JDBC driver.

The attached patch fixes the REST client's handling node types, adopting the JCR interfaces for node types, property definitions, and child node definitions. This has a couple of advantages: the REST client doesn't need to duplicate the non-trivial interfaces and semantics; and the JDBC driver uses the REST client for remote access and the JCR interfaces for local access, and the same node type interfaces are used in both and fairly significantly simplify the JDBC metadata logic. The only disadvantage is that the JCR API library is now a dependency of the REST client, but it's small and has no other dependencies, so this is not really that bad of a change. The benefits greatly outweigh the disadvantages.

The two methods in the IRestClient interface that deal with node types also didn't really work, and we could not maintain backward compatibility because of a change in the return type. (The existing methods could have been left, but could not have been implemented correctly without duplicating a lot of code.) Therefore, the 'getNodeTypes(...)' method signature was changed to work with the usage of the JCR interfaces and the removal of unnecessary parameters.

Additionally, the 'getNodeType(...)' method that returned a single node type could not functionally work without a lot of effort and potentially numerous remote calls. Because of this, and because the return type needed to be changed and would result in no benefit over the 'getNodeTypes(...)' method, this method was simply removed.

The attached patch also changes the JDBC driver to use the new REST client's 'getNodeTypes' method and the JCR node type interfaces. The former change corrected the fundamental problem reported by this defect, while the latter allowed the REST-oriented mechanism to directly expose the JCR node type interfaces (just like the other mechanisms) and allowed for removal of a lot of code.

The result appears to be that the REST client is now returning accurate and complete representations of the node types, and the JDBC driver is now returning accurate database metadata descriptions of the available tables and columns.

git-svn-id: https://svn.jboss.org/repos/modeshape/trunk@2271 76366958-4244-0410-ad5e-bbfabb93f86b

    • -0
    • +97
    ./NodeTypeNodeTest.java
  1. … 21 more files in changeset.
MODE-895 Ignored two unit tests that are not working ATM because of problems with Cargo.

git-svn-id: https://svn.jboss.org/repos/modeshape/trunk@2268 76366958-4244-0410-ad5e-bbfabb93f86b

MODE-895 Ignored two unit tests that are not working ATM because of problems with Cargo.

git-svn-id: https://svn.jboss.org/repos/modeshape/branches/2.2.x@2267 76366958-4244-0410-ad5e-bbfabb93f86b

MODE-895 - cleaned up node types dependencies and changed to exclude mixins and multivalued types

git-svn-id: https://svn.jboss.org/repos/modeshape/trunk@2266 76366958-4244-0410-ad5e-bbfabb93f86b

  1. … 4 more files in changeset.
MODE-895 - cleans up adding node type depedences and excludes mixins and multi-value types

git-svn-id: https://svn.jboss.org/repos/modeshape/branches/2.2.x@2261 76366958-4244-0410-ad5e-bbfabb93f86b

  1. … 4 more files in changeset.
MODE-886 The JsonRestClient was not checking the response code, and was always attempting to convert the response into a JSON object -- even with response code other than 200. The fix is to check the response code (as is already being done in other methods), and in the case of a 200 response to build the result or, in the case of any other response code, to throw an exception with the message in the response.

I also took the opportunity to map the javax.jcr.InvalidQueryException into a 402 response (i.e., bad request), which is a little better mapping of what's going wrong.

All unit and integration tests pass with these changes.

git-svn-id: https://svn.jboss.org/repos/modeshape/branches/2.2.x@2260 76366958-4244-0410-ad5e-bbfabb93f86b

  1. … 6 more files in changeset.
MODE-886 The JsonRestClient was not checking the response code, and was always attempting to convert the response into a JSON object -- even with response code other than 200. The fix is to check the response code (as is already being done in other methods), and in the case of a 200 response to build the result or, in the case of any other response code, to throw an exception with the message in the response.

I also took the opportunity to map the javax.jcr.InvalidQueryException into a 402 response (i.e., bad request), which is a little better mapping of what's going wrong.

All unit and integration tests pass with these changes.

git-svn-id: https://svn.jboss.org/repos/modeshape/trunk@2259 76366958-4244-0410-ad5e-bbfabb93f86b

  1. … 6 more files in changeset.
MODE-681 - changes to the rest client to expose the Node Types to the jdbc driver.

git-svn-id: https://svn.jboss.org/repos/modeshape/trunk@2144 76366958-4244-0410-ad5e-bbfabb93f86b

  1. … 20 more files in changeset.
MODE-806 RESTful server should allow queries to be executed

Applied a patch that adds a new URI pattern (/<context root>/<repository name>/<workspace name>/query) for query support. Users can execute a query by POSTing a request to that URI with the unencoded query in the body of the message and a content type that specifies which language to use. The REST server will then execute that query in the workspace described by the URI.

The query results will be returned as a JSON-encoded object with two properties: types, which maps the column names in the query results to their JCR type, and rows, which contains a JSON-encoded array of rows. Each element in the rows array corresponds to a single row in the query results and each element is a JSON object that maps column names to their value for that particular row. The types property relies on ModeShape-specific functionality and will not contain any mappings if the REST server is configured to use another JCR implementation.

This patch also updates the REST client to add a new query method that returns a list of QueryRow objects. Each QueryRow provides a collection of column names in the row, the t value for a named column, and the type for a named column. The type of the column will always be null if a JCR implementation other than ModeShape is used.

This patch includes Randall's suggestion to perform case-insensitive compares in the JsonRestClient when determining the query language.

git-svn-id: https://svn.jboss.org/repos/modeshape/trunk@2075 76366958-4244-0410-ad5e-bbfabb93f86b

  1. … 25 more files in changeset.
MODE-785 - reviewed by Dan, checking in the changes from the patch: modeshape-web-jcr-rest-client.patch. This removes the hardcoded "resources" context.

git-svn-id: https://svn.jboss.org/repos/modeshape/trunk@1912 76366958-4244-0410-ad5e-bbfabb93f86b

  1. … 6 more files in changeset.
MODE-734 Alter port used for web project tests

Modifed modeshape-web-jcr-rest-client module to use port 8090 as well.

git-svn-id: https://svn.jboss.org/repos/modeshape/trunk@1774 76366958-4244-0410-ad5e-bbfabb93f86b

  1. … 1 more file in changeset.
MODE-580 Applied Brian's patch, though there were several difficulties doing so (so I had to resort to apply bits of the patch and a few changes by hand). All seems to be okay, and all tests do pass. I was able to run the JDBC metadata connector unit and integration tests from the command line and from within Eclipse.

git-svn-id: https://svn.jboss.org/repos/modeshape/trunk@1604 76366958-4244-0410-ad5e-bbfabb93f86b

  1. … 55 more files in changeset.
Merge branch 'mode-580'

git-svn-id: https://svn.jboss.org/repos/modeshape/trunk@1602 76366958-4244-0410-ad5e-bbfabb93f86b

  1. … 8 more files in changeset.
DNA-580 Rebranded all of the codebase, changing from 'JBoss DNA' to 'ModeShape'. For details about the procedure, see DNA-580. The rebranding is not yet complete with this commit, but at this point all modules have been renamed, all package names have been adjusted, all references to 'DNA' (in the various forms) have been changed, and all of the unit tests and integration tests do pass. The remaining work involves fixing a small number of issues (table names used by the JPA connector models, one TCK failure that has been commented out that apparently was uncovered by the node type names and prefixes were changes) that still have to be fixed. Also, I've not verified much of the Getting Started or Reference Guides (though these were changed automatically by my scripts). In short, there still is work to do before we release something.

git-svn-id: https://svn.jboss.org/repos/modeshape/trunk@1596 76366958-4244-0410-ad5e-bbfabb93f86b

    • -0
    • +207
    ./JsonRestClientTest.java
  1. … 3504 more files in changeset.