1. 27 Aug, 2018 1 commit
  2. 22 Aug, 2018 2 commits
  3. 16 Aug, 2018 3 commits
  4. 26 Jun, 2018 1 commit
  5. 11 Jun, 2018 2 commits
  6. 29 May, 2018 2 commits
  7. 28 May, 2018 1 commit
  8. 09 May, 2018 1 commit
  9. 07 May, 2018 2 commits
    • Peter Centgraf's avatar
      REPO-2012 Update tika to 1.18 · 7e68f584
      Peter Centgraf authored
      7e68f584
    • Ard Schrijvers's avatar
      REPO-2007 [Backport 11.2] Reset invalid RUNNING locks to free when a cluster node starts · a8536671
      Ard Schrijvers authored
      If a cluster node (say 'node1') starts and it finds locks in the lock
      table that are for 'node1', it means that the cluster node did not release
      all its locks during shutdown (graceful or ungraceful) and it did come
      up again before other cluster nodes had reset the lock to FREE because
      the lock did not yet reach its expiration time (or there were no other
      cluster nodes).
      In normal situations the DbResetExpiredLocksJanitor takes care of freeing
      expired locks, for example locks that belonged to a shut down cluster
      node. But in the scenario above, the DbResetExpiredLocksJanitor did not
      yet free the locks, resulting in
      org.onehippo.repository.lock.db.DbLockManager#createLock not allowing the
      lock to be created BUT the DbLockRefresher starts refreshing the database
      lock nonetheless, hence, no thread in any cluster node can reclaim the
      lock any more.
      A solution could be that the DbLockRefresher only refreshes locks that
      are present in the
      org.onehippo.repository.lock.AbstractLockManager#localLocks object.
      However that would make the refresh statement complexer, so instead,
      during start up now invalid live locks are reset.
      
      (cherry picked from commit 2fdd5458ae3439092b58b7febb380f69057fca7f)
      a8536671
  10. 24 Apr, 2018 2 commits
  11. 20 Apr, 2018 1 commit
  12. 11 Apr, 2018 1 commit
  13. 03 Apr, 2018 1 commit
  14. 02 Apr, 2018 1 commit
    • Ate Douma's avatar
      REPO-1976 Upgrade to jackrabbit-2.16.1-h1 and Tika 1.17 · a4e46541
      Ate Douma authored
      This introduces the new hippo-repository-tika module which now takes care of managing all the tika-parsers related dependencies (and exclusions),
      and provides a new TikaFactory for loading the hippo-repository specific tika-config.xml, and creating new Tika instances using the corresponding TikaConfig.
      
      The tika-core/tika-parsers dependency management previously configured in the hippo-cms7-project parent no longer can/should be used, and thus will be removed.
      
      (cherry picked from commit 56ff16ba)
      a4e46541
  15. 29 Mar, 2018 3 commits
  16. 13 Mar, 2018 1 commit
  17. 07 Mar, 2018 3 commits
  18. 27 Feb, 2018 1 commit
  19. 12 Feb, 2018 2 commits
  20. 11 Feb, 2018 3 commits
  21. 25 Jan, 2018 2 commits
  22. 23 Jan, 2018 1 commit
  23. 16 Jan, 2018 2 commits
  24. 03 Jan, 2018 1 commit