from:"angela \(JIRA\)"

[jira] [Created] (OAK-343) Session.getNodeByUUID requires save call

2012-09-26 Thread angela (JIRA)

angela created OAK-343:
--

 Summary: Session.getNodeByUUID requires save call
 Key: OAK-343
 URL: https://issues.apache.org/jira/browse/OAK-343
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: core, jcr
Reporter: angela


while adding mix:referenceable to a new node immediately assigns a 
uuid and makes the node referenceable, session.getNodeByUUID only works
after saving the changes.

the following test illustrates this behavior:

@Test
public void getNodeByUUID() throws RepositoryException {
Node node = getNode(/foo).addNode(boo);
node.addMixin(JcrConstants.MIX_REFERENCEABLE);

assertTrue(node.isNodeType(JcrConstants.MIX_REFERENCEABLE));
String uuid = node.getUUID();
assertNotNull(uuid);
assertEquals(uuid, node.getIdentifier());

Node nAgain = node.getSession().getNodeByUUID(uuid);
assertTrue(nAgain.isSame(node));
  
assertTrue(nAgain.isSame(node.getSession().getNodeByIdentifier(uuid)));
}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-343) Session.getNodeByUUID requires save call

2012-09-26 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13463663#comment-13463663
 ] 

angela commented on OAK-343:


the same applies to IdentifierManager#getTree and main issue behind is that 
uuid/identifier resolutions uses
the query which relies on an index that is only populated after changes have 
been saved.

 Session.getNodeByUUID requires save call
 

 Key: OAK-343
 URL: https://issues.apache.org/jira/browse/OAK-343
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: core, jcr
Reporter: angela

 while adding mix:referenceable to a new node immediately assigns a 
 uuid and makes the node referenceable, session.getNodeByUUID only works
 after saving the changes.
 the following test illustrates this behavior:
 @Test
 public void getNodeByUUID() throws RepositoryException {
 Node node = getNode(/foo).addNode(boo);
 node.addMixin(JcrConstants.MIX_REFERENCEABLE);
 assertTrue(node.isNodeType(JcrConstants.MIX_REFERENCEABLE));
 String uuid = node.getUUID();
 assertNotNull(uuid);
 assertEquals(uuid, node.getIdentifier());
 Node nAgain = node.getSession().getNodeByUUID(uuid);
 assertTrue(nAgain.isSame(node));
   
 assertTrue(nAgain.isSame(node.getSession().getNodeByIdentifier(uuid)));
 }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-343) Session.getNodeByUUID requires save call

2012-09-26 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13463745#comment-13463745
 ] 

angela commented on OAK-343:


well, since the uuid is created immediately and the node is referenceable as 
well,
i would expect that i could also get it by uuid.

second we have an issue with a backwards compatible user mgt implementation:
a NEW user used to be accessible by for the editing session even before 
commiting
it. second, since the tree object isn't stable it needs to be re-accessed during
the life-time of a user object. searching isn't possible but i would expect that
lookup be id was possible.

 Session.getNodeByUUID requires save call
 

 Key: OAK-343
 URL: https://issues.apache.org/jira/browse/OAK-343
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: core, jcr
Reporter: angela

 while adding mix:referenceable to a new node immediately assigns a 
 uuid and makes the node referenceable, session.getNodeByUUID only works
 after saving the changes.
 the following test illustrates this behavior:
 @Test
 public void getNodeByUUID() throws RepositoryException {
 Node node = getNode(/foo).addNode(boo);
 node.addMixin(JcrConstants.MIX_REFERENCEABLE);
 assertTrue(node.isNodeType(JcrConstants.MIX_REFERENCEABLE));
 String uuid = node.getUUID();
 assertNotNull(uuid);
 assertEquals(uuid, node.getIdentifier());
 Node nAgain = node.getSession().getNodeByUUID(uuid);
 assertTrue(nAgain.isSame(node));
   
 assertTrue(nAgain.isSame(node.getSession().getNodeByIdentifier(uuid)));
 }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OAK-343) Session.getNodeByUUID requires save call

2012-09-26 Thread angela (JIRA)


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

angela updated OAK-343:
---

Description: 
while adding mix:referenceable to a new node immediately assigns a 
uuid and makes the node referenceable, session.getNodeByUUID only works
after saving the changes.

the following test illustrates this behavior:

@Test
public void getNodeByUUID() throws RepositoryException {
   Node node = getNode(/foo).addNode(boo);
   node.addMixin(JcrConstants.MIX_REFERENCEABLE);

   assertTrue(node.isNodeType(JcrConstants.MIX_REFERENCEABLE));
   String uuid = node.getUUID();
   assertNotNull(uuid);
   assertEquals(uuid, node.getIdentifier());

   Node nAgain = node.getSession().getNodeByUUID(uuid);
   assertTrue(nAgain.isSame(node));
   assertTrue(nAgain.isSame(node.getSession().getNodeByIdentifier(uuid)));
}

  was:
