Clone
 

philippe aristote <philippe.aristote@exoplatform.com> in eXo-JCR-jcr

PLF-1747 JCR-1647

What is the problem to fix?

Platform source distribution. Create a Zip archive with all projects sources.

How is the problem fixed?

Add a maven plugin to generate the Zip automatically during the release.

    • -0
    • +54
    /patch/1.12.11-GA/JCR-1647/JCR-1647.patch
    • -0
    • +63
    /patch/1.12.11-GA/JCR-1647/readme.txt
PLF-1897 commit change for EXOJCR-1464

PLF-1897 update version in pom.xml files

  1. … 12 more files in changeset.
JCR-1639

What is the problem to fix?

* Delay in replication of Nodes data in JBoss EPP

How is the problem fixed?

* Need to rollback JDBC connection before closing.

    • -0
    • +72
    /patch/1.12.10-GA/JCR-1639/readme.txt
[PLF-1660] Upgrade dependencies to next snapshots

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

  1. … 11 more files in changeset.
[maven-release-plugin] [PLF-1660]prepare release 1.12.9-GA

  1. … 11 more files in changeset.
[PLF-1660] Upgrade dependencies to latest releases

JCR-1631 log error messages in ERROR more rather than DEBUG

JCR-1632 clean build by putting all generated data in target

JCR-1572

What is the problem to fix?

* Tested EPP 5.0.1 with 19 000 users created thanks to crash and its advanced command addusers that you can found here https://github.com/exoplatform/gatein-stuff. The table JCR_SITEM contains 4,3 Millions of rows and JCR_SVALUE contains 3,2 Millions of rows, in this case if I try to re-index my content that contains 1 216 000 nodes, the re-indexing takes 3 h 40 minutes on my laptop which is a dual core. The idea of my patch proposal is to propose a multi-threaded re-indexing mechanism in order to take advantage of multi-cores which is commonly used now, thanks to this patch the re-indexing takes 2 h 20 minutes on my laptop knowing that the main bottelneck is the db.

Please check the patch and if it is ok ask the QA to load a big table and re-index it with and without the patch to see the gain in their environment.

How is the problem fixed?

* involve several threads in jcr indexing operation

    • -0
    • +0
    /patch/1.12.9-GA/JCR-1572/JCR-1572.patch
    • -462
    • +0
    /patch/1.12.8-GA/JCR-1572/JCR-1572.patch
    • -0
    • +65
    /patch/1.12.9-GA/JCR-1572/readme.txt
JCR-1577

Check in DefaultChangesFilter if we use the right ids in case of a IOException while updating the index of the parentSearchManager

How is the problem fixed?

Fixed by passing correct lists of added and removed nodes on Exception to queryHandler.logErrorChanges(List, List);

    • -0
    • +0
    /patch/1.12.9-GA/JCR-1577/JCR-1577.patch
    • -13
    • +0
    /patch/1.12.8-GA/JCR-1577/JCR-1577.patch
    • -0
    • +106
    /patch/1.12.9-GA/JCR-1577/readme.txt
JCR-1611

What is the problem to fix?

We need to backport the fix of the jira EXOJCR-1234 to JCR 1.12.x.

How is the problem fixed?

Change the calculation way of last order number during node adding. The new order number will be as real last order number plus 1.

In previous impl it was as children nodes count plus 1.

  1. … 11 more files in changeset.
JCR-1618

What is the problem to fix?

This issue is only reproduced with Mysql engine type InnoDB(not reproduced with MySQL MyIsam)

when we try to create a new nodetype with same name sibling we get an exception.

How is the problem fixed?

Check-sns-new-connection is set to false by default

    • -0
    • +106
    /patch/1.12.9-GA/JCR-1618/readme.txt
JCR-1597

What is the problem to fix?

There are some problems when using webdav on Windows 7. We can't open a document (MS Office 2010) or the document is opened as read only (Open Office)

How is the problem fixed?

Lock tokens parsing fixed, to parse tokens not surrounded by '<' and '>' characters. To open documents via basic authentication on Windows 7 with MS Office 2010 we also need to edit registry.

    • -0
    • +70
    /patch/1.12.9-GA/JCR-1597/readme.txt
JCR-1622

What is the problem to fix?

* Threads are not ended when the application is stopped/restarted

so after restart we have multiple instances of these threads ( org.exoplatform.container.StandaloneContainer-db1_cmis1_cacheWorker,

and the one for db1_system too and also HSQL Timer thread)

* test case to reproduce:

start tomcat with xcmis

go to Tomcat Manager

Stop xCMIS Application

Start xCMIS Application

With a jconsole you can see that you have several times the same threads.

How is the problem fixed?

* Make components to be Startable and on stop method shutdown working threads.

    • -0
    • +76
    /patch/1.12.9-GA/JCR-1622/readme.txt
JCR-1629

What is the problem to fix?

* For indexing, JBC is used as the temporary/transactional/cluster aware memory such that if we add an eviction policy we could miss some nodes to index

moreover using eviction algorithm such as FIFO add some contention.

