Picon

[Commented] (JCR-3131) NPE in ItemManager when calling Session.save() with nothing to save


    [
https://issues.apache.org/jira/browse/JCR-3131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13141086#comment-13141086
] 

Jukka Zitting commented on JCR-3131:
------------------------------------

+1 the patch looks good

> NPE in ItemManager when calling Session.save() with nothing to save
> -------------------------------------------------------------------
>
>                 Key: JCR-3131
>                 URL: https://issues.apache.org/jira/browse/JCR-3131
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-core
>    Affects Versions: 2.3.2
>            Reporter: Bertrand Delacretaz
>            Assignee: Julian Reschke
>            Priority: Minor
>         Attachments: JCR-3131.patch
>
>
> I'm getting an NPE on the id.denoteNodes() call below, in ItemManager:
>     private ItemData retrieveItem(ItemId id) {
>         synchronized (itemCache) {
>             ItemData data = itemCache.get(id);
>             if (data == null && id.denotesNode()) {
(Continue reading)

Picon

[Assigned] (JCR-3131) NPE in ItemManager when calling Session.save() with nothing to save


     [
https://issues.apache.org/jira/browse/JCR-3131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Guggisberg reassigned JCR-3131:
--------------------------------------

    Assignee: Stefan Guggisberg  (was: Julian Reschke)

> NPE in ItemManager when calling Session.save() with nothing to save
> -------------------------------------------------------------------
>
>                 Key: JCR-3131
>                 URL: https://issues.apache.org/jira/browse/JCR-3131
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-core
>    Affects Versions: 2.3.2
>            Reporter: Bertrand Delacretaz
>            Assignee: Stefan Guggisberg
>            Priority: Minor
>         Attachments: JCR-3131.patch
>
>
> I'm getting an NPE on the id.denoteNodes() call below, in ItemManager:
>     private ItemData retrieveItem(ItemId id) {
>         synchronized (itemCache) {
>             ItemData data = itemCache.get(id);
>             if (data == null && id.denotesNode()) {
> ...
(Continue reading)

Picon

[Resolved] (JCR-3131) NPE in ItemManager when calling Session.save() with nothing to save


     [
https://issues.apache.org/jira/browse/JCR-3131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Guggisberg resolved JCR-3131.
------------------------------------

       Resolution: Fixed
    Fix Version/s: 2.4

fixed in svn revision 1196062 by committing the patch with some changes (i've chosen a somewhat simpler approach).

> NPE in ItemManager when calling Session.save() with nothing to save
> -------------------------------------------------------------------
>
>                 Key: JCR-3131
>                 URL: https://issues.apache.org/jira/browse/JCR-3131
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-core
>    Affects Versions: 2.3.2
>            Reporter: Bertrand Delacretaz
>            Assignee: Stefan Guggisberg
>            Priority: Minor
>             Fix For: 2.4
>
>         Attachments: JCR-3131.patch
>
>
> I'm getting an NPE on the id.denoteNodes() call below, in ItemManager:
(Continue reading)

Picon

[Commented] (JCR-3064) Concurrent access performance drop


    [
https://issues.apache.org/jira/browse/JCR-3064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13142148#comment-13142148
] 

Julian Reschke commented on JCR-3064:
-------------------------------------

For jcr2spi, I see NPEs logged in canRead(); maybe the assumption

          // no extra check for existence as method may only be called for existing items.

is incorrect in this case?

                
> Concurrent access performance drop
> ----------------------------------
>
>                 Key: JCR-3064
>                 URL: https://issues.apache.org/jira/browse/JCR-3064
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>            Reporter: Jukka Zitting
>            Priority: Blocker
>             Fix For: 2.4
>
>         Attachments: ConcurrentReadTest-2011.png, ConcurrentReadTest.png,
ConcurrentReadWriteTest-2011.png, ConcurrentReadWriteTest.png,
JCR-3064-EntryCollector.patch, visualvm-ConcurrentReadTest-2.2.png, visualvm-ConcurrentReadTest-2.3.png
>
(Continue reading)

Picon

[Created] (JCR-3135) Upgrade to Logback 1.0

Upgrade to Logback 1.0
----------------------

                 Key: JCR-3135
                 URL: https://issues.apache.org/jira/browse/JCR-3135
             Project: Jackrabbit Content Repository
          Issue Type: Improvement
            Reporter: Jukka Zitting
            Assignee: Jukka Zitting
            Priority: Minor

Logback 1.0 was just released (see http://mailman.qos.ch/pipermail/announce/2011/000093.html).
There are no big new features or other major changes, but the bump to 1.0 is still a good point for us to
upgrade to get all the latest bug fixes and other improvements.

At the same time we should upgrade our SLF4J depedency to the latest 1.6.4 version.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Picon

[Updated] (JCR-3116) Cluster Node ID should be trimmed


     [
https://issues.apache.org/jira/browse/JCR-3116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Mueller updated JCR-3116:
--------------------------------

    Fix Version/s: 2.2.10

> Cluster Node ID should be trimmed
> ---------------------------------
>
>                 Key: JCR-3116
>                 URL: https://issues.apache.org/jira/browse/JCR-3116
>             Project: Jackrabbit Content Repository
>          Issue Type: Improvement
>          Components: clustering, config, jackrabbit-core
>    Affects Versions: 2.2.9, 2.3.1
>            Reporter: Julian Sedding
>            Assignee: Thomas Mueller
>            Priority: Trivial
>             Fix For: 2.2.10, 2.4
>
>         Attachments: JCR-3116.patch
>
>
> If the cluster node ID is not configured in repository.xml, it is read from the file cluster_node.id
instead. In case this file is edited by hand, some editors (e.g. vi) insert a trailing newline character
("\n"). This leads to the cluster node ID to contain a blank character. While I don't expect this to cause
any issues, it is inconvenient for debugging and also introduces line-breaks in log files. I suggest to
(Continue reading)

Picon

[Resolved] (JCR-3116) Cluster Node ID should be trimmed


     [
https://issues.apache.org/jira/browse/JCR-3116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Mueller resolved JCR-3116.
---------------------------------

    Resolution: Fixed

> Cluster Node ID should be trimmed
> ---------------------------------
>
>                 Key: JCR-3116
>                 URL: https://issues.apache.org/jira/browse/JCR-3116
>             Project: Jackrabbit Content Repository
>          Issue Type: Improvement
>          Components: clustering, config, jackrabbit-core
>    Affects Versions: 2.2.9, 2.3.1
>            Reporter: Julian Sedding
>            Assignee: Thomas Mueller
>            Priority: Trivial
>             Fix For: 2.2.10, 2.4
>
>         Attachments: JCR-3116.patch
>
>
> If the cluster node ID is not configured in repository.xml, it is read from the file cluster_node.id
instead. In case this file is edited by hand, some editors (e.g. vi) insert a trailing newline character
("\n"). This leads to the cluster node ID to contain a blank character. While I don't expect this to cause
any issues, it is inconvenient for debugging and also introduces line-breaks in log files. I suggest to
(Continue reading)

Picon

[Resolved] (JCR-2551) Recovery from a lost version history


     [
https://issues.apache.org/jira/browse/JCR-2551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jukka Zitting resolved JCR-2551.
--------------------------------

    Resolution: Duplicate

Resolving as a duplicate of JCR-3101.

> Recovery from a lost version history
> ------------------------------------
>
>                 Key: JCR-2551
>                 URL: https://issues.apache.org/jira/browse/JCR-2551
>             Project: Jackrabbit Content Repository
>          Issue Type: New Feature
>          Components: jackrabbit-core, versioning
>            Reporter: Jukka Zitting
>
> I'm working on a case where the entire version storage is lost and would like to add a recovery feature that
can restore the repository to a consistent state after such an event. This feature should look for all
versionable nodes in the repository and either remove all broken references to the version storage
(making the node unversionable) or automatically reconnect the nodes to new empty version histories.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
(Continue reading)

Apache Jenkins Server | 2 Nov 16:23 2011
Picon

Jackrabbit-trunk - Build # 1724 - Unstable

The Apache Jenkins build system has built Jackrabbit-trunk (build #1724)

Status: Unstable

Check console output at https://builds.apache.org/job/Jackrabbit-trunk/1724/ to view the results.

Jukka Zitting | 2 Nov 16:45 2011
Picon

Re: Jackrabbit-trunk - Build # 1724 - Unstable

Hi,

This was a case of JCR-3097. I marked the test as a known issue in
revision 1196642.

[1] https://issues.apache.org/jira/browse/JCR-3097

BR,

Jukka Zitting


Gmane