headers
Jukka Zitting | 2 Jan 2012 17:08
Picon
Favicon
Gravatar

[ANNOUNCE] Apache Jackrabbit 2.3.6 released

The Apache Jackrabbit community is pleased to announce the release of
Apache Jackrabbit 2.3.6. The release is available for download at:

  http://jackrabbit.apache.org/downloads.html

See the full release notes below for details about this release.

Release Notes -- Apache Jackrabbit -- Version 2.3.6

Introduction
------------

This is Apache Jackrabbit(TM) 2.3, a fully compliant implementation of the
Content Repository for Java(TM) Technology API, version 2.0 (JCR 2.0) as
specified in the Java Specification Request 283 (JSR 283).

Apache Jackrabbit 2.3 is an unstable series of releases cut directly from
Jackrabbit trunk, with a focus on new features and other improvements.
For production use we recommend the latest stable 2.2 release.

Changes in Jackrabbit 2.3.6
---------------------------

New features

  [JCR-3005] Make it possible to get multiple nodes in one call via davex
  [JCR-3183] Add memory based bundle store

Improvements
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jukka Zitting | 2 Jan 2012 17:17
Picon
Gravatar

Re: Jackrabbit 2.4 release plan

Hi,

On Tue, Dec 6, 2011 at 4:24 PM, Jukka Zitting <jukka.zitting <at> gmail.com> wrote:
> Two weeks later, on Tuesday Jan 3rd, and assuming no big problems have
> been detected, we'll then cut the stable 2.4.0 release candidate.

The 2.3.6 release announcement got delayed since I didn't have ssh
access required for staging the release over the holidays. The release
is finally now up and I just sent out the release announcement, but
it's probably best to give some time for people to try it out before
we cut 2.4.0.

And there hasn't been much work in trunk or the 2.4 branch since the
2.3.6, so also from that perspective we should let things rest a bit
longer before cutting the first stable 2.4 release.

Thus I suggest that we postpone the 2.4.0 cut date two weeks ahead to
Tuesday, Jan 17th. Any help before that in testing the 2.3.6 release
and pointing out any pending fixes in Jira will be much appreciated.

BR,

Jukka Zitting
Permalink | Reply | 4 comments |
headers
Lukas Kahwe Smith (Commented) (JIRA | 2 Jan 2012 17:52
Picon
Favicon

[Commented] (JCR-2543) spi2dav : Query offset not respected


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

Lukas Kahwe Smith commented on JCR-2543:
----------------------------------------

so is this issue resolved now?

> spi2dav : Query offset not respected
> ------------------------------------
>
>                 Key: JCR-2543
>                 URL: https://issues.apache.org/jira/browse/JCR-2543
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-jcr-server, jackrabbit-spi2dav, JCR 2.0, query
>    Affects Versions: 2.0
>            Reporter: angela
>         Attachments: patch_commit_ebebb62c3df0.patch
>
>
> the TCK query test SetOffsetTest fails in the setup jcr2spi - spi2dav(ex) - jcr-server.
> not sure whether it is due to missing implementation on client or server part of something completely different....

--
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)