while adding mix:referenceable to a new node immediately assigns a 
uuid and makes the node referenceable, session.getNodeByUUID only works
after saving the changes.

the following test illustrates this behavior:

@Test
public void getNodeByUUID() throws RepositoryException {
Node node = getNode(/foo).addNode(boo);
node.addMixin(JcrConstants.MIX_REFERENCEABLE);

assertTrue(node.isNodeType(JcrConstants.MIX_REFERENCEABLE));
String uuid = node.getUUID();
assertNotNull(uuid);
assertEquals(uuid, node.getIdentifier());

Node nAgain = node.getSession().getNodeByUUID(uuid);
assertTrue(nAgain.isSame(node));
  
assertTrue(nAgain.isSame(node.getSession().getNodeByIdentifier(uuid)));
}


 Session.getNodeByUUID requires save call
 

 Key: OAK-343
 URL: https://issues.apache.org/jira/browse/OAK-343
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: core, jcr
Reporter: angela

 while adding mix:referenceable to a new node immediately assigns a 
 uuid and makes the node referenceable, session.getNodeByUUID only works
 after saving the changes.
 the following test illustrates this behavior:
 @Test
 public void getNodeByUUID() throws RepositoryException {
Node node = getNode(/foo).addNode(boo);
node.addMixin(JcrConstants.MIX_REFERENCEABLE);
assertTrue(node.isNodeType(JcrConstants.MIX_REFERENCEABLE));
String uuid = node.getUUID();
assertNotNull(uuid);
assertEquals(uuid, node.getIdentifier());
Node nAgain = node.getSession().getNodeByUUID(uuid);
assertTrue(nAgain.isSame(node));
assertTrue(nAgain.isSame(node.getSession().getNodeByIdentifier(uuid)));
 }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-250) Enforce jcr constraints for 'protected' items

2012-09-26 Thread angela (JIRA)

[
https://issues.apache.org/jira/browse/OAK-250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13463789#comment-13463789
]

angela commented on OAK-250:

IMO the protection of items in terms of JCR has nothing to do with access
control.
thus the approach that would allow admin/system but not other users looks a bit
awkward to me.

an alternative approach was:
- enforce item protection on oak-jcr based on the node type definitions:
i.e. add an extra check for regular JCR API write operations if the target
items are
protected.
- not enforcing item protection in oak-core but rather cover this with the
commit-validator concept that was in charge of making sure that content of
protected
items was reasonable, correct in terms of node type constraints...

the reason for this approach is that a protected item is not defined to be
read-only.
instead the goal of the protection is to force the usage of additional API
(versioning,
access control) that may enforce extra constraints or actually knows what to do
in term of item-modification when e.g. a node is checked-in. that logic is
executed
in the corresponding API implementation but validation can (and probably
should) be
delegated to oak-core.

similarly: if someone is allowed to write protected items by calling the
corresponding
API methods is defined by specific permissions (e.g. jcr:versionManagement
privilege)
that again can be checked as part of the commit validation.

Enforce jcr constraints for 'protected' items
-

Key: OAK-250
URL: https://issues.apache.org/jira/browse/OAK-250
Project: Jackrabbit Oak
Issue Type: Sub-task
Components: jcr
Reporter: angela

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-41) Initial repository setup

2012-10-02 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13467565#comment-13467565
 ] 

angela commented on OAK-41:
---

please note that 

- initial users
- initial permissions

are depending on the configured setup and implementation. we cannot
assume that users or permissions are stored in one particular way.

the same applies for those parts of :unique constraint that are
bound to a particular implementation (i added a FIXME there).

 Initial repository setup
 

 Key: OAK-41
 URL: https://issues.apache.org/jira/browse/OAK-41
 Project: Jackrabbit Oak
  Issue Type: Task
  Components: core
Reporter: angela
 Attachments: OAK-41-initial-proposal.patch


 upon the initial creation of a JCR repository the associated SPI layer 
 (oak-core) should 
 take care of setting up the corresponding MK-instance. this includes 
 (incomplete list):
 - create the jcr repo (not sure what that means in terms of mk-implementation)
 - create the jcr:system node (unique for the repository, across workspaces) 
 - create the default workspace (- name from config)
 - create the root node of the default workspace 
 in addition the repository would need to have access to the following
 information (maybe also mk-nodes underneath jcr:system ??)
 - built-in node types
 - built-in namespace
 - built-in privileges
 - built-in permissions
 - repository configuration (can that be stored in the mk?)
 as far as the workspace is concerned a functional repository would in 
 addition need to have:
 - build-in users (based on some sort of configuration)
 - workspace configuration

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (OAK-354) Support node types and node type inheritance in query

2012-10-02 Thread angela (JIRA)

