headers
jira | 1 Mar 2009 08:20
Picon
Favicon

Subscription: open issues

Issue Subscription
Filter: open issues (279 issues)
Open Issues for Apache Jackrabbit
Subscriber: jackrabbitdev

Key         Summary
JCR-2001    requestObjectCache not cleared in ObjectContentManager.getObjectIterator()
            https://issues.apache.org/jira/browse/JCR-2001
JCR-2000    Deadlock on concurrent commits
            https://issues.apache.org/jira/browse/JCR-2000
JCR-1999    Index curruption after XML import
            https://issues.apache.org/jira/browse/JCR-1999
JCR-1996    Handle date values in the far future or prevent these from being persisted
            https://issues.apache.org/jira/browse/JCR-1996
JCR-1991    please create osgi bundles for all jars
            https://issues.apache.org/jira/browse/JCR-1991
JCR-1987    Jackrabbit's lucene based query implementation does not check property constraints on the root node.
            https://issues.apache.org/jira/browse/JCR-1987
JCR-1986    XPathQueryBuilder treats ordering relations in property constraints as symmetrical
            https://issues.apache.org/jira/browse/JCR-1986
JCR-1980    Create a database utility package
            https://issues.apache.org/jira/browse/JCR-1980
JCR-1977    authentication order has changed from 1.4.x to 1.5.x
            https://issues.apache.org/jira/browse/JCR-1977
JCR-1975    Connection timed out IO Exceptions
            https://issues.apache.org/jira/browse/JCR-1975
JCR-1974    JSR 283: Evaluate Capabilities 
            https://issues.apache.org/jira/browse/JCR-1974
JCR-1973    OCM search features should retrieve objects also from VersionHistory objects
            https://issues.apache.org/jira/browse/JCR-1973
(Continue reading)

Permalink | Reply | 0 comments |
headers
vkrejcirik | 1 Mar 2009 11:59
Picon

javax.jcr.AccessDeniedException

I have problem with login to JCR for modify node over POST request.
I try to login over XmlHttpRequest (AJAX) and also with URL, but I get 
the same error.

my code in esb file:

part of form for modify currentNode property:
 <input type="hidden" name="currentNode <at> marshaler" 
value="EntireMarshaler"/>

next:  
var logger = document.getElementById("logger").value;
var url = "config?time=" + new Date().getTime();
var queryString = "logger=" + logger;
  xmlHttp = createXMLHttpRequest();
  xmlHttp.onreadystatechange = processSaveSettings;
  xmlHttp.open("POST", url, true, "admin", "admin");
  xmlHttp.setRequestHeader("Content-Type", 
"application/x-www-form-urlencoded;");
  xmlHttp.send(queryString);

log file:

org.apache.sling.servlets.post.impl.operations.ModifyOperation Exception 
during response processing. javax.jcr.AccessDeniedException: 
/content/servicemix/config: not allowed to modify item
 at 
