Clone Tools
  • last updated a few minutes ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
MODE-2185 Removed the ModeShape REST client (modeshape-web-jcr-rest-client module). The functionality required by the remote JDBC Driver was moved to the modeshape-jdbc package and a new, lightweight client created which only performs the functionality required by the driver.

    • -299
    • +0
    ./client/domain/PropertyDefinitionTest.java
    • -82
    • +0
    ./client/domain/RepositoryTest.java
    • -577
    • +0
    ./client/json/JsonRestClientTest.java
    • -136
    • +0
    ./client/json/NodeTypeNodeTest.java
  1. … 72 more files in changeset.
MODE-2218 Corrected the REST client's methods that obtain the node types. This fixes the JDBC driver DatabaseMetaData methods, too.

    • -7
    • +54
    ./client/json/NodeTypeNodeTest.java
  1. … 2 more files in changeset.
MODE-2218 Corrected the REST client's methods that obtain the node types. This fixes the JDBC driver DatabaseMetaData methods, too.

    • -7
    • +54
    ./client/json/NodeTypeNodeTest.java
  1. … 2 more files in changeset.
MODE-2097, MODE-2169, MODE-2197 Integrated the latest version of the jboss-integration BOM. This commit includes changes for multiple different issues that snowballed: - packaging Javadocs in a zip - updating Apache POI In addition, after integrating the BOM a number of unit tests had to be updated to reflect changes in dependencies both from a functionality perspective and from a deprecation perspective. The most significant change there was the rewriting of the ConnectorTestCase (modeshape-jca) because the new versions of Arquillian + IronJacamar hold filelocks on Windows: https://issues.jboss.org/browse/JBJCA-1027

  1. … 93 more files in changeset.
MODE-2150 Implemented a boolean constraint checker.

  1. … 2 more files in changeset.
MODE-2150 Implemented a boolean constraint checker.

  1. … 2 more files in changeset.
MODE-2148 Added checkstyle to our build, and corrected numerous potential problems or issues in the code. Also removed lots of meaningless JavaDoc

  1. … 366 more files in changeset.
MODE-2081 Changed the license for ModeShape code to ASL 2.0.

    • -18
    • +10
    ./client/RestClientI18nTest.java
    • -18
    • +10
    ./client/domain/NodeTypeTest.java
    • -18
    • +10
    ./client/domain/PropertyDefinitionTest.java
    • -18
    • +10
    ./client/domain/RepositoryTest.java
    • -18
    • +10
    ./client/domain/WorkspaceTest.java
    • -18
    • +10
    ./client/json/JsonRestClientTest.java
    • -18
    • +10
    ./client/json/NodeTypeNodeTest.java
  1. … 550 more files in changeset.
Fixed tests which assert repository version (was 3.x is now 4.x).

  1. … 1 more file in changeset.
MODE-1710 Corrected compiler warnings

    • -13
    • +15
    ./client/json/JsonRestClientTest.java
  1. … 5 more files in changeset.
MODE-1919 Updated the IRestClient interface with 2 methods which allow to mark & unmark a folder as a publish area.

    • -7
    • +140
    ./client/json/JsonRestClientTest.java
  1. … 11 more files in changeset.
MODE-1619 Corrected JavaDoc warnings/errors

    • -10
    • +11
    ./client/json/JsonRestClientTest.java
  1. … 3 more files in changeset.
MODE-1619 - Added a new method on the IRestClient interface, which checks the existence of a file on the server Also, fixed the log4j appender pattern for some of the test modules.

    • -9
    • +29
    ./client/json/JsonRestClientTest.java
  1. … 8 more files in changeset.
MODE-1646 REST client can now be used to talk to 3.x and 2.x servers

Because of the improvements/changes in the RESTful API in 3.0, using the REST client required using slightly

different URLs to talk to 3.x vs 2.x servers. The reason is that the REST client still uses the older REST API,

and the URL for the older API is different on 3.x servers.

Although it was not feasible to transparently and automatically discover the correct URL given the actual server

the client talks to, it was possible to add a new method that does this. There is now a "validate(Server):Server"

method on the IRestClient interface, and this method can be used to validate a Server instance with a normal

URL (that is, excluding the API version qualifier) based upon the actual server. The method returns a new

Server instance that should be used for all subsequent communications.

Note that clients that don't take advantage of this new method can still work, as long as the URL ends with "/v1" for

3.x servers.

    • -40
    • +51
    ./client/json/JsonRestClientTest.java
  1. … 5 more files in changeset.
MODE-1639, MODE-1640, MODE-1634 Replaced the Aperture-based MIME type detector with a Tika-based one

This required quite a bit of dependency gymnastics, since Tika has quite a few more transitive

dependencies than the Aperture library (which we had successfully pared down several years ago).

Tika references about 25 dependencies (including transitive dependencies), but this was reduced

in 'modeshape-jcr' to about 8 for basic MIME type detection. Note that Tika usually includes

two BouncyCastle libraries in its dependencies (used for encrypted PDFs, among other things),

but ModeShape intentionally excludes these (as we don't want to ship or depend on any

security-related JARs).

Not only do we get Tika's substantial MIME type database, we've made it possible for users

to edit the 'org/modeshape/custom-mimetypes.xml' file and provide the updated one on the application

classpath. What goes in that file will overwrite all of the other sources (namely Tika's built-in

file and its customization file, both of which are to be found on the classpath), which means

it's easiest to simply provide an updated version of this file at 'org/modeshape/custom-mimetypes.xml'.

Be sure to not remove any of the (few) customizations that ModeShape includes - those are important.

As we upgrade Tika, we'll get updated versions of the media type data. This is far more preferable

than having a ModeShape-specific version.

The MIME type related interfaces in ModeShape's public API (e.g., 'modeshape-jcr-api') have been removed.

These were added sometime in one of the 3.0 releases, so removing them will not introduce compatibility

issues for users.

Instead, we've decided to get out of the MIME type detection framework business, and have decided

to switch to Tika for all MIME type detection. In fact, you can still write your own MIME type detector,

but you do that by implementing Tika's interface and reference the implementation class(es) in the

corresponding service loader file in your JAR. (See the TIKA documentation for details.)

However, internally we still have an abstraction. This is because it is possible to remove the Tika

(and transitive dependencies) from a ModeShape installation, as long as your applications will not

expect any kind of automatic MIME type detection. This is a perfectly valid use case: for example,

using a repository to store data and do not store files (and don't use sequencers).

The AS7 kits required a bit more modification. There is now a new AS7 module for 'org.apache.tika'

that contains all of the JARs, and this is used by the ModeShape module and by the Tika text extractor

module.

All unit and integration tests pass with these changes. Several new tests were added.

  1. … 70 more files in changeset.
MODE-1583 - Implemented functionality for bulk creating/updating/deleting of nodes

  1. … 10 more files in changeset.
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.

  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

    • -35
    • +17
    ./client/json/JsonRestClientTest.java
  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.

    • -16
    • +14
    ./client/json/JsonRestClientTest.java
  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

    • -12
    • +52
    ./client/json/JsonRestClientTest.java
MODE-1262 Temporary fix to unpublish the file published in the test. This patch needs to be removed when the problem is resovled

    • -15
    • +54
    ./client/json/JsonRestClientTest.java
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
    • +11
    ./client/json/JsonRestClientTest.java
  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.

    • -4
    • +72
    ./client/json/JsonRestClientTest.java
  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.

    • -0
    • +32
    ./client/json/JsonRestClientTest.java
  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".

  1. … 4 more files in changeset.