Clone Tools
  • last updated a few minutes ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
MODE-1416 - Updated the rest server to produce not only application/json but also text/plain and text/html, based on the Accept header of the request. Clients which rely on the old (default application/json behavior) should specify the Accept header in the request.

    • -170
    • +0
    ./modeshape/web/jcr/rest/client/MockRestClient.java
  1. … 14 more files in changeset.
MODE-872 - Added back into build cycle & fixed tests for web-jcr-rest-client module.

The following were updated

- cargo plugin version and general cargo usage has been refactored: the parent pom defines & configures the default cargo plugin while the child modules only use that configuration

- the cargo plugin & configuration have been updated to work with the latest version of the plugin & Jetty has been upgraded to 7x

- the JcrResources web service, on the @Delete method, does not need the @Consumed annotation

  1. … 21 more files in changeset.
MODE-1288 Fixed uses of the interfaces/methods that were removed

Some other code was using the interfaces that Horian removed. This change fixes those.

  1. … 7 more files in changeset.
MODE-1262 Temporary fix to unpublish the file published in the test. This patch needs to be removed when the problem is resovled

MODE-1262 Temporary fix to unpublish the file published in the test. This patch needs to be removed when the problem is resovled

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-1142 Corrected the use of @Override

The 'modeshape-jcr', 'modeshape-jcr-api' and 'modeshape-graph' modules are now compiled with JDK 1.5 (see MODE-1108), so the @Override annotations need to be removed from that code. All of the remaining modules use JDK 6, and thus need to use @Override in all places (including interfaces).

  1. … 242 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-1099 Added ability for clients to publish files as being versioned

Previously, the REST client API would publish as file by creating an "nt:file" node

with the standard properties and "jcr:content" child node, but would never create nodes that

were versionable. This change adds a method to the IRestClient interface that allows a client

to specify whether the published file should be versioned, in which case the "mix:versionable"

mixin is added to the "nt:file" node's list of "jcr:mixinTypes".

    • -0
    • +14
    ./modeshape/web/jcr/rest/client/MockRestClient.java
  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/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. … 2 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. … 2 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 Ahem, the unit tests fail on Hudson (which is in a different time zone) due to time conversion problems. The conversion from PropertyType.DATE types to long, double, and BigDecimal values did not first convert the date into UTC.

Stupid java.util.Calendar and java.util.Date! The latter does not have the notion of a time zone, so SimpleDateFormat.parse(String) always converts the date to the current time zone, which messes everything up.

After quite a bit of time spent trying to get Java's Date and Calendar classes to work, I punted and added a dependency on JodaTime. The library is not really that big, plus the parsing and conversion logic is now the same as what's used in our JCR implementation. I also manually verified the expected milliseconds used in the unit tests, and they appear to be correct (and in UTC). The unit and integration tests pass locally, and hopefully they'll pass on Hudson.

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

  1. … 2 more files in changeset.
MODE-878 Ahem, the unit tests fail on Hudson (which is in a different time zone) due to time conversion problems. The conversion from PropertyType.DATE types to long, double, and BigDecimal values did not first convert the date into UTC.

Stupid java.util.Calendar and java.util.Date! The latter does not have the notion of a time zone, so SimpleDateFormat.parse(String) always converts the date to the current time zone, which messes everything up.

After quite a bit of time spent trying to get Java's Date and Calendar classes to work, I punted and added a dependency on JodaTime. The library is not really that big, plus the parsing and conversion logic is now the same as what's used in our JCR implementation. I also manually verified the expected milliseconds used in the unit tests, and they appear to be correct (and in UTC). The unit and integration tests pass locally, and hopefully they'll pass on Hudson.

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

  1. … 2 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/branches/2.2.x@2272 76366958-4244-0410-ad5e-bbfabb93f86b

    • -20
    • +3
    ./modeshape/web/jcr/rest/client/MockRestClient.java
    • -0
    • +97
    ./modeshape/web/jcr/rest/client/json/NodeTypeNodeTest.java
  1. … 17 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

    • -20
    • +3
    ./modeshape/web/jcr/rest/client/MockRestClient.java
    • -0
    • +97
    ./modeshape/web/jcr/rest/client/json/NodeTypeNodeTest.java
  1. … 17 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. … 2 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. … 2 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.