How is the problem fixed?

* Removing eviction policy from configuration

    • -0
    • +65
    /patch/1.12.9-GA/JCR-1629/readme.txt
JCR-1616

What is the problem to fix?

To reproduce the problem:

Create/Open an Article node

Click on Manage Actions and add a new action.

Try to edit this node.

-> The node could not be edited .

Problem analysis

Problem of getting node definition.

How is the problem fixed?

Determinate more suitable node definition based on node type.

    • -0
    • +77
    /patch/1.12.9-GA/JCR-1616/readme.txt
JCR-1615

What is the problem to fix?

1- Go to the Drive "Collaboration"

2- Lock the "documents" folder

3- Create a new document in the "documents" folder, save it as draft than close it

4- Click on the "publish" button: we get an exception: "javax.jcr.lock.LockException: Node /Documents is locked..."

5- Changing publication state through Manage Publications action: it works fine even if the item is locked.

How is the problem fixed?

On JCR side locking bug is fixed. When calling Node.checkIn() JCR checks if parent is locked, that is actually a bug. Since Node.checkIn() doesn't modify the parent node, so it should only check if current node not locked.

    • -0
    • +70
    /patch/1.12.9-GA/JCR-1615/readme.txt
JCR-1613 This bug happens randomly (like EXOJCR-1234) when a node is ordered after it was moved at the same parent (to rename it). For instance let's suppose we have an ordered list ("a","b") and we want to rename "a" to "c" and keep the same order then the JCR operations to do it are:

session.move(parent.getPath() + "/a", parent.getPath() + "/c");

parent.orderBefore("c", "b");

How is the problem fixed?

New node is added to the end of the list of parent node as implementation says

    • -0
    • +67
    /patch/1.12.9-GA/JCR-1613/readme.txt
JCR-1594

What is the problem to fix?

Renaming folder in WebDAV takes a lot of time.

How is the problem fixed?

Avoid unnecessary re-indexing operations for children nodes

    • -0
    • +67
    /patch/1.12.9-GA/JCR-1594/readme.txt
JCR-1594 move patch to the right version folder

    • -0
    • +0
    /patch/1.12.9-GA/JCR-1594/JCR-1594.patch
    • -305
    • +0
    /patch/1.12.8-GA/JCR-1594/JCR-1594.patch
JCR-1593

What is the problem to fix?

Using webdav with https, it's impossible to rename or move a file or directory. The applied Architecture is an Apache in front which manages the https and AJP connectors that transfer requests to the server JBoss

Problem analysis

This error is caused by the following line of code in WebDavServiceImpl.java:

destinationHeader = serverURI + escapePath(destinationHeader.substring(serverURI.length()));

The output of this line is https://localhost:443/rest/private/jcr/repositorylaboration/ so the workspace collaboration is not found. The consideration of the port 443 is badly done (By using Apache, we don't specify the port).

The path obtained by this line of code:

destinationHeader = TextUtil.unescape(destinationHeader, '%'); is correct (without the specification of the port 443)

There is no problem with http.

How is the problem fixed?

Change the algorithm of parsing destination URI and base URI. Now we use java.net.URI which itself does all the parsing.

    • -0
    • +560
    /patch/1.12.9-GA/JCR-1593/JCR-1593.patch
    • -0
    • +84
    /patch/1.12.9-GA/JCR-1593/readme.txt
JCR-1605

What is the problem to fix?

Can't open file containing special characters (e.g Japanese characters) in file name/path via WebDav in Nautilus. In case of cadaver, when using "ls" command, cadaver can't list such files.

How is the problem fixed?

Set the selected tab after user add any permission to the wanted one.

    • -0
    • +83
    /patch/1.12.9-GA/JCR-1605/readme.txt
JCR-1604

What is the problem to fix?

JCR addNode within a transaction causes javax.transaction.HeuristicMixedException (internally, org.exoplatform.services.transaction.TransactionException caused by org.jboss.cache.lock.TimeoutException) in the first access to the node

How is the problem fixed?

Perform loading data in cache outside the current transaction

    • -0
    • +74
    /patch/1.12.9-GA/JCR-1604/readme.txt
JCR-1605 PLF-1483

What is the problem to fix?

Can't open file containing special characters (e.g Japanese characters) in file name/path via WebDav in Nautilus. In case of cadaver, when using "ls" command, cadaver can't list such files.

How is the problem fixed?

Set the selected tab after user add any permission to the wanted one.

JCR-1604 - PLF-1483

What is the problem to fix?

JCR addNode within a transaction causes javax.transaction.HeuristicMixedException (internally, org.exoplatform.services.transaction.TransactionException caused by org.jboss.cache.lock.TimeoutException) in the first access to the node

How is the problem fixed?

Perform loading data in cache outside the current transaction

PLF-1483 update the version number to 1.12.8_CP01

  1. … 11 more files in changeset.
[REL-647] Upgrade dependencies to next snapshots

[maven-release-plugin] [REL-647]prepare for next development iteration

  1. … 11 more files in changeset.