Permalink
Commits on Feb 27, 2013
  1. Updated release notes

    rhauch committed Feb 27, 2013
Commits on Feb 26, 2013
  1. MODE-1830 Corrected the purging of workspace caches in a cluster

    Before this fix, when a change was made via a WritableSessionCache,
    any changes persisted to the store were also used to directly purge
    any previously-cached node representations from the corresponding
    WorkspaceCache. Thus, when the RepositoryCache received the changes,
    it simply forwarding them to all workspaces except the one in which
    the changes originated.
    
    However, in a clustered environment, the changes originate on one
    process and are sent to all other processes. The logic described
    above works fine in the same process in which the changes originated,
    but it doesn't correctly propagate the changes in the other processes.
    
    The fix was pretty simple: determine if the changes came from the same
    process. If so, the use the current logic. If not, always forward the
    changes to all WorkspaceCache instances.
    
    I also modified the ClusteredRepositoryTest to look in process A for
    nodes changed in process B. This failed before the logic was fixed,
    and now works with the fix.
    rhauch committed Feb 26, 2013
  2. MODE-1826 - Added an integration smoke test which uses a write-behind…

    …, JDBC cache store
    hchiorean committed with rhauch Feb 26, 2013
  3. MODE-1828 - ConstraintViolationException when updating the definition…

    … of the same node in a session
    
    Fix the issue by making sure that nodeTypes with the same name is actually updated properly in the cache.
    panghy committed with rhauch Feb 26, 2013
  4. MODE-1827 - NullPointerException in RepositoryQueryManager

    Null check in case the node no longer exist in the cache.
    panghy committed with rhauch Feb 25, 2013
  5. MODE-1823 - Fixed the WebDAV servlet to use UTF-8 encoding in paths a…

    …nd also to generate full links when displaying the contents of folders.
    hchiorean committed Feb 26, 2013
  6. MODE-1823 - Changed the rest service's output mechanism, so that the …

    …written strings are always UTF-8 encoded and added UTF-8 as an explicit response header.
    hchiorean committed Feb 25, 2013
Commits on Feb 25, 2013
  1. MODE-1822 Added tests that use Atomikos transaction manager

    Other fixes for MODE-1819 actually fixed the problem, while this
    change only adds test cases and test dependencies on Atomikos to
    verify the expected behavior now works. Also added similar tests
    that use the JBoss Transactions library.
    rhauch committed Feb 25, 2013
  2. MODE-1819 Changed how WorkspaceCache is used inside user transactions

    Added a new specialization of WorkspaceCache called
    TransactionWorkspaceCache that is used in place of WorkspaceCache
    any time a ReadOnlySessionCache or WritableSessionCache is used
    during the scope of a running user transaction.
    
    Normally, each RepositoryCache instance has for each workspace a
    single WorkspaceCache instance shared by all sessions. However, in
    the case of a session is running within a user transaction, it is
    possible for the session (or other sessions that are also participating
    in the same user transaction) to persist node changes in the document
    store but to not commit the transaction. This means that such
    persisted-but-not-committed node representations should be visible to
    the sessions running within the transaction but should not be visible
    to sessions outside of the transaction. Because the shared
    WorkspaceCache lazily loads the requested nodes using the transactional
    scope of the requestor, this means that the WorkspaceCache may load
    these persisted-but-not-committed node representations and make them
    available to other sessions (outside the transaction boundary) and
    thereby leaking transactionally-scoped data. Similarly,
    a WorkspaceCache that already has the persisted-and-committed node
    representations from other sessions will expose those already-cached
    forms to sessions running within the transaction, thereby causing
    some of the sessions in the same user transaction to not see the
    transactionally-scoped (e.g., persisted-but-not-committed) changes.
    
    Therefore, such sessions running within user transactions need a
    transactionally-scoped WorkspaceCache instance rather than sharing
    the commont WorkspaceCache instance. However, the ModeShape
    infrastructure is not set up to handle lots of WorkspaceCache instances
    for the same workspace, so we have to be careful about any
    transaction-specific caches.
    
    This new design changes the AbstractSessionCache to maintain the original
    reference to the real (shared) WorkspaceCache, but to also have another
    WorkspaceCache reference that may change (depending upon whether there
    is a current user transaction) to a transient TransactionalWorkspaceCache
    instance specific to the transaction.
    
    Originally, I tried to have the TransactionalWorkspaceCache do no
    caching whatsoever, but this caused problems within the
    WritableSessionCache's persistChanges logic, which needs access to
    the persisted representation of the node prior to when each changed
    node was actually changed. So, the TWC simply uses an in-memory
    ConcurrentHashMap. (The alternative was to use another Infinispan
    cache such as the one used for the shared workspace caches, but this
    would dramatically increase the complexity of the system and would
    require an additional cache container configured with different settings
    than the normal workspace caches and to use a different naming
    convention.)
    
    Several new test cases were added to verify that multiple sessions
    within the same user transaction do indeed all see the same
    transactionally-scoped data, while other sessions that are outside
    of the user transaction do indeed not see any of the transactionally-
    scoped changes until commit occurs.
    rhauch committed Feb 25, 2013
  3. MODE-1821 Improved the recent changes to perform post-lock validation

    Made several improvements to the recent changes that add validation
    of SNS *after* locks were obtained.
    rhauch committed Feb 25, 2013
