jira | 1 Apr 2007 08:23
Picon
Favicon

Subscription: open issues

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

Key         Summary
JCR-831     NPE Exception Thrown By AbstractJournal During Commit Operation
            https://issues.apache.org/jira/browse/JCR-831
JCR-829     XPath character escape problem
            https://issues.apache.org/jira/browse/JCR-829
JCR-826     NodeTest.testAddNodeConstraintViolationExceptionUndefinedNodeType relies on
addNode(name, "nt:base")
            https://issues.apache.org/jira/browse/JCR-826
JCR-823     NamespaceRegistryTest makes assumptions about legal names
            https://issues.apache.org/jira/browse/JCR-823
JCR-822     TCK: Transfer of lock token should be tested using open-scoped locks
            https://issues.apache.org/jira/browse/JCR-822
JCR-820     Add support for query result highlighting
            https://issues.apache.org/jira/browse/JCR-820
JCR-817     TCK vs available property types
            https://issues.apache.org/jira/browse/JCR-817
JCR-813     TCK: testSaveMovedRefNode
            https://issues.apache.org/jira/browse/JCR-813
JCR-812     TCK: RestoreTest.testRestoreLabel
            https://issues.apache.org/jira/browse/JCR-812
JCR-811     SetPropertyAssumeTypeTest check for non-protected string array property
            https://issues.apache.org/jira/browse/JCR-811
JCR-808     Better error message for non-trivial nodetype changes
            https://issues.apache.org/jira/browse/JCR-808
JCR-802     Create a jackrabbit-site subproject
(Continue reading)

Jukka Zitting | 1 Apr 2007 21:37
Picon
Gravatar

Next Generation Persistence

Hi,

Based on some idle thinking I've written up a proposed model for next
gneration persistence in Jackrabbit. Instead of trying to explain the
whole idea in an email I've written a web page (with diagrams!) to
describe the model in more detail. You can find the model description
at http://jackrabbit.apache.org/dev/ngp.html (it's not linked in the
menu).

To summarize, the model I'm proposing brings a heavily abstracted
persistence layer up as the central focus point of the entire
repository architecture. The persistence model I'm proposing has
implications all the way to things like clustering implementation,
node type management, and session handling. In fact it would
revolutionarize almost all parts of Jackrabbit core. ;-)

On the other hand, instead of seeing the proposed model as a
revolution, it could be seen simply as a way to raise the prominence
of the ChangeLog class over the ItemState  model. Currently ItemStates
are the central concept in Jackrabbit and the ChangeLog class is just
a way to group together a set of ItemState changes. In the model I'm
proposing the ChangeLog, or a revision, would instead become the
central concept that governs not only read and write operations but
also things like transactions and observation to a much greater degree
than it does today.

There are a number of open issues with the proposal, especially how to
make it perform well and not use too much disk space, but I feel that
the model is interesting enough for serious consideration and perhaps
even early prototyping. I'm especially interested in hearing your
(Continue reading)

Tobias Bocanegra | 2 Apr 2007 09:12
Favicon
Gravatar

Re: Next Generation Persistence

hi jukka,
good work. very nice draft! i was working on a similar idea of a new
persistence model which went a bit further in some detailes and was
much alike how subversion stores it's content [0].
i see 2 additional fundamental paradigms that a persistence layer
should be based on:
1. copies must be very cheep (and just recorded as reference)
2. multiple (or all) workspaces must be able to live on the same
'persistence tree'

the first point basically describes a 'copy be reference'. this allows
very fast implementations of copy, checkin, restore, etc. the second
paradigm allows very fast inter-workspace operations, like clone,
copy, etc.

regards, toby

[0] http://subversion.tigris.org/design.html#server.fs.struct

On 4/1/07, Jukka Zitting <jukka.zitting <at> gmail.com> wrote:
> Hi,
>
> Based on some idle thinking I've written up a proposed model for next
> gneration persistence in Jackrabbit. Instead of trying to explain the
> whole idea in an email I've written a web page (with diagrams!) to
> describe the model in more detail. You can find the model description
> at http://jackrabbit.apache.org/dev/ngp.html (it's not linked in the
> menu).
>
> To summarize, the model I'm proposing brings a heavily abstracted
(Continue reading)

