ModeShape

Clone Tools
  • last updated a few minutes ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Changed version numbers to reflect current build requirements.

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

    • -1
    • +1
    /extensions/modeshape-clustering/pom.xml
  1. … 37 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

  1. … 8 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

  1. … 8 more files in changeset.
MODE-901 changed to use hibernate 3.2.2

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

MODE-873: Changed log level for discovery to debug

git-svn-id: https://svn.jboss.org/repos/modeshape/trunk@2269 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/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

MODE-895 - Changed so that tables with no columns are returned by the databasemetadata.getTables call.

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

Added 'dependencyManagement' section to the 'modeshape-sequencer-java' project's pom.xml to overcome the hellishness that are version ranges as used within the org.eclipse artifacts.

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

Added 'dependencyManagement' section to the 'modeshape-sequencer-java' project's pom.xml to overcome the hellishness that are version ranges as used within the org.eclipse artifacts.

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

MODE-891 - changed to not return tables that have no columns.

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

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

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

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

Corrected version of 'modeshape-jcr-tck' module

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

Corrected version of 'modeshape-jcr-tck' module

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

MODE-892 Changed the CndNodeTypeReader and the JackrabbitXmlNodeTypeReader methods to try more things when resolving files given a string path. The code used to just look on the classpath, and even then just using getClass().getResourceAsStream() method (meaning absolute paths with a leading '/' were treated as absolute paths, but relative paths without a leading '/' were considered relative to the 'org.modeshape.jcr' package).

These methods now attempt to resolve the string path into an InputStream as follows:

1) Using the ClassLoader returned from the ExecutionContext.getClassLoader(), attempt to resolve using ClassLoader.getResourceAsStream(path); or

2) Using the reader's getClass() method, attempt to resolve using Class.getResourceAsStream(path); or

3) Using the ClassLoader from the reader's Class, attempt to resolve using ClassLoader.getResourceAsStream(path); or

4) Create a java.io.File with the supplied (absolute or relative) path, and return a FileInputStream if the file exists and is readable; or

5) Create a java.net.URL with the supplied path, and (if not malformed) return the stream resulting from URL.openStream(); or

6) throw an IOException

The first InputStream returned from these methods is then passed to the reader's 'read(InputStream)' method. This logic is actually encapsulated in IoUtil.getResourceAsStream(String).

Several additional unit tests were added for the CndNodeTypeReader and the JackrabbitXmlNodeTypeReader. Some of these verified that files could be found using the various path formats, while others verified that an IOException is now thrown if none of these resolve to a valid InputStream.

Additionally, JcrEngine was changed to use the same IoUtil.getResourceAsStream() to load the CND files referenced in the configuration files.

Interestingly, this change uncovered an error in the ModeShape repository configuration used in the unit tests in 'modeshape-jdbc', as that configuration was specifying CND files that did not exist. (Likely, this was a copy-and-paste error.) This configuration file was corrected.

The Reference Guide was also updated to describe the additional ways in which ModeShape now resolves CND files referenced in the configuration file.

All unit and integration tests pass with these changes, and they were committed into SVN on 'trunk' in r2255 and on the '2.2.x' branch in r2256.

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

MODE-892 Changed the CndNodeTypeReader and the JackrabbitXmlNodeTypeReader methods to try more things when resolving files given a string path. The code used to just look on the classpath, and even then just using getClass().getResourceAsStream() method (meaning absolute paths with a leading '/' were treated as absolute paths, but relative paths without a leading '/' were considered relative to the 'org.modeshape.jcr' package).

These methods now attempt to resolve the string path into an InputStream as follows:

1) Using the ClassLoader returned from the ExecutionContext.getClassLoader(), attempt to resolve using ClassLoader.getResourceAsStream(path); or

2) Using the reader's getClass() method, attempt to resolve using Class.getResourceAsStream(path); or

3) Using the ClassLoader from the reader's Class, attempt to resolve using ClassLoader.getResourceAsStream(path); or