Permalink | Reply | 0 comments |
headers
Gustavo Orair (Created) (JIRA | 2 Jan 2012 18:52
Picon
Favicon

[Created] (JCR-3197) ItemNotFoundException while adding a NT_FOLDER node inside rootNode

ItemNotFoundException while adding a NT_FOLDER node inside rootNode
-------------------------------------------------------------------

                 Key: JCR-3197
                 URL: https://issues.apache.org/jira/browse/JCR-3197
             Project: Jackrabbit Content Repository
          Issue Type: Bug
          Components: jackrabbit-core
    Affects Versions: 2.3.3
         Environment: Linux Ubuntu, Glassfish 3.1.1, JackRabbitJCA 2.3.3.
            Reporter: Gustavo Orair
            Priority: Critical

I got an Strange ItemNotFoundException exception while adding a NT_FOLDER to the root node.

The code just calls:
	session.getRootNode().addNode(folderName, NodeType.NT_FOLDER);

The addNode method failed with ItemNotFoundException.

Relevant Stack trace:
Caused by: javax.jcr.ItemNotFoundException?: 9ea3aca6-c1b8-4955-9ece-546fd12ba5f1

    at org.apache.jackrabbit.core.ItemManager?.getItemData(ItemManager?.java:384) ~[jackrabbit-core-2.3.3.jar:na]
    at org.apache.jackrabbit.core.ItemManager?.getNode(ItemManager?.java:669) ~[jackrabbit-core-2.3.3.jar:na]
    at org.apache.jackrabbit.core.ItemManager?.getNode(ItemManager?.java:647) ~[jackrabbit-core-2.3.3.jar:na]
    at org.apache.jackrabbit.core.NodeImpl?.addNode(NodeImpl?.java:1286) ~[jackrabbit-core-2.3.3.jar:na]
    at org.apache.jackrabbit.core.session.AddNodeOperation?.perform(AddNodeOperation?.java:111) ~[jackrabbit-core-2.3.3.jar:na]
    at org.apache.jackrabbit.core.session.AddNodeOperation?.perform(AddNodeOperation?.java:37) ~[jackrabbit-core-2.3.3.jar:na]
    at org.apache.jackrabbit.core.session.SessionState?.perform(SessionState?.java:216) ~[jackrabbit-core-2.3.3.jar:na]
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jukka Zitting (Resolved) (JIRA | 3 Jan 2012 13:04
Picon
Favicon

[Resolved] (JCR-2543) spi2dav : Query offset not respected


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

Jukka Zitting resolved JCR-2543.
--------------------------------

       Resolution: Fixed
    Fix Version/s: 2.4
         Assignee: Jukka Zitting

The test indeed passes now, so in revision 1226750 I removed them from the known.issues exclusion list.
Resolving as fixed.

> spi2dav : Query offset not respected
> ------------------------------------
>
>                 Key: JCR-2543
>                 URL: https://issues.apache.org/jira/browse/JCR-2543
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-jcr-server, jackrabbit-spi2dav, JCR 2.0, query
>    Affects Versions: 2.0
>            Reporter: angela
>            Assignee: Jukka Zitting
>             Fix For: 2.4
>
>         Attachments: patch_commit_ebebb62c3df0.patch
>
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
angela (Commented) (JIRA | 3 Jan 2012 16:14
Picon
Favicon

[Commented] (JCR-2859) Make open scoped locks recoverable


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

angela commented on JCR-2859:
-----------------------------

imo loosing a lock token should be considered a mistake with the API consumer rather than something that
occurs on a regular basis. while i am fine with providing a fallback in case the token is indeed lost, i am
therefore not convinced that having a group that is allowed to see all lock tokens in the repository would be
a wise move. apart from the fact that i consider this an edge case that should not be used on a regular
basis, being member of a given group will not guarantee that a given user is allowed to lock/unlock a
given node but only expose the lock token (in contrast to the admin).

thus, i'm in favor of the latest patch by julian. however, -1 for allow breaking locks based on group membership.

                
> Make open scoped locks recoverable
> ----------------------------------
>
>                 Key: JCR-2859
>                 URL: https://issues.apache.org/jira/browse/JCR-2859
>             Project: Jackrabbit Content Repository
>          Issue Type: New Feature
>          Components: locks
>    Affects Versions: 2.2
>            Reporter: Carsten Ziegeler
>            Assignee: Julian Reschke
>         Attachments: JCR-2859.diff, JCR-2859.patch, OpenScopeLockTest.java
(Continue reading)

Permalink | Reply | 0 comments |
headers
Julian Reschke (Commented) (JIRA | 3 Jan 2012 16:48
Picon
Favicon

[Commented] (JCR-2859) Make open scoped locks recoverable


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

Julian Reschke commented on JCR-2859:
-------------------------------------

+1 for starting with a small change (thus leaving it to admins).

That being said, maybe we should also try to mitigate the effects of lost lock tokens? For instance, by
changing the default timeout from "Infinity" to something reasonable? 

> Make open scoped locks recoverable
> ----------------------------------
>
>                 Key: JCR-2859
>                 URL: https://issues.apache.org/jira/browse/JCR-2859
>             Project: Jackrabbit Content Repository
>          Issue Type: New Feature
>          Components: locks
>    Affects Versions: 2.2
>            Reporter: Carsten Ziegeler
>            Assignee: Julian Reschke
>         Attachments: JCR-2859.diff, JCR-2859.patch, OpenScopeLockTest.java
>
>
> The lock tokens for open scoped locks are currently tied to the session which created the lock. If the
session dies (for whatever reason) there is no way to recover the lock and unlock the node.
> There is a theoretical way of adding the lock token to another session, but in most cases the lock token is
(Continue reading)

Permalink | Reply | 0 comments |
headers
angela (Commented) (JIRA | 3 Jan 2012 17:12
Picon
Favicon

[Commented] (JCR-2859) Make open scoped locks recoverable


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

angela commented on JCR-2859:
-----------------------------

> by changing the default timeout from "Infinity" to something reasonable

yes. that definitely makes sense... maybe we could even make the default timeout part of the workspace 
configuration as the preferred timeout may vary between different types of applications.
in any case we should clarify that as a general rule it is preferable to specify a reasonable timeout
suited for the situation when creating a new lock... LockManager#lock always takes a timeout hint, while 
Node.lock (which doesn't support it) has been deprecated as of JSR 283.

> Make open scoped locks recoverable
> ----------------------------------
>
>                 Key: JCR-2859
>                 URL: https://issues.apache.org/jira/browse/JCR-2859
>             Project: Jackrabbit Content Repository
>          Issue Type: New Feature
>          Components: locks
>    Affects Versions: 2.2
>            Reporter: Carsten Ziegeler
>            Assignee: Julian Reschke
>         Attachments: JCR-2859.diff, JCR-2859.patch, OpenScopeLockTest.java
>
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stefan Guggisberg (Commented) (JIRA | 3 Jan 2012 17:48
Picon
Favicon

[Commented] (JCR-3194) ConcurrentModificationException in CacheManager.


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

Stefan Guggisberg commented on JCR-3194:
----------------------------------------

only happens with log level set to DEBUG.

                
> ConcurrentModificationException in CacheManager.
> ------------------------------------------------
>
>                 Key: JCR-3194
>                 URL: https://issues.apache.org/jira/browse/JCR-3194
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>    Affects Versions: 2.3.4
>            Reporter: Mat Lowery
>
> Using the test code below, I was able to produce this stack:
> java.util.ConcurrentModificationException
> 	at java.util.WeakHashMap$HashIterator.nextEntry(WeakHashMap.java:762)
> 	at java.util.WeakHashMap$KeyIterator.next(WeakHashMap.java:795)
> 	at org.apache.jackrabbit.core.cache.CacheManager.logCacheStats(CacheManager.java:164)
> 	at org.apache.jackrabbit.core.cache.CacheManager.cacheAccessed(CacheManager.java:137)
> 	at org.apache.jackrabbit.core.cache.AbstractCache.recordCacheAccess(AbstractCache.java:122)
> 	at org.apache.jackrabbit.core.cache.ConcurrentCache.get(ConcurrentCache.java:122)
> 	at org.apache.jackrabbit.core.state.MLRUItemStateCache.retrieve(MLRUItemStateCache.java:71)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jukka Zitting (Created) (JIRA | 3 Jan 2012 17:48
Picon
Favicon

[Created] (JCR-3198) Broken handling of outer join results over davex

Broken handling of outer join results over davex
------------------------------------------------

                 Key: JCR-3198
                 URL: https://issues.apache.org/jira/browse/JCR-3198
             Project: Jackrabbit Content Repository
          Issue Type: Bug
          Components: jackrabbit-jcr-server, jackrabbit-spi2dav
    Affects Versions: 2.3.6
            Reporter: Jukka Zitting
            Assignee: Jukka Zitting

The davex join support added in JCR-3089 only works correctly when the join returns at least one row and none
of the returned rows contain null values for any of the selectors. This should be reasonably
straightforward to fix.

--
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
Permalink | Reply | 2 comments |

Gmane