Marcel Reutegger (JIRA | 2 Apr 2007 09:53
Picon
Favicon

Resolved: (JCR-829) XPath character escape problem


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

Marcel Reutegger resolved JCR-829.
----------------------------------

    Resolution: Invalid

The space and ampersand are illegal characters in an XML name. You need to encode them as described in
section 6.4.3 of the JSR 170 specification.

//a_x0020__x0026__x0020_b

will work.

> XPath character escape problem
> ------------------------------
>
>                 Key: JCR-829
>                 URL: https://issues.apache.org/jira/browse/JCR-829
>             Project: Jackrabbit
>          Issue Type: Bug
>    Affects Versions: 1.2.2
>            Reporter: Xiaohua Lu
>
> I created a node with name "a & b" but when I tried to query it with 
> a &amp; b
> a & b
> a %26 b
(Continue reading)

Dominique Pfister (JIRA | 2 Apr 2007 10:43
Picon
Favicon

Resolved: (JCR-831) NPE Exception Thrown By AbstractJournal During Commit Operation


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

Dominique Pfister resolved JCR-831.
-----------------------------------

    Resolution: Fixed

This bug should have been fixed by the refactoring that took place while working on JCR-757: this version of
AbstractJournal still relied on an instance variable named "out" that may or (in exceptional cases) may
not have been initialized in the updateCreated/updatePrepared callback methods. While I could see
myself these errors now and then in the non-refactored version, they disappeared after the resolving of
JCR-757, which didn't make it into the 1.2.3 release, though.

> NPE Exception Thrown By AbstractJournal During Commit Operation
> ---------------------------------------------------------------
>
>                 Key: JCR-831
>                 URL: https://issues.apache.org/jira/browse/JCR-831
>             Project: Jackrabbit
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.2.2
>         Environment: Cluster of 2 JCR JVM's, Oracle DB
>            Reporter: Hemanta Gupta
>         Assigned To: Dominique Pfister
>
> This seems related to JCR-712 (which was apparently fixed in 1.2.2), but I see the following error
now-and-then on JR 1.2.2 (I'm using the DB based journal implementation with Oracle 10g):
(Continue reading)

Marcel Reutegger | 2 Apr 2007 11:16
Picon

poll on jcr query usage

Hi all,

my apologies for cross posting, but I'd like to get as many responses as 
possible from any kind of jackrabbit users on this topic.

I'd like to know what the preferred query language is that you are using, just 
to get a feeling where further development should go regarding query support in 
jackrabbit and JCR in general.

[ ] I primarily use XPath
[ ] I primarily use SQL
[ ] I use both XPath and SQL

and on a related topic:

If there was an API to construct a query I would ...

[ ] ... use it /instead/ of the existing XPath or SQL languages.
[ ] ... use it only for occasionally.
[ ] ... not use it at all.

Thank you for participating.

regards
  marcel

Marcel Reutegger | 2 Apr 2007 11:21
Picon

Re: poll on jcr query usage

Marcel Reutegger wrote:
[ ] I primarily use XPath
[ ] I primarily use SQL
[X] I use both XPath and SQL

If there was an API to construct a query I would ...

[ ] ... use it /instead/ of the existing XPath or SQL languages.
[X] ... use it only occasionally.
[ ] ... not use it at all.

Christoph Kiehl | 2 Apr 2007 11:28
Picon

Re: poll on jcr query usage

Marcel Reutegger wrote:

> [ ] I primarily use XPath
> [ ] I primarily use SQL
> [X] I use both XPath and SQL

I'm mostly using XPath, but SQL gives me better performance if I only need a 
particular property of a node in the result set.

> If there was an API to construct a query I would ...
> 
> [ ] ... use it /instead/ of the existing XPath or SQL languages.
> [X] ... use it only for occasionally.
> [ ] ... not use it at all.

Cheers,
Christoph

Przemo Pakulski (JIRA | 2 Apr 2007 11:51
Picon
Favicon

Created: (JCR-832) BundleDBPersistenceManager does not free blobStore resources

BundleDBPersistenceManager does not free blobStore resources
------------------------------------------------------------

                 Key: JCR-832
                 URL: https://issues.apache.org/jira/browse/JCR-832
             Project: Jackrabbit
          Issue Type: Bug
          Components: core
    Affects Versions: 1.2.3
            Reporter: Przemo Pakulski

When removing binary property from node or removing node containing binary property, resources occupied
by binary property are not freed (orphaned records remains in associated ${schemaObjectPrefix}BINVAL table).

David Nuescheler | 2 Apr 2007 12:10
Picon

better sql performance? [was: Re: poll on jcr query usage]

hi christoph,

> I'm mostly using XPath, but SQL gives me better performance if I only need a
> particular property of a node in the result set.
can you elaborate on this? it would be great to have more background
information on this...

afaik, there should not be any difference in performance, and for example
"//element(*, nt:resource)/( <at> jcr:lastModified)" should be equivalent to
"select jcr:lastModified from nt:resource"

regards,
david


Gmane