angela created OAK-354:
--

 Summary: Support node types and node type inheritance in query
 Key: OAK-354
 URL: https://issues.apache.org/jira/browse/OAK-354
 Project: Jackrabbit Oak
  Issue Type: Sub-task
  Components: core
Reporter: angela


i recently tried to run some user mgt related test and found that
they might be failing due to a query that restricts the results
to nodes of a particular base node type.

adding this sub-task as a reminder and to be able to cover dependencies
here in jira



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-169) Support orderable nodes

2012-10-04 Thread angela (JIRA)

[
https://issues.apache.org/jira/browse/OAK-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13469262#comment-13469262
]

angela commented on OAK-169:

that's a perfect move. i definitely prefer that over the previous approach that
delegated
the complete reordering to the implementation on top of oak. similarly i think
having
an extra api method to cover reordering of nodes makes sense... for the save of
flexibility
i would however prefer a more general method (reorder() or similar)... while
'orderBefore'
has a 1:1 match with the jcr api, i don't particularly like it as it feels a bit
awkward to use, when you want to move something to the start or to the end.

Support orderable nodes
---

Key: OAK-169
URL: https://issues.apache.org/jira/browse/OAK-169
Project: Jackrabbit Oak
Issue Type: New Feature
Components: jcr
Reporter: Jukka Zitting

There are JCR clients that depend on the ability to explicitly specify the
order of child nodes. That functionality is not included in the MicroKernel
tree model, so we need to implement it either in oak-core or oak-jcr using
something like an extra (hidden) {{oak:childOrder}} property that records the
specified ordering of child nodes. A multi-valued string property is probably
good enough for this.

[jira] [Created] (OAK-369) missing support for relative path consisting of parent-element

2012-10-09 Thread angela (JIRA)

angela created OAK-369:
--

 Summary: missing support for relative path consisting of 
parent-element
 Key: OAK-369
 URL: https://issues.apache.org/jira/browse/OAK-369
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: jcr
Reporter: angela
Priority: Minor
 Fix For: 0.3


Persisting paths in properties of type path requires that we can round-trip 
relative JCR paths through the oak-core persistence, such as

  ../foobar

or

  .

Note that these paths still need prefix remapping so that they are stable with 
respect to session prefix remappings.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OAK-369) missing support for relative path consisting of parent-element

2012-10-09 Thread angela (JIRA)


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

angela updated OAK-369:
---

Fix Version/s: (was: 0.3)

 missing support for relative path consisting of parent-element
 --

 Key: OAK-369
 URL: https://issues.apache.org/jira/browse/OAK-369
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: jcr
Reporter: angela
Priority: Minor

 could not reopen OAK-95 - cloning.
 during testing of user-mgt api found that relpath consisting of a single 
 parent element doesn't work (but used to):
 @Test
 public void getNode3() throws RepositoryException {
 Node node = getNode(/foo);
 Node root = node.getNode(..);
 assertNotNull(root);
 assertEquals(, root.getName());
 assertTrue(/.equals(root.getPath()));
 }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OAK-369) missing support for relative path consisting of parent-element

2012-10-10 Thread angela (JIRA)


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

angela updated OAK-369:
---

Description: 
could not reopen OAK-95 - cloning.
during testing of user-mgt api found that relpath consisting of a single parent 
element doesn't work (but used to):

{code}
@Test
public void getNode3() throws RepositoryException {
Node node = getNode(/foo);
Node root = node.getNode(..);
assertNotNull(root);
assertEquals(, root.getName());
assertTrue(/.equals(root.getPath()));
}
:

{code}

  was:
could not reopen OAK-95 - cloning.
during testing of user-mgt api found that relpath consisting of a single parent 
element doesn't work (but used to):

@Test
public void getNode3() throws RepositoryException {
Node node = getNode(/foo);
Node root = node.getNode(..);
assertNotNull(root);
assertEquals(, root.getName());
assertTrue(/.equals(root.getPath()));
}


 missing support for relative path consisting of parent-element
 --

 Key: OAK-369
 URL: https://issues.apache.org/jira/browse/OAK-369
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: jcr
Reporter: angela
Priority: Minor

 could not reopen OAK-95 - cloning.
 during testing of user-mgt api found that relpath consisting of a single 
 parent element doesn't work (but used to):
 {code}
 @Test
 public void getNode3() throws RepositoryException {
 Node node = getNode(/foo);
 Node root = node.getNode(..);
 assertNotNull(root);
 assertEquals(, root.getName());
 assertTrue(/.equals(root.getPath()));
 }
 :
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (OAK-370) Creating Root is too expensive

2012-10-10 Thread angela (JIRA)

angela created OAK-370:
--

 Summary: Creating Root is too expensive
 Key: OAK-370
 URL: https://issues.apache.org/jira/browse/OAK-370
 Project: Jackrabbit Oak
  Issue Type: Improvement
  Components: core
Reporter: angela