4) Create a java.io.File with the supplied (absolute or relative) path, and return a FileInputStream if the file exists and is readable; or

5) Create a java.net.URL with the supplied path, and (if not malformed) return the stream resulting from URL.openStream(); or

6) throw an IOException

The first InputStream returned from these methods is then passed to the reader's 'read(InputStream)' method. This logic is actually encapsulated in IoUtil.getResourceAsStream(String).

Several additional unit tests were added for the CndNodeTypeReader and the JackrabbitXmlNodeTypeReader. Some of these verified that files could be found using the various path formats, while others verified that an IOException is now thrown if none of these resolve to a valid InputStream.

Additionally, JcrEngine was changed to use the same IoUtil.getResourceAsStream() to load the CND files referenced in the configuration files.

Interestingly, this change uncovered an error in the ModeShape repository configuration used in the unit tests in 'modeshape-jdbc', as that configuration was specifying CND files that did not exist. (Likely, this was a copy-and-paste error.) This configuration file was corrected.

The Reference Guide was also updated to describe the additional ways in which ModeShape now resolves CND files referenced in the configuration file.

All unit and integration tests pass with these changes, and they were committed into SVN on 'trunk' in r2255 and on the '2.2.x' branch in r2256.

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

MODE-894 Corrected the Reference Guide to use the correct 'SYSTEM_SOURCE_NAME' option in Section 8.2.

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

MODE-894 Corrected the Reference Guide to use the correct 'SYSTEM_SOURCE_NAME' option in Section 8.2.

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

MODE-893 Several minor changes were needed outside of MapTransaction. One change was required in Processor to grab the original location of a node before it was moved, and Repository was changed to cache the WorkspaceType instances in the map (rather than creating them each time). This last change apparently fixed a previously-unknown issue with the JCR TCK runs against Infinispan, in that the otherWorkspace no longer needed to be predefined.

All unit and integration tests pass with these changes.

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

MODE-893 Several minor changes were needed outside of MapTransaction. One change was required in Processor to grab the original location of a node before it was moved, and Repository was changed to cache the WorkspaceType instances in the map (rather than creating them each time). This last change apparently fixed a previously-unknown issue with the JCR TCK runs against Infinispan, in that the otherWorkspace no longer needed to be predefined.

All unit and integration tests pass with these changes.

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

MODE-885 It turns out that our log4j.properties file included DEBUG as the default logging level, and was not something that should have been committed. This fix changes the default level to INFO in the 'modeshape-web-jcr-rest-war' and 'modeshape-web-jcr-webdav-war' modules, and unit tests show there is no longer debug-level logging occurring.

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

MODE-885 It turns out that our log4j.properties file included DEBUG as the default logging level, and was not something that should have been committed. This fix changes the default level to INFO in the 'modeshape-web-jcr-rest-war' and 'modeshape-web-jcr-webdav-war' modules, and unit tests show there is no longer debug-level logging occurring.

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

MODE-889 Added two unit tests to confirm the recent change is indeed working.

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

Merge branch 'mode-889'

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

MODE-890 The problem turned out to be the irritating 'javax.jcr.Node.getName()' method that does not include the SNS index. A simple correction to ModeShapeWebdavStore in the 'modeshape-web-jcr-webdav' module fixes the problem my adding the '[snsIndex]' to the name for all nodes that have a SNS index > 1.

All unit and integration tests pass.

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

MODE-890 The problem turned out to be the irritating 'javax.jcr.Node.getName()' method that does not include the SNS index. A simple correction to ModeShapeWebdavStore in the 'modeshape-web-jcr-webdav' module fixes the problem my adding the '[snsIndex]' to the name for all nodes that have a SNS index > 1.

All unit and integration tests pass.

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

MODE-889 The problem turned out to be the irritating 'javax.jcr.Node.getName()' method that does not include the SNS index. A simple correction to ItemHandler in the REST service module fixes the problem my adding the '[snsIndex]' to the name for all nodes that have a SNS index > 1. All unit and integration tests pass.

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