eXo-JCR-jcr

Clone Tools
  • last updated a few minutes ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
patch-jcr-2415

Fix for Gerap-44

[maven-release-plugin] [PLF-6276]prepare release 1.15.13-GA

    • -1
    • +1
    /applications/exo.jcr.ispn.ear/pom.xml
    • -1
    • +1
    /exo.jcr.component.core.impl.infinispan.v5/pom.xml
  1. … 12 more files in changeset.
[PLF-6276] Upgrade dependencies to latest releases

[PLF-6220]: Update dependencies

[maven-release-plugin] [PLF-6220]prepare for next development iteration

    • -1
    • +1
    /applications/exo.jcr.ispn.ear/pom.xml
    • -1
    • +1
    /exo.jcr.component.core.impl.infinispan.v5/pom.xml
  1. … 12 more files in changeset.
[maven-release-plugin] [PLF-6220]prepare release 1.15.12-GA

    • -1
    • +1
    /applications/exo.jcr.ispn.ear/pom.xml
    • -1
    • +1
    /exo.jcr.component.core.impl.infinispan.v5/pom.xml
  1. … 12 more files in changeset.
[PLF-6220] Upgrade dependencies to latest releases

JCR-2381 : Update foundation parent pom

Merge pull request #196 from exodev/fix/1.15.12-GA/JCR-2381

JCR-2381 : Update foundation parent pom

JCR-2381 : Update foundation parent pom

JCR-2378 : Fix the violations found by Sonar

JCR-2376 : Methods COPY, MOVE : Overwrite Header doesn't match specification

JCR-2372 : NPE with PostgreSQL 9.2 and 9.3 in jUnit tests

Problem analysis

- The error occurs when we launch tests with the driver 9.3-1102 JDBC4 is due to a

lack of permission for reading system property "org.postgresql.force binary"

Fix description

- Add read permission for the system property org.postgresql.forcebinary (Add this permission in the java.security.policy). This change affects only test execution for jcr.

    • -0
    • +14
    /exo.jcr.component.core.impl.infinispan.v5/pom.xml
JCR-2370: Update the documentation about Manageability

JCR-2369: Upgrade to Infinispan 5.1.8

JCR-2367 : Create new logic for webdav: create-version and checkin-checkout

PLF-6122: Update dependencies to next snapshots

JCR-2362 : Slowness when creating a new page

Problem analysis

- When a new child node is added, we have to invalidate the list of child nodes of the parent node in the cache which was done by a simple remove of the related cache entry.

- The JCR-2288 isolates the invalidation by doing it outside the global tx in order to highly reduce the risk of such deadlocks.

- But with this approach, the removal of each entry generates a command JGroups. So when a lot of child are created, this process invokes a large network traffic IO then the creation is slow.

Fix description

- Allow to invalidate the content in auto-commit until we reach a given threshold, beyond this threshold the rest will be done within the context of a transaction.

- With a threshold properly set, we will reduce the risk of having deadlocks and we will reduce the total amount of jgroups calls done especially in case of a big transaction.

[maven-release-plugin] [PLF-6112]prepare for next development iteration

    • -1
    • +1
    /applications/exo.jcr.ispn.ear/pom.xml
    • -1
    • +1
    /exo.jcr.component.core.impl.infinispan.v5/pom.xml
  1. … 12 more files in changeset.
[maven-release-plugin] [PLF-6112]prepare release 1.15.11-GA

    • -1
    • +1
    /applications/exo.jcr.ispn.ear/pom.xml
    • -1
    • +1
    /exo.jcr.component.core.impl.infinispan.v5/pom.xml
  1. … 12 more files in changeset.
[PLF-6112] Upgrade dependencies to latest releases

JCR-2352: The method SharedFieldCache.getValueIndex needs to be optimized

JCR-2345: Simultaneous startup of the nodes results in failure of initialization of almost all nodes

Problem analysis

- Deep investigations show that the requested RemoteCommand _org.exoplatform.services.jcr.impl.core.query.lucene.DocNumberRecoveryFilter-getDocNum-portal-repository-portal-system-false_ cannot be invoked because it has been removed from the commands map under the RPCService.

- The timestamp in which command was removed from the coordinator coincides with the timestamp where the same command get removed from the nodes being shut down using the org.exoplatform.services.rpc.impl.AbstractRPCService#unregisterCommand.

Fix description

- When the SearchIndex has been suspended, the getDocsNumCommand command waits until SearchIndex is resumed

JCR-2343: Parsing error appeared when export PDF file and import it again

* Problem analysis:

An invalid character in a PDF file is stored in XML file when exporting it.

XML parser cannot then parse this character when importing again.

* Fix description:

- Validate all characters when exporting to System View.

If a string has invalid character, it uses Base64 encoding instead of unicode (default) for that string.

- When importing, it checks and sets appropriate encoding value per string.

- Nothing changes in case of Document View.

ECMS-6597 will provide a comprehensible message so that the user who imports such file can remove that character manually.

JCR-2335 : DB2 and XA Datasource on JBoss EAP

Problem analysis

- By default auto-commit is enabled and error is returned once the inner resultset Resultset2 has completed fetching all the rows from Resultset2 because this causes a COMMIT to be sent to the server. The COMMIT also closes any other open ResultSets such as ResultSet1.

Fix description

- The solution is to disable autocommit before any nested Resultset code and then re-enable auto-commit after the nested resultset code.

JCR-2333: New registered namespaces aren't synchronized between two nodes

Fix description:

- Use RPCService to register/unregister newly added namespaces and node types in repository of all cluster nodes.

JCR-2324: RepositoryCheckController mbean writes log in / when starting as Linux Service

Fix description:

- Open log file with absolute path to save log in right folder.

JCR-2332: Remove TestDateSearch inside XLS file

Fix description:

* After COR-329, date value in Microsoft Excel's cells is no longer extracted.

TestDateSearch inside XLS file gives thus no result.

JCR-2323: Wrong Upload size on cluster mode

Problem analysis:

- On clustering mode : for files whose size exceeds the buffer value (by default 200K), the steps are as follows:

- The property jcr:data is built in the first node having the value of an object (more precisely of StremValuePropertyData type) that has an instance variable with the name "file" containing the file path in the value storage and point on a path in the swap file.

- When this property is applied to the second node and the object is intercepted, the logic responsible for the serialization of the object simply checks if the file exists in the system or not (which is not the case) and make it "null" if necessary.

Fix description

- When the path file of StremValuePropertyData is null, do forceLoad the property data from the DB storage.