org.apache.jackrabbit.core.ItemImpl.validateTransientItems(ItemImpl.java:483) 

 at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1205)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Michael Dürig (JIRA | 1 Mar 2009 14:31
Picon
Favicon

Commented: (JCR-1695) Improve and promote spi-logger


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

Michael Dürig commented on JCR-1695:
------------------------------------

AFAIR the 1.5. dependency is not a problem as it occurs in a place which would be an implementation of a spi
logger in the approach I suggested above. We could just enable/disable building of this particular
implementation depending on the build environment. 

> Improve and promote spi-logger
> ------------------------------
>
>                 Key: JCR-1695
>                 URL: https://issues.apache.org/jira/browse/JCR-1695
>             Project: Jackrabbit Content Repository
>          Issue Type: Improvement
>          Components: sandbox
>            Reporter: Michael Dürig
>            Priority: Minor
>
> The spi-logger is very useful for debugging an SPI implementation. However it only supports the
RepositoryService interface. Other SPI interfaces are not supported. Also writing log information as
string seems a bit restrictive to me. Finally it is not included in the jackrabbit-spi package which
introduces an additional dependency for debugging. 
> I therefore suggest:
> - Add support for the other major SPI interfaces 
> - Replace the current way of logging a String to a Writer instance by a more versatile mechanism (i.e.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Dürig (JIRA | 1 Mar 2009 14:35
Picon
Favicon

Commented: (JCR-1695) Improve and promote spi-logger


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

Michael Dürig commented on JCR-1695:
------------------------------------

I will be back on March 9

> Improve and promote spi-logger
> ------------------------------
>
>                 Key: JCR-1695
>                 URL: https://issues.apache.org/jira/browse/JCR-1695
>             Project: Jackrabbit Content Repository
>          Issue Type: Improvement
>          Components: sandbox
>            Reporter: Michael Dürig
>            Priority: Minor
>
> The spi-logger is very useful for debugging an SPI implementation. However it only supports the
RepositoryService interface. Other SPI interfaces are not supported. Also writing log information as
string seems a bit restrictive to me. Finally it is not included in the jackrabbit-spi package which
introduces an additional dependency for debugging. 
> I therefore suggest:
> - Add support for the other major SPI interfaces 
> - Replace the current way of logging a String to a Writer instance by a more versatile mechanism (i.e.
clients have to provide an interface which consumes more structured log data). 
> - Provide some default implementation for the above mechanism (i.e. writing to a file, writing to a slf4j
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Dürig (JIRA | 1 Mar 2009 14:47
Picon
Favicon

Updated: (JCR-1695) Improve and promote spi-logger


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

Michael Dürig updated JCR-1695:
-------------------------------

    Comment: was deleted

> Improve and promote spi-logger
> ------------------------------
>
>                 Key: JCR-1695
>                 URL: https://issues.apache.org/jira/browse/JCR-1695
>             Project: Jackrabbit Content Repository
>          Issue Type: Improvement
>          Components: sandbox
>            Reporter: Michael Dürig
>            Priority: Minor
>
> The spi-logger is very useful for debugging an SPI implementation. However it only supports the
RepositoryService interface. Other SPI interfaces are not supported. Also writing log information as
string seems a bit restrictive to me. Finally it is not included in the jackrabbit-spi package which
introduces an additional dependency for debugging. 
> I therefore suggest:
> - Add support for the other major SPI interfaces 
> - Replace the current way of logging a String to a Writer instance by a more versatile mechanism (i.e.
clients have to provide an interface which consumes more structured log data). 
> - Provide some default implementation for the above mechanism (i.e. writing to a file, writing to a slf4j
based logger, writing to the console...)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Dürig (JIRA | 1 Mar 2009 15:03
Picon
Favicon

Commented: (JCR-1012) JCR2SPI: Optimization for Item.refresh and Session.refresh


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

Michael Dürig commented on JCR-1012:
------------------------------------

I think we should not add yet another method to the RepositoryService interface for this.
RepositoryService is already huge and hard to implement for non jcr persistent layers. In general there
will be probably not much gain from such a method since most implementations wouldn't be able to provide
useful information. 

I was thinking of a different approach however: instead of invalidating each item in the respective
sub-tree (which might be an expensive operation) why not just mark the root of the sub-tree as
invalidated. Such a mark would include some sort of a time stamp. Also we would time stamp individual items
with the time they where resolved. When an item is access, it would check if its resolution time stamp is
older than the latest invalidation time stamp. If so, it checks whether the invalidation applies to it at
all (by traversing up the path) and if so it would re-resolve itself. In any case its resolution time stamp
will be updated. 

This approach would make invalidation much cheaper without putting much additional load to simple item
access. Moreover most of the additional load (traversing up the path) only applies when an invalidation
is pending.

> JCR2SPI: Optimization for Item.refresh and Session.refresh
> ----------------------------------------------------------
>
>                 Key: JCR-1012
>                 URL: https://issues.apache.org/jira/browse/JCR-1012
(Continue reading)

Permalink | Reply | 0 comments |
headers
Martijn Hendriks (JIRA | 2 Mar 2009 09:50
Picon
Favicon

Resolved: (JCR-1117) Bundle cache is not rolled back when the storage of a ChangeLog fails


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

Martijn Hendriks resolved JCR-1117.
-----------------------------------

    Resolution: Fixed
      Assignee:     (was: Martijn Hendriks)

> Bundle cache is not rolled back when the storage of a ChangeLog fails
> ---------------------------------------------------------------------
>
>                 Key: JCR-1117
>                 URL: https://issues.apache.org/jira/browse/JCR-1117
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-core
>    Affects Versions: 1.3, 1.4, 1.5.0, 1.5.2
>            Reporter: Martijn Hendriks
>         Attachments: JCR-1117-v2.patch, JCR-1117-v3.patch, JCR-1117.patch, stacktrace.txt
>
>
> The bundle cache in the bundle persistence managers is not restored to its old state when the
AbstractBundlePersistenceManager.store(ChangeLog changeLog) method throws an exception. If, for
instance, the storage of references fails then the
AbstractBundlePersistenceManager.putBundle(NodePropBundle bundle) method has already been
called for all modified bundles. Because of the connection rollback, the bundle cache will be
out-of-sync with the persistent state. As a result, the SharedItemStateManager will have an incorrect
view of the persistent state.
(Continue reading)

Permalink | Reply | 0 comments |
headers
jukka.zitting | 2 Mar 2009 10:07
Picon
Gravatar

Analytics jackrabbit.apache.org 200902

This is an automated monthly report of the Google Analytics statistics for  
the Apache Jackrabbit web site (http://jackrabbit.apache.org/).

Please use dev <at> jackrabbit.apache.org for any questions and comments  
regarding these statistics.

----------------------------------------
This is a monthly email from Google Analytics.  You received this email  
because someone requested the report to be sent to you.  You will receive  
the next report during the first days of next month.  If you would like to  
opt-out of future email delivery from Google Analytics, please visit  
https://www.google.com/analytics/reporting/optout?token=Oap86h8BAAA.kEk_finFfmWe6pvC3xfL4VgpcLLRQ0VNZp8EvVpeUv1H52TW3Ke28S4-M2uZsQuAgY9Xe1bGTHbGsujsV6kQuw.aT9GnbH0CSRVhM3Kks4yKg&email=dev%40jackrabbit.apache.org&hl=en_US
Attachment (Analytics_jackrabbit.apache.org_200902.pdf): application/pdf, 140 KiB
Permalink | Reply | 0 comments |
headers
Jukka Zitting (JIRA | 2 Mar 2009 11:58
Picon
Favicon

Updated: (JCR-2000) Deadlock on concurrent commits


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

Jukka Zitting updated JCR-2000:
-------------------------------

    Attachment: JCR-2000.patch

Attached a patch that solves the issue for environments where the transaction manager does not use
separate threads for preparing and committing a transaction (see JCR-1334). Support for JCR-1334
requires updating also the version manager lock to support switching the lock ownership from one thread
to another.

> Deadlock on concurrent commits
> ------------------------------
>
>                 Key: JCR-2000
>                 URL: https://issues.apache.org/jira/browse/JCR-2000
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-core, transactions
>    Affects Versions: 1.5.3
>            Reporter: Jukka Zitting
>            Assignee: Jukka Zitting
>             Fix For: 1.5.4
>
>         Attachments: JCR-2000.patch
>
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jukka Zitting (JIRA | 2 Mar 2009 12:56
Picon
Favicon

Updated: (JCR-2000) Deadlock on concurrent commits


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

Jukka Zitting updated JCR-2000:
-------------------------------

    Attachment: JCR-2000.patch

Here's a new version of the patch that solves also the JCR-1334 issues. I'll run some more tests on it before
committing to trunk and the 1.5 branch.

> Deadlock on concurrent commits
> ------------------------------
>
>                 Key: JCR-2000
>                 URL: https://issues.apache.org/jira/browse/JCR-2000
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-core, transactions
>    Affects Versions: 1.5.3
>            Reporter: Jukka Zitting
>            Assignee: Jukka Zitting
>             Fix For: 1.5.4
>
>         Attachments: JCR-2000.patch, JCR-2000.patch
>
>
> As reported in the followup to JCR-1979, there's a case where two transactions may be concurrently inside
a commit. This is bad as it breaks the main assumption in
(Continue reading)

Permalink | Reply | 0 comments |

Gmane