Commits on Feb 22, 2013
  1. MODE-1821 - Fixed the inconsistency which can occur when creating SNS…

    … simultaneously from multiple threads. The solution was to add an additional method to JcrSession#PreSave and which is executed only after Infinispan locks are obtained on the changed nodes.
    hchiorean committed Feb 22, 2013
Commits on Feb 21, 2013
  1. MODE-1825 Added testcase and fix for handling QOM queries where both …

    …the columnName and propertyName are null.
    panghy committed with rhauch Feb 21, 2013
Commits on Feb 20, 2013
  1. MODE-1818 Added garbage collection properties to AS7 schema and subsy…

    …stem
    
    Added the garbage collection configuration attributes to ModeShape's
    XSD schema and subsystem, and added a unit test that verifies the
    attributes are read correctly.
    rhauch committed with hchiorean Feb 18, 2013
  2. MODE-1818 Repository configuration can now dictate garbage collection…

    … options.
    
    The garbage collection options can now be specified in the repository
    configuration. Each repository registers its own garbage collection
    processes with a named thread pool, and these processes are stopped
    when the repository is shut down.
    rhauch committed with hchiorean Feb 18, 2013
Commits on Feb 18, 2013
  1. MODE-1813 - Updated CDI test with a test-case that allow replication …

    …of the issue. Also, added the explicit dependency as fix.
    hchiorean committed Feb 15, 2013
  2. MODE-1796 Changed the InfinispanBinaryStore garbage collection logic

    The RemoteCache or a RemoteCacheStore do not support map-reduce,
    so we have to process the contents in a different way.
    rhauch committed with hchiorean Feb 15, 2013
  3. MODE-1817 Corrected logic of concurrent removals

    Added a relatively-simple test case that replicated the exact exception
    using my hypothesized scenario. The test creates separate threads to
    concurrently remove a specific node and (after synchronizing on a
    CyclicBarrier) save their changes. Thus, the transient state of each
    Session does not see the uncommitted transient state of the other
    Session, but both sessions are saved roughly the same time (in different
    threads so different transactions are used). But since both need to
    acquire the lock on the same parent node, only one session will proceed
    first to successfully remove the node. When the second session proceeds,
    it no accepts the fact that the node was already removed and proceeds
    accordingly.
    
    (ACID transactions FTW!)
    
    The fix was pretty simple: be aware that attempting to remove an entry
    in the cache may return null if the entry does not exist (i.e., was
    recently removed).
    rhauch committed with hchiorean Feb 15, 2013
  4. MODE-1809 Corrected the processing of set queries, including unions

    The code was sorting and then removing duplicates in the tuples,
    but during pre-processing and planning, the internal structure of the
    tuples changed for certain kinds of queries (like unions with join)
    to add in node location information as additional columns. The
    removal of duplicates, however, was still incorrectly basing its
    access of the tuple values upon the smaller/earlier tuple structure.
    This cause various kinds of ClassCastExceptions.
    
    Added a test case that replicated the originally reported problem,
    which after the fix now passes.
    rhauch committed with hchiorean Feb 15, 2013