see 
http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201210.mbox/%3c50741032.4050...@adobe.com%3E

imo creating a new root instance (and thus creating a new session) should
be for free. even creating a root instance that is just used for reading should 
be cheap. all kind of extra effort associated with a potential write operation 
should be postponed until write does really happen.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (OAK-380) Define conversion of property values

2012-10-17 Thread angela (JIRA)

angela created OAK-380:
--

 Summary: Define conversion of property values
 Key: OAK-380
 URL: https://issues.apache.org/jira/browse/OAK-380
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: core
Reporter: angela


i just run into the situation of converting a propertystate's value
of type Date to a Long, which currently throws numberformatexception.

while i can work around this, i think we should come up with a clear
definition on value conversion provided by oak-api. the only thing i
found so far was the description in PropertyState#getValue that claims
that a conversion in done but not which conversions are supported.
unless otherwise specified i had silently expected that simple jcr-conversions
would work.



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OAK-386) Define equality or 'sameness' of Tree objects

2012-10-18 Thread angela (JIRA)


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

angela updated OAK-386:
---

Component/s: core

 Define equality or 'sameness' of Tree objects
 -

 Key: OAK-386
 URL: https://issues.apache.org/jira/browse/OAK-386
 Project: Jackrabbit Oak
  Issue Type: Improvement
  Components: core
Reporter: angela

 i think the Tree interface and implementation should define what exactly
 can be expected with regard to equality of 2 Tree objects. Since the
 tree is an oak-level correspondent of the jcr Node we may even take
 'sameness' into consideration as it is defined by Item#isSame. That doesn't
 necessarily mean that we need this on the API but IMO the interface 
 description
 should mention the contract (equality across repositories, sessions, 
 workspaces...).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (OAK-386) Define equality or 'sameness' of Tree objects

2012-10-18 Thread angela (JIRA)

angela created OAK-386:
--

 Summary: Define equality or 'sameness' of Tree objects
 Key: OAK-386
 URL: https://issues.apache.org/jira/browse/OAK-386
 Project: Jackrabbit Oak
  Issue Type: Improvement
Reporter: angela


i think the Tree interface and implementation should define what exactly
can be expected with regard to equality of 2 Tree objects. Since the
tree is an oak-level correspondent of the jcr Node we may even take
'sameness' into consideration as it is defined by Item#isSame. That doesn't
necessarily mean that we need this on the API but IMO the interface description
should mention the contract (equality across repositories, sessions, 
workspaces...).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (OAK-387) Clarify behavior/state of Root and Tree after calling ContentSession#close()

2012-10-18 Thread angela (JIRA)

angela created OAK-387:
--

 Summary: Clarify behavior/state of Root and Tree after calling 
ContentSession#close()
 Key: OAK-387
 URL: https://issues.apache.org/jira/browse/OAK-387
 Project: Jackrabbit Oak
  Issue Type: Improvement
  Components: core
Reporter: angela


quickly discussed this topic with jukka today in the office.
as far as i know the API contract does currently not specify what happens
to (the state of) a Root or Tree once the ContentSession has been closed.

if i am not mistaken, the current implementation would just loose 
the permissions that were granted to the original subject... but that's
rather a coincidence (and i didn't test it to verify that's really the case)

possible solutions could be:
- upon session closure the root/tree becomes invalid (invalidstate) and throws
- the root/tree are still valid but doesn't have the original permissions
  any more - default permissions for empty-subject would apply
- ...

whatever solution we may prefer in the end, i think that API contract should
state the expected behavior (even if it was undefined) and we should have 
tests verifying the current implementation does what we think it should do.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (OAK-395) Inconsistency in Node#setProperty in case of null value

2012-10-25 Thread angela (JIRA)


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

angela reassigned OAK-395:
--

Assignee: angela

 Inconsistency in Node#setProperty in case of null value
 ---

 Key: OAK-395
 URL: https://issues.apache.org/jira/browse/OAK-395
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: jcr
Reporter: angela
Assignee: angela

 Setting a null value to a single valued property will result
 in 'null' being returned while executing the same on a multivalued
 property will return the removed property.
 jr2 returned the removed property in both cases as far as i 
 remember and i would suggest that we don't change that behavior. in
 particular since the specification IMO doesn't allow to return
 null-values for these methods.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (OAK-395) Inconsistency in Node#setProperty in case of null value

2012-10-25 Thread angela (JIRA)

angela created OAK-395:
--

 Summary: Inconsistency in Node#setProperty in case of null value
 Key: OAK-395
 URL: https://issues.apache.org/jira/browse/OAK-395
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: jcr
Reporter: angela


Setting a null value to a single valued property will result
in 'null' being returned while executing the same on a multivalued
property will return the removed property.

jr2 returned the removed property in both cases as far as i 
remember and i would suggest that we don't change that behavior. in
particular since the specification IMO doesn't allow to return
null-values for these methods.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-250) Enforce jcr constraints for 'protected' items

