Added support in the file system connector for handling 'mix:referenceable' nodes and correctly handling the 'jcr:uuid' property. The connector still does not handle finding nodes by identifier (e.g., UUID). Also changed the JcrSession (and associated classes) to better handle looking up nodes by identifier if the connector doesn't support doing so. In such cases, the JcrSession performs a query to search for the path of the node given the UUID, and then looks up the node by path. Note that when the referenceable nodes are still in the session's transient state, the session is now able to find them without resorting to the connector or queries. A new integration test case was added to test for this functionality. Prior to the above fixes, this test case failed (as expected); after the above fixes, the test case passes. All unit and integration tests pass.
Several changes were made to improve the startup time of the ModeShape engine and Repository instances, especially when starting up after the first shutdown. The JPA connector was improved to eliminate a dual-connection startup mode that attempted to discover the model before establishing the actual connection. This will have a noticeable impact when starting up with 'autoGenerateSchema' properties of 'update' or 'validate', since before this change both connection phases performed the update and/or validation. Now that there is only a single connection phase, the update and/or validation will only be performed once. This change also improves the process of reading the existing node types during JcrRepository startup. Prior to this change, the existing node types were read from the '/jcr:system' area and the built-ins were always loaded from a CND on the classpath, replacing any "incorrect" or "invalid" built-in node type that was stored in '/jcr:system'. Now, the existing node types are read from the '/jcr:system' area and used as is, without overwriting the built-ins. This was thought to better accept any existing node types configured by the user, and will perhaps come into play when a user upgrades from 2.x to 3.x (assuming there are changes to the built-ins). As a result, users will be responsible for updating the built-in node types using the standard NodeTypeManager.registerNodeTypes(…) methods. Several automated and manual integration tests were modified before these changes to allow better measurement of the startup times. Some test utility methods (e.g., simulation of Guvnor activities) were refactored so they could be more easily used in multiple (kinds of) tests. All unit and integration tests pass with these changes, and a full build (e.g., "mvn install -Pintegration") appears to take 1 minute less.
Added a new chapter in the Reference Guide that describes the ModeShape RHQ plugin.
HSQL will be used because it is the default database/datasource used in JBoss AS
I've finally replicated the problem and identified a fix. Normally when restarting the engine reads the node types from the system store, and these node types are usually in a specific order. Somehow, the node types are reordered so that the built-ins are not first in the list, and when registering these the built-ins (often "nt:unstructured" or "nt:base") are not able to be resolved. Fixing the ordering won't help with existing installations, so instead I chose to change RepositoryNodeTypeManager to be more tolerant of the order of the node types by simply iterating multiple times through the list and only failing when no more node types can be successfully registered. In addition to the change to RepositoryNodeTypeManager, the bulk of the rest of the changes are new (manual) integration tests that are successful at replicating the problem. (Note that I was not able to replicate the problem when restarting the engine while in the same process - only when restarting ModeShape in a separate VM.) All unit and integration tests pass, as does the new manual test.
…nfiguration The fix was quite simple, and involved how the configuration graph is being processed when instantiating and setting up the JcrRepository instance. All unit and integration tests pass.
The logic of restoring a versioned node was not properly handling nodes below the versioned node - it was ignoring the 'jcr:mixinTypes' and 'jcr:uuid' properties. This change corrects that behavior to properly set these properties. Note that while testing a fix, a case involving storing 'mix:versionable' nodes was found to not really be addressed by the JCR 2.0 specification. After some investigation, the reference implementation appears to use 'nt:frozenNode' for all nodes underneath a Version. This definitely works around the issue, so the ModeShape behavior was reverted (from MODE-1172) back to doing the same thing. The code is backward compatible for old version histories using node types other than nt:frozenNode (other than the 'mix:referenceable' issue). Several tests were added to verify the problematic scenarios, and after the change all unit and integration tests pass. Similar tests using the reference implementation were added to the 'modeshape-test-reference-impl' module in the sandbox.
…c driver jar The common utilities were originally moved into the jdbc driver, thinking that the jdbc driver would not need common-core. This commit reverts that, making the jdbc driver depend on common-core and eliminating the duplicate classes from the jdbc driver.
…deprecated the class. And removed ChangeLogEntity from being added to the EntityManagerFactory in HibernateAdapter.getEntityManagerFactory(JpaSource) method
Several tests were modified to check for additional information, namely that the Session.getUserID() returns the correct value after authenticating with various configuration. All tests continue to pass.
Updated the Drools CNDs used in the integration tests. Also added a new integration test that: 1) starts a new engine (using a disk-based JPA source), 2) loads the Drools node types, 3) gets all of the available node types (which would include the built-ins plus the Drools node types) 4) shuts down the engine 5) starts up a new engine (using the same disk-based JPA source), 6) gets all of the available node types (which would include the built-ins plus the Drools node types) 7) compares the node types from step 3 and step 6, making sure that the node types match The test case does not fail. Furthermore, based upon the information in this defect, we should be getting an error in step 5, and we are not. Still committing this new test case.
…oss AS 5.1 Fixed default cacheProviderClassName value to 'null' on JpaSource.
…edentials Attached patch removes all test uses of SecurityContextCredentials and replaces custom RepositoryContext implementations with MockRepositoryContext where possible. All tests pass.
…ing ModeShape through Teiid Fixed a bad I18n message and added a test case to verify that the behavior was broken and is now fixed. Unfortunately, the I18n message that was bad was the same error message that gets used when the I18n message is bad - hence the stack overflow.
…oss AS 5.1 Attached patch that removes all use of JPA2 from the JPA connector, as JBoss AS 5.1 supports Java EE 5, and Java EE 5 only supports JPA, not JPA2. It seems possible to make JPA2 work in AS5 (according to this post: http://community.jboss.org/thread/159628), but it requires users to jump through some hoops. The JPA2 dependencies were all added as part of the MODE-1209 fix, but it is possible to preserve the ability to cache nodes without using JPA2. That is what this patch does.
…thentication Changed how the ModeShape JCR repository authentication and authorizes clients to no longer be entirely self-contained. Now, it is possible to configure each Repository instance with one or more customized authentication providers that are added to several built-in authentication providers for JAAS, anonymous (if configured), and HTTP Servlet. When Repository.login(...) is called, these providers are consulted in serial to authenticate the supplied credentials, and a Session is created if any provider successfully authenticates. The ExecutionContext's SecurityContext is used to perform any authorization. Since the already-existing SecurityContext could only perform role-based permissions, a new AuthorizingSecurityContext interface was added to do path-based authorization, and is now used first if the ExecutionContext's security context is an AuthorizingSecurityContext implementation. Therefore, each authenticator is responsible for creating an ExecutionContext that represents the user, including an appropriate (Authorizing)SecurityContext instance. The AuthorizationProvider.authorize(...) method takes a Map<String,Object> parameter, allowing providers to add name-value pairs to this map when the supplied credentials are authenticated. ModeShape takes this map (populated only by the provider that successfully authenticates) and uses it as the Session's attributes. Thus, this technique allows each provider to place their own information in the Session attributes. Also updated the new Reference Guide section that talks about the AuthorizationProvider framework. JcrRepository can be configured such that any user failing authentication will be authenticated as an anonymous user. The way JcrRepository was tracking this option was not clear, so it was changed to set up an AnonymousCredentials in these situations, and if the user fails authentication with their the AnonymousCredentials then we try to authenticate them anonymously (using the AnonymousCredentials). This was merely an implementation change, so no documentation changes were necessary. Finally, it is possible to disable the JAAS AuthenticationProvider by specifying a zero-length value for the 'jaasLoginConfigName' option. This was also documented in the associated Reference Guide sections. Again, out-of-the-box ModeShape works as it did before, except that SecurityContextCredentials are deprecated and authentication with them is DISABLED by default.