Commits on Feb 15, 2013
  1. MODE-1816 REST v2 responses base property representations on number o…

    …f values
    
    The response should base the field value for a given property based upon
    whether that JCR property is single-valued or multi-valued, not upon
    the number of values. If multi-valued, then the field value should be
    an array (even if there is just one item). Version 1 of the REST API
    already works this way, but the version 2 was changed.
    
    Note that it is still possible for property representations in
    requests to use a single value (rather than an array) when setting
    a multi-value to a single value, or the more conventional practice
    of using an array to set a multi-valued array. The latter is obviously
    required when setting the mutli-valued property to 0 or 2+ values.
    
    Several of the expected results were incorrect and have been changed.
    rhauch committed Feb 15, 2013
  2. MODE-1813 - Implemeted an Arquillian based test using CDI and various…

    … deployment units.
    hchiorean committed with rhauch Feb 15, 2013
  3. MODE-1804 - Corrected the schema and the Hibernate Search parameters …

    …for the jgroups-slave backend.
    hchiorean committed with rhauch Feb 15, 2013
Commits on Feb 14, 2013
  1. MODE-1816 The jcr:mixinTypes properties should not need to be first i…

    …n the JSON requests
    
    ModeShape should not expect that the "jcr:mixinTypes" property be
    before the other properties in the JSON request coming from REST clients.
    Some libraries will not allow clients to reliably choose the order.
    
    Added a test case to verify this now works.
    rhauch committed Feb 14, 2013
  2. MODE-1811 - Fixed the InfinispanBinaryStore not being able to load a …

    …class from modeshape-jcr, by making that class available in the AS 7.1.1 kit to the org.infinispan.main module.
    hchiorean committed with rhauch Feb 14, 2013
  3. MODE-1807 - Changed the order of steps in the node validation algorit…

    …hm and updated the test case that caused this issue
    hchiorean committed Feb 14, 2013
Commits on Feb 13, 2013
  1. MODE-1805 Query system can be disabled in AS7 kit

    Added ability to completely disable the query system (including the
    generation/maintenance of indexes) in a repository in the AS7
    subsystem. (The JSON repository configurations had this ability for
    some time, but it could not be controlled in AS7.)
    
    This adds a new "enable-queries" XML attribute on the "repository"
    element in the subsystem configuration. This attributes defaults
    to "true" and therefore is backward compatible. However, setting it
    to "false" will completely disable the indexing system, although
    any index storage and indexing configuration within a repository
    configuration will remain as-is; it will simply not be used.
    This means that the repository's indexes and query system can be
    disabled (perhaps on a temporary basis) and then re-enabled without
    having to completely reconfigure the index storage and indexing
    parameters.
    
    It was discovered that executing queries on a repository that had
    its query system disabled resulted in a NPE, because the running
    state did not have a RepositoryQueryManager instance. Rather than
    deal with all of the potential NPEs, a new specialization of
    the RepositoryQueryManager, called RepositoryDisabledQueryManager,
    was added and is instantiated within the running state when queries
    are disabled. This specialization essentially no-ops all of the
    operations. The result is that queries will return no results
    rather than throw an exception.
    
    Additional warning messages are logged when the indexes are indeed
    disabled, since this will rarely be done in production.
    
    Several new tests were added, including unit tests (in
    'modeshape-jcr') and integration tests for the AS7 subsystem.
    rhauch committed Feb 13, 2013