2012-10-30 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13486786#comment-13486786
 ] 

angela commented on OAK-250:


Revision: 1403656

- move definition and effective node type related code to nodetype plugin 
package
- remove duplicate code in NodeTypeImpl
- add missing test for protection in NodeType#canSetProperty
- add TODO/FIXME comments in NodeTypeImpl for code that seems insufficient to me

the test for items being protected is still missing with
- Session#move
- Workspace#move
- Workspace#copy
- Workspace#clone


 Enforce jcr constraints for 'protected' items
 -

 Key: OAK-250
 URL: https://issues.apache.org/jira/browse/OAK-250
 Project: Jackrabbit Oak
  Issue Type: Sub-task
  Components: jcr
Reporter: angela



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-395) Inconsistency in Node#setProperty in case of null value

2012-10-30 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13486881#comment-13486881
 ] 

angela commented on OAK-395:


as long as we don't return null, i am fine with any solution.

 Inconsistency in Node#setProperty in case of null value
 ---

 Key: OAK-395
 URL: https://issues.apache.org/jira/browse/OAK-395
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: jcr
Reporter: angela
Assignee: angela

 Setting a null value to a single valued property will result
 in 'null' being returned while executing the same on a multivalued
 property will return the removed property.
 jr2 returned the removed property in both cases as far as i 
 remember and i would suggest that we don't change that behavior. in
 particular since the specification IMO doesn't allow to return
 null-values for these methods.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-411) Validator for node type management

2012-10-31 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13487633#comment-13487633
 ] 

angela commented on OAK-411:


added initial draft of RegistrationValidator in revision 1404049. it currently 
still has plenty of
TODOs and currently only prevents un-registration of built-in node types in 
order to
be able to resolve the hack/todo in ReadWriteNodeTypeManager.


 Validator for node type management
 --

 Key: OAK-411
 URL: https://issues.apache.org/jira/browse/OAK-411
 Project: Jackrabbit Oak
  Issue Type: Sub-task
  Components: core
Reporter: angela

 while working on the protected item definitions i realized that
 we don't have any validation for node type management operations
 on the oak-level.
 IMO there should be a separate validator for content changes underneath
 /jcr:system/jcr:nodeTypes with the following characteristics:
 - prevent removal of built-in node types
 - assert validity of node type definition
 - prevent changes to registered node types that would render
   existing nodes invalid

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-250) Enforce jcr constraints for 'protected' items

2012-10-31 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13487731#comment-13487731
 ] 

angela commented on OAK-250:


btw: NodeType#getSuperType is something different (or maybe a subtask)... the 
effective 
node type also should take mixin types into account not just the primary type.

 Enforce jcr constraints for 'protected' items
 -

 Key: OAK-250
 URL: https://issues.apache.org/jira/browse/OAK-250
 Project: Jackrabbit Oak
  Issue Type: Sub-task
  Components: jcr
Reporter: angela



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (OAK-250) Enforce jcr constraints for 'protected' items

2012-10-31 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13487721#comment-13487721
 ] 

angela edited comment on OAK-250 at 10/31/12 1:01 PM:
--

as you might have seen there is a TODO there and there is another TODO in the 
TypeValidator you
created earlier that again provides the same functionality (and added a third 
time the exact same
but buggy code) and in effect defines an effectivenodetype. i just didn't 
want to change 
too much to the original logic that's why i didn't  introduce an 
'EffectiveNodeType' class which 
IMO was much better than having the provider return IterableNodeType'.

feel free to clean up any remaining redundancies but please be aware that it 
wasn't me
introducing the redundancy... you may not have notice before, because the code 
was just
spread all over the place. svn annotate will be your friend ;-)

  was (Author: anchela):
as you might have seen there is a TODO there and there is another TODO in 
the TypeValidator you
created earlier that again provides the same functionality (and added a third 
time the exact same
- but buggy - code) and in effect defines an effectivenodetype. i just didn't 
want to change 
too much to the original logic that's why i didn't  introduce an 
'EffectiveNodeType' class which 
IMO was much better  than having the provider return IterableNodeType'.
  
 Enforce jcr constraints for 'protected' items
 -

 Key: OAK-250
 URL: https://issues.apache.org/jira/browse/OAK-250
 Project: Jackrabbit Oak
  Issue Type: Sub-task
  Components: jcr
Reporter: angela



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-411) Validator for node type management

2012-10-31 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13488037#comment-13488037
 ] 

angela commented on OAK-411:


just one additional comment:

currently there is some validation done in ReadWriteNodeTypeManager before
registration or unregistration of nodetypes. IMHO that needs to be done
in the RegistrationValidator (or however that validator is called in the
end) as we also have to make sure that no invalid node type definitions are 
created or modified by means of using oak-api (circumventing jcr node type 
management API)... where or not some preliminary validations
should be done in the NodeTypeManager methods upfront is most probably a
question of preference... however, i think it is mandatory upon commit.

 Validator for node type management
 --

 Key: OAK-411
 URL: https://issues.apache.org/jira/browse/OAK-411
 Project: Jackrabbit Oak
  Issue Type: Sub-task
  Components: core
Reporter: angela

 while working on the protected item definitions i realized that
 we don't have any validation for node type management operations
 on the oak-level.
 IMO there should be a separate validator for content changes underneath
 /jcr:system/jcr:nodeTypes with the following characteristics:
 - prevent removal of built-in node types
 - assert validity of node type definition
 - prevent changes to registered node types that would render
   existing nodes invalid

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-414) Importing protected properties

2012-11-01 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13488792#comment-13488792
 ] 

angela commented on OAK-414:


in revision: 1404623 i added another package to oak-spi containing a slightly 
modified
version of protected item import facility that we used to have in jackrabbit 
core. in
particular i completely dropped the distinction between methods used for 
workspace
vs session import.

in addition i modified the security related configurations that they can expose
their implementation specific importer functionality.

currently this code is not used in the XML-importer which IMO needs some major
refactoring in order to really provide support for the full JCR import 
functionality.
in a next step, i would verify if the initial draft was suitable to cover
user information.

feel free to adjust or modify it, if there is something missing or not suitable.


 Importing protected properties
 --

 Key: OAK-414
 URL: https://issues.apache.org/jira/browse/OAK-414
 Project: Jackrabbit Oak
  Issue Type: Sub-task
  Components: jcr
Reporter: angela

 for backwards compatibility with jackrabbit we should also implement
 the ability to import protected items.
 while import version content is most probably unique and system defined,
 there are quite some areas like user management and access control that
 need to be pluggable and thus the particular import behavior should be
 defined by the corresponding implementation.
 i envision this to work in a similar way than the implementation
 specific validators.
 steps to get there include:
 - properly setup the xml-import such that it recognizes protected items
   and calls the configured protected-item-importers.
 - allow to plugin implementation specific extensions
 - define an interface for that protected item import.
 regarding the latest part: in contrast to jackrabbit core, where we had
 just the JCR API at hand i would suggest to setup those special importers
 such that they can operate both on the JCR API (session and extensions)
 and on the OAK API giving the implementation more flexibility on how
 to actually treat the import.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OAK-414) Importing protected properties and nodes

2012-11-02 Thread angela (JIRA)


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

angela updated OAK-414:
---

Summary: Importing protected properties and nodes  (was: Importing 
protected properties)

 Importing protected properties and nodes
 

 Key: OAK-414
 URL: https://issues.apache.org/jira/browse/OAK-414
 Project: Jackrabbit Oak
  Issue Type: Sub-task
  Components: jcr
Reporter: angela

 for backwards compatibility with jackrabbit we should also implement
 the ability to import protected items.
 while import version content is most probably unique and system defined,
 there are quite some areas like user management and access control that
 need to be pluggable and thus the particular import behavior should be
 defined by the corresponding implementation.
 i envision this to work in a similar way than the implementation
 specific validators.
 steps to get there include:
 - properly setup the xml-import such that it recognizes protected items
   and calls the configured protected-item-importers.
 - allow to plugin implementation specific extensions
 - define an interface for that protected item import.
 regarding the latest part: in contrast to jackrabbit core, where we had
 just the JCR API at hand i would suggest to setup those special importers
 such that they can operate both on the JCR API (session and extensions)
 and on the OAK API giving the implementation more flexibility on how
 to actually treat the import.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-427) ItemDelegate has dependency to TreeImpl#NullLocation

2012-11-07 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13492249#comment-13492249
 ] 

angela commented on OAK-427:


i might well be mistaken, but from my understanding the NullLocation doesn't 
have any dependency to TreeImpl
and it also felt a bit odd if it had one since as you state it is intended to 
represent those case where
there is no (accessible) tree.

 ItemDelegate has dependency to TreeImpl#NullLocation
 

 Key: OAK-427
 URL: https://issues.apache.org/jira/browse/OAK-427
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: jcr
Reporter: angela
Priority: Minor

 The item-delegate has a dependency to NullLocation which is a
 inner class of TreeImpl and as such is an implementation detail.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-396) Limit property index to nodes of given type

2012-11-08 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13493147#comment-13493147
 ] 

angela commented on OAK-396:


this is a bug not an improvement

 Limit property index to nodes of given type
 ---

 Key: OAK-396
 URL: https://issues.apache.org/jira/browse/OAK-396
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: core
Affects Versions: 0.5
Reporter: Marcel Reutegger

 As discussed on the mailing list [0] the property index must be enhanced to 
 take the node type into account.
 [0] http://jackrabbit.markmail.org/thread/loudobqviwvhsli5

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-432) Repository does not restart with PrivilegeInitializer

2012-11-08 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13493168#comment-13493168
 ] 

angela commented on OAK-432:


sorry for that... i always run the complete build including integrationtest but 
never restart ;)
hope it's fixed with revision 1407069, please reopen if that's not the case

 Repository does not restart with PrivilegeInitializer
 -

 Key: OAK-432
 URL: https://issues.apache.org/jira/browse/OAK-432
 Project: Jackrabbit Oak
  Issue Type: Bug
Reporter: Marcel Reutegger
Assignee: angela
Priority: Blocker

 PrivilegeInitializer tries to register built-in privileges on every startup 
 and fails on a second start with:
 javax.jcr.RepositoryException: Privilege definition with name 'rep:readNodes' 
 already exists.
 at 
 org.apache.jackrabbit.oak.security.privilege.PrivilegeDefinitionWriter.writePrivilegeNode(PrivilegeDefinitionWriter.java:75)
 at 
 org.apache.jackrabbit.oak.security.privilege.PrivilegeDefinitionWriter.writeDefinitions(PrivilegeDefinitionWriter.java:56)
 at 
 org.apache.jackrabbit.oak.security.privilege.PrivilegeInitializer.initialize(PrivilegeInitializer.java:82)
 ... 34 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (OAK-435) Compilation failure due to MongoGridFSBlobStore

2012-11-09 Thread angela (JIRA)

angela created OAK-435:
--

 Summary: Compilation failure due to MongoGridFSBlobStore
 Key: OAK-435
 URL: https://issues.apache.org/jira/browse/OAK-435
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: mongomk
Reporter: angela


building the oak-mongomk failes on my machine with the following error:

ERROR] COMPILATION ERROR : 
[INFO] -
[ERROR] 
[...]oak-mongomk/src/main/java/org/apache/jackrabbit/mongomk/impl/blob/MongoGridFsBlobStore.java:[35,7]
 class MongoGridFSBlobStore is public, should be declared in a file named 
MongoGridFSBlobStore.java
[

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OAK-424) MongoMicroKernel changes

2012-11-09 Thread angela (JIRA)


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

angela updated OAK-424:
---

Component/s: (was: mk)
 mongomk

 MongoMicroKernel changes
 

 Key: OAK-424
 URL: https://issues.apache.org/jira/browse/OAK-424
 Project: Jackrabbit Oak
  Issue Type: Improvement
  Components: mongomk
Reporter: Mete Atamel
Assignee: Michael Dürig
 Fix For: 0.6

 Attachments: oak-mongomk-merge-failure-test.diff


 I worked on MongoMK in my own fork [0] and this is a request to merge those 
 changes back into Oak. There's a pull request [1] but the summary of changes 
 are the following:
 -Performance tests for MicroKernel by Tudor Rogoz.
 -Test and fix for OAK-351
 -Removed all @author and other code reorganization
 -Fix for FetchValidCommitsQuery
 -Fix for MicroKernelIT#copyDescendant test
 -Jsop fixes
 -Diff support and tests
 -Osgi support
 -Branch support and tests
 -Merge support and tests
 -GetJournal fixes
 -GetRevisionHistory fixes
 -Fixes and tests for copy, move nodes
 -Fix for OAK-384
 -General API and code cleanup
 -Split diff, merge, getJournal, getRevHistory, waitForCommit into its own 
 commands
 -Converted *CommandMongo tests into MongoMK* tests
 -Fixes for concurrency issue reported by Tudor.
 -Renamed head collection to sync
 -Moved MongoUtil functionality under Mongoconnection
 -Renamed *Query clases into *Action
 -oak-mongo-perf cleanup
 -Merged CommitImpl into CommitMongo
 -Renamed MongoBlobStore to MongoGridFSBlobStore
 -Initial MongoBlobStore implementation based on AbstractBlobStore
 -Blob retrieval fix in MongoGridFSBlobStore
 -Move collection handling from MongoConnection to MongoNodeStore
 [0] https://github.com/meteatamel/jackrabbit-oak/
 [1] https://github.com/apache/jackrabbit-oak/pull/6

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-426) TreeLocation: Add support for relative paths containing current or parent element

2012-11-09 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13494053#comment-13494053
 ] 

angela commented on OAK-426:


that the Tree doesn't handle it is pretty obvious but if it really should not 
care is IMHO debatable.
the longer i actually think about the more i have the impression that it was 
better to deal with
'.' and '..' wherever the OAK API takes a relative path.

keeping this in a utility might work but i have the feeling that it's really 
sensible to do so
and will be prone for errors as there will be many places where that needs to 
be enforced.
in addition i simply can't come up with a use-case of having '.' and '..' being 
valid names for a 
Tree or a PropertyState and since the OAK API is on a different level of 
abstraction than the MK I
don't see why we should be bound to the same level of ignorance.

 TreeLocation: Add support for relative paths containing current or parent 
 element
 -

 Key: OAK-426
 URL: https://issues.apache.org/jira/browse/OAK-426
 Project: Jackrabbit Oak
  Issue Type: New Feature
  Components: core
Reporter: angela

 i just run into another place where i would need to work around
 missing support for the current (.) and parent (..) element
 in the TreeLocation.
 IMO it would make sense to add this to TreeLocation#getChild... maybe
 even rename it to TreeLocation#getLocation(String relativePath)?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OAK-426) OAK-API: Deal with names and relativePaths consisting/containing . and ..

2012-11-09 Thread angela (JIRA)


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

angela updated OAK-426:
---

Summary: OAK-API: Deal with names and relativePaths consisting/containing 
. and ..  (was: TreeLocation: Add support for relative paths containing 
current or parent element)

i slightly adjusted to subject to match what i feel should be
present... if TreeLocation is able to handle relative paths containing
. and .. the rest of the OAK-API should act consistently

 OAK-API: Deal with names and relativePaths consisting/containing . and ..
 -

 Key: OAK-426
 URL: https://issues.apache.org/jira/browse/OAK-426
 Project: Jackrabbit Oak
  Issue Type: New Feature
  Components: core
Reporter: angela

 i just run into another place where i would need to work around
 missing support for the current (.) and parent (..) element
 in the TreeLocation.
 IMO it would make sense to add this to TreeLocation#getChild... maybe
 even rename it to TreeLocation#getLocation(String relativePath)?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OAK-51) Access Control Management

2012-11-13 Thread angela (JIRA)


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

angela updated OAK-51:
--

Summary: Access Control Management  (was: Implement JCR Access Control 
Management)

 Access Control Management
 -

 Key: OAK-51
 URL: https://issues.apache.org/jira/browse/OAK-51
 Project: Jackrabbit Oak
  Issue Type: Task
  Components: core, jcr
Reporter: angela
Assignee: angela



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (OAK-444) Authorization for the jcr version store

2012-11-13 Thread angela (JIRA)

angela created OAK-444:
--

 Summary: Authorization for the jcr version store
 Key: OAK-444
 URL: https://issues.apache.org/jira/browse/OAK-444
 Project: Jackrabbit Oak
  Issue Type: Sub-task
  Components: core
Reporter: angela


as explained in JCR-2963 the version store needs special attention when
it comes to access control and permissions enforced on the store.

for oak we need to define mechanisms on how to control access to the
version store and provide the possibility to limit access to individual
parts of the version store. some possibilities are already listed in JCR-2963.

additional topics include:
- searching for versioned content
- find and restore versions that have no corresponding versionable node in
  the content tree
- ability to prevent access to version store altogether without preventing
  access to versions/version histories through JCR version operations


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OAK-453) Move move and copy methods from Root to Tree

2012-11-20 Thread angela (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13500955#comment-13500955
 ] 

angela commented on OAK-453:


-1 for moving copy/move to Tree as long as we didn't reach consensus on how to 
deal
with multiple workspace.

 Move move and copy methods from Root to Tree
 

 Key: OAK-453
 URL: https://issues.apache.org/jira/browse/OAK-453
 Project: Jackrabbit Oak
  Issue Type: Improvement
  Components: core
Reporter: Michael Dürig
 Attachments: OAK-453.patch


 In OAK-391 we decided to not track trees through moves any more (see also 
 http://markmail.org/message/b6dcyae362akyogd). This allows us to move the 
 {{move}} and {{copy}} methods from {{Root}} to {{Tree}} where they feel more 
 natural. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Reopened] (OAK-410) RepositoryInitializer runs before the CommitHooks are in place

2012-11-20 Thread angela (JIRA)


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

angela reopened OAK-410:



i have the impression that fix broke the build... reopening.

 RepositoryInitializer runs before the CommitHooks are in place
 --

 Key: OAK-410
 URL: https://issues.apache.org/jira/browse/OAK-410
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: core
Reporter: Alex Parvulescu
 Fix For: 0.6

 Attachments: 
 0001-OAK-410-RepositoryInitializer-runs-before-the-Commit.patch, OAK-410.patch


 The InitialContent installs a bunch of content nodes before the CommitHooks 
 are enabled.
 This hurts the query indexes as they don't get notified about the initial 
 content and cannot index/process it.
 I'm mostly referring to the Auth stuff that relies on a combo of initial 
 content  queries.
 Luckily when using the PropertyIndex it does fallback to full repository 
 traversal, which works (albeit slowly). Unfortunately I can't say the same 
 for the lucene index).
 A bit of context here [0].
 [0] 
 https://issues.apache.org/jira/browse/OAK-403?focusedCommentId=13486763page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13486763

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

1 2 3 4 5 6 7 8 9 10 >

1 - 100 of 4199 matches

Mail list logo