[jira] [Updated] (JCR-3006) UserManager: concurrent user creation using same intermediate path fails

[Stefan Guggisberg (JIRA)]

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

Stefan Guggisberg updated JCR-3006:
---

Attachment: ConcurrentCreateUserTest.java

test case

 UserManager: concurrent user creation using same intermediate path fails
 

 Key: JCR-3006
 URL: https://issues.apache.org/jira/browse/JCR-3006
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: security
Affects Versions: 2.2.7
Reporter: Stefan Guggisberg
 Attachments: ConcurrentCreateUserTest.java


 concurrently creating users using same intermediate path fails with node ... 
 has been modified externally.
 the problem is the intermediate path. if it doesn't exist multiple threads 
 try to create it concurrently: 
 o.a.jackrabbit.core.security.user.UserManagerImpl, line 1310ff:
 String[] segmts = defaultPath.split(/);
 NodeImpl folder = (NodeImpl) session.getRootNode();
 String authRoot = (isGroup) ? groupsPath : usersPath;
 for (String segment : segmts) {
 if (segment.length()  1) {
 continue;
 }
 if (folder.hasNode(segment)) {
 folder = (NodeImpl) folder.getNode(segment);
 if (Text.isDescendantOrEqual(authRoot, folder.getPath()) 
 
 !folder.isNodeType(NT_REP_AUTHORIZABLE_FOLDER)) {
 throw new ConstraintViolationException(Invalid 
 intermediate path. Must be of type rep:AuthorizableFolder.);
 }
 } else {
 Node parent = folder;
 folder = addNode(folder, session.getQName(segment), 
 NT_REP_AUTHORIZABLE_FOLDER);
 }
 }
 the attached test case illustrates this issue/

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (JCR-3006) UserManager: concurrent user creation using same intermediate path fails

[Stefan Guggisberg (JIRA)]

UserManager: concurrent user creation using same intermediate path fails


 Key: JCR-3006
 URL: https://issues.apache.org/jira/browse/JCR-3006
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: security
Affects Versions: 2.2.7
Reporter: Stefan Guggisberg
 Attachments: ConcurrentCreateUserTest.java

concurrently creating users using same intermediate path fails with node ... 
has been modified externally.

the problem is the intermediate path. if it doesn't exist multiple threads try 
to create it concurrently: 

o.a.jackrabbit.core.security.user.UserManagerImpl, line 1310ff:


String[] segmts = defaultPath.split(/);
NodeImpl folder = (NodeImpl) session.getRootNode();
String authRoot = (isGroup) ? groupsPath : usersPath;

for (String segment : segmts) {
if (segment.length()  1) {
continue;
}
if (folder.hasNode(segment)) {
folder = (NodeImpl) folder.getNode(segment);
if (Text.isDescendantOrEqual(authRoot, folder.getPath()) 
!folder.isNodeType(NT_REP_AUTHORIZABLE_FOLDER)) {
throw new ConstraintViolationException(Invalid 
intermediate path. Must be of type rep:AuthorizableFolder.);
}
} else {
Node parent = folder;
folder = addNode(folder, session.getQName(segment), 
NT_REP_AUTHORIZABLE_FOLDER);
}
}

the attached test case illustrates this issue/

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [jr3] MicroKernel API: Provide means for commit message

[Stefan Guggisberg]

On Wed, Jun 22, 2011 at 11:01 AM, Michael Dürig mdue...@apache.org wrote:

 Hi,

 I think we should provide means for having a commit message. That message
 should also go to the journal such that it can be retrieved by calling
 getRevisions(). See attached patch for details.

+1, i'll take care

cheers
stefan


 The rational for this change is that implementing the User Data
 functionality [1] is not feasible on top of the current MicroKernel API.

 Michael

 [1]
 http://www.day.com/specs/jcr/2.0/12_Observation.html#12.3.5%20User%20Data

Re: [j3] Repository MicroKernel API draft

[Stefan Guggisberg]

On Sun, Jun 19, 2011 at 3:15 PM, Jukka Zitting jukka.zitt...@gmail.com wrote:
 Hi,

 On Fri, Jun 17, 2011 at 6:37 PM, Stefan Guggisberg
 stefan.guggisb...@gmail.com wrote:
 one of the design goals of the MicroKernel API was easy portablilty.
 typically it would be used in-proc by some higher level code, comparable
 to the current SPI.

 To me it seems like the JSON parts of the API would be better suited
 for a higher-level integration layer.

 The problem here is that since the MicroKernel is an intentionally
 low-level API, we'll need a lot of higher level code to implement
 features like versioning and search.

correct.

 My assumption is that these
 components would still reside in the same JVM as the MicroKernel and
 thus access it through the defined Java interface.

typically yes, but not necessarily.

 Are we expecting
 such code to have to parse and generate JSON strings whenever it wants
 to access the underlying content?

yes, and i don't think that it's a problem.



 Consider, for example, a simple task of updating a counter. The JCR
 API for that is something like this:

    Property count = session.getProperty(/counter/count);
    count.setValue(count.getLong() + 1);
    session.save();

 The equivalent MicroKernel code, as far as I understand the API, would
 be something like this:

    String revision = microkernel.getHeadRevision();
    String counter = microkernel.getNodes(/counter, revision, 0, 0, 0);
    JSONObject json = new JSONObject(counter);
    long count = json.getLong(count) + 1;
    revision = microkernel.commit(/counter, ^count: + count, revision);

 This doesn't strike me as a particularly programmer-friendly API.

agreed. since the audience of the MicroKernel API is pretty small
programmer-friendliness has admittedly not been a top priority ;)

OTOH portability, remotability, stateless nature and compactness
have been. having those goals in mind, JSON is IMO a perfect fit.

cheers
stefan


 BR,

 Jukka Zitting

Re: [j3] Repository MicroKernel API draft

[Stefan Guggisberg]

On Mon, Jun 20, 2011 at 12:21 PM, Michael Dürig mdue...@apache.org wrote:

 why JSON strings?
 - easy portability
 - remoting-friendly
 - leads to very compact API
 - JSON parsing/generating overhead is IMO minimal
   and probably more effecient than creating (and collecting) tons of
   small java objects on the heap


 I doubt this. In fact I think the situation with the small Java objects is
 even worse in the face of a JSON based API: typically a (de)serialization
 layer will create an additional set of intermediate objects which have to be
 consumed/translated into the domain objects of the respective
 implementation.

that's IMO implementation specific. the JSON response doesn't need to
be parsed fully, the JSON string might just as well be kept instead and
domain objects would be generated on demand from the underlying JSON data.


 Michael

Re: [j3] Repository MicroKernel API draft

[Stefan Guggisberg]

On Mon, Jun 20, 2011 at 12:43 PM, Michael Dürig mdue...@apache.org wrote:

 agreed. since the audience of the MicroKernel API is pretty small
 programmer-friendliness has admittedly not been a top priority ;)

 I think programmer-friendliness should have a higher priority then. Where
 did this priorities come from btw?

those priorities reflect my personal judgement, based on various coffee break
discussions, mailing-list discussions and 10 years working on jackrabbit core.

i've started the sandbox project to share it with interested parties
in the community
and hoping to be able to test the feasibility of this approach.

cheers
stefan


 Programmer unfriendly api's lead to programmers designing ad-hoc convenience
 wrappers which lead to fragmentation and broken windows. This is already now
 apparent from the jr3 prototype code base! Which is pretty alarming to me.

 OTOH portability, remotability, stateless nature and compactness
 have been. having those goals in mind, JSON is IMO a perfect fit.

 Again, where did these goals come from? What are the rationals?

 While I think having a stateless api is a good think, I think we should not
 let this preclude other features and functionality. For example having the
 commit method to contain all the transient changes in a single json string
 will limit the size of transient modifications.

 We could as well allow transient changes to be written to the micro kernel
 and then committed later on:

 changes.add(mk.writeTransient(+/foo/bar, {}))
 changes.add(mk.writeTransient(+/foo2/bar2, {}))
 ...
 mk.commit(changes)

 IMO this is as stateless as the other approach.

 Michael




 cheers
 stefan


 BR,

 Jukka Zitting

Re: [j3] Repository MicroKernel API draft

[Stefan Guggisberg]

sorry for being late...

On Fri, Jun 10, 2011 at 1:18 PM, Jukka Zitting jukka.zitt...@gmail.com wrote:
 Hi,

 On Wed, May 11, 2011 at 6:31 PM, Stefan Guggisberg
 stefan.guggisb...@gmail.com wrote:
 as some of you may have noticed i've started work on my own
 MicroKernel proposal a while ago in the jackrabbit sandbox.

 although the project is in a very early stage i wanted to share my work
 with you.

 Good stuff! I see people are already starting to collaborate on this.

 as always, questions  feedback are welcome.

 The MicroKernel interface [1] reads more like a REST than a Java API.
 I guess that's the intention,

no, it just ended up like this after several redesign cycles ;)

 but I question why one would ever want
 to pass around serialized JSON strings around in a Java application. A
 Java client would just parse the string again, leading to unnecessary
 serialize/parse rounds whenever an API call is made. So, assuming we
 are designing a REST API (which seems like a good idea), instead of
 defining the API as a Java interface, wouldn't it make more sense to
 directly with a HTTP binding or alternatively a more abstract API
 definition?

one of the design goals of the MicroKernel API was easy portablilty.
typically it would be used in-proc by some higher level code, comparable
to the current SPI.

why JSON strings?
- easy portability
- remoting-friendly
- leads to very compact API
- JSON parsing/generating overhead is IMO minimal
  and probably more effecient than creating (and collecting) tons of
  small java objects on the heap

cheers
stefan


 Another question: Why would we ever want to build our own JSON parsing
 and serialization code? Just use one of the existing libraries out
 there.

 [1] 
 http://svn.apache.org/repos/asf/jackrabbit/sandbox/microkernel/src/main/java/org/apache/jackrabbit/mk/api/MicroKernel.java

 BR,

 Jukka Zitting

[j3] Repository MicroKernel API draft

[Stefan Guggisberg]

hi,

as some of you may have noticed i've started work on my own
MicroKernel proposal a while ago in the jackrabbit sandbox.

although the project is in a very early stage i wanted to share my work
with you.

my idea was to first come up with an abstraction of a bare-bone
MVCC -based repository storage engine and then test the feasibility
with a primitive prototype.

the source code is located here:
http://svn.apache.org/repos/asf/jackrabbit/sandbox/microkernel/

and here's some (still very basic) documentation:
http://wiki.apache.org/jackrabbit/RepositoryMicroKernel

as always, questions  feedback are welcome.

cheers
stefan

[jira] [Created] (JCR-2967) SessionItemStateManager.getIdOfRootTransientNodeState() may cause NPE

[Stefan Guggisberg (JIRA)]

SessionItemStateManager.getIdOfRootTransientNodeState() may cause NPE
-

 Key: JCR-2967
 URL: https://issues.apache.org/jira/browse/JCR-2967
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-core
Affects Versions: 2.2.5, 2.2.4, 2.2.2, 2.2.1, 2.2.0, 2.1.3, 2.1.2, 2.1.1, 
2.1.0, 2.0.3, 2.0.0
Reporter: Stefan Guggisberg
 Fix For: 2.3.0


regression of JCR-2425

in certain scenarios, calling 
SessionItemStateManager.getIdOfRootTransientNodeState() may cause a NPE.

Test case: 

Repository repository = new TransientRepository(); 
Session session = repository.login( 
new SimpleCredentials(admin, admin.toCharArray())); 
Session session2 = repository.login( 
new SimpleCredentials(admin, admin.toCharArray())); 

try { 
while (session.getRootNode().hasNode(test)) { 
session.getRootNode().getNode(test).remove(); 
} 
Node test = session.getRootNode().addNode(test); 
session.save(); 
Node x = test.addNode(x); 
session.save(); 

Node x2 = session2.getRootNode().getNode(test).getNode(x); 
x2.remove(); 
x.addNode(b); 
session2.save(); 
session.save(); // throws NPE 
} finally { 
session.logout(); 
session2.logout(); 
}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (JCR-2967) SessionItemStateManager.getIdOfRootTransientNodeState() may cause NPE

[Stefan Guggisberg (JIRA)]

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

Stefan Guggisberg resolved JCR-2967.


Resolution: Fixed
  Assignee: Stefan Guggisberg

fixed in svn r1101046

 SessionItemStateManager.getIdOfRootTransientNodeState() may cause NPE
 -

 Key: JCR-2967
 URL: https://issues.apache.org/jira/browse/JCR-2967
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-core
Affects Versions: 2.0.0, 2.0.3, 2.1.0, 2.1.1, 2.1.2, 2.1.3, 2.2.0, 2.2.1, 
 2.2.2, 2.2.4, 2.2.5
Reporter: Stefan Guggisberg
Assignee: Stefan Guggisberg
 Fix For: 2.3.0


 regression of JCR-2425
 in certain scenarios, calling 
 SessionItemStateManager.getIdOfRootTransientNodeState() may cause a NPE.
 Test case: 
 Repository repository = new TransientRepository(); 
 Session session = repository.login( 
 new SimpleCredentials(admin, admin.toCharArray())); 
 Session session2 = repository.login( 
 new SimpleCredentials(admin, admin.toCharArray())); 
 try { 
 while (session.getRootNode().hasNode(test)) { 
 session.getRootNode().getNode(test).remove(); 
 } 
 Node test = session.getRootNode().addNode(test); 
 session.save(); 
 Node x = test.addNode(x); 
 session.save(); 
 Node x2 = session2.getRootNode().getNode(test).getNode(x); 
 x2.remove(); 
 x.addNode(b); 
 session2.save(); 
 session.save(); // throws NPE 
 } finally { 
 session.logout(); 
 session2.logout(); 
 }

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (JCR-2961) Improve logging of Session.save() to trace back root cause of externally modified nodes

[Stefan Guggisberg (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13030756#comment-13030756
 ] 

Stefan Guggisberg commented on JCR-2961:


thanks, i could now reproduce the NPE.

i filed JCR-2967.

 Improve logging of Session.save() to trace back root cause of externally 
 modified nodes
 ---

 Key: JCR-2961
 URL: https://issues.apache.org/jira/browse/JCR-2961
 Project: Jackrabbit Content Repository
  Issue Type: New Feature
Reporter: Thomas Mueller
Assignee: Thomas Mueller
Priority: Minor
 Fix For: 2.3.0


 Currently it's very difficult to find the root cause of error like: 
 javax.jcr.InvalidItemStateException: UUID has been modified externally.
 To better trace back such issues, it would be nice to add DEBUG logging for 
 the Session.save() call.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (JCR-2960) Long values not properly stored

[Stefan Guggisberg (JIRA)]

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

Stefan Guggisberg updated JCR-2960:
---

Description: 
When a long value assigned to a property is too big, when restarting the server 
the value become 0 !! 

The test pass with versions 1.6.4 and 2.0

  was:
When a long value assigned to a property is too large,  the value is correctly 
read until the repository is restarted. Then the value read is 0 !
( see attached junit test)

The test pass with versions 1.6.4 and 2.0


regression of JCR-2762.

test case: 

any long value  0x3FFF (i.e. with any of the 2 most significant 
bits set)
causes an overflow on deserialization.

this obviously also includes Long.MAX_VALUE and Long.MIN_VALUE...

example:
long test = 0x3FFFL;
 
BundleWriter.writeVarLong(test);
test == BundleReader.readVarLong()  // = ok

test++;
BundleWriter.writeVarLong(test);
= BundleReader.readVarLong() returns 0

 Long values not properly stored
 ---

 Key: JCR-2960
 URL: https://issues.apache.org/jira/browse/JCR-2960
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-core
Affects Versions: 2.2.0, 2.2.1, 2.2.4, 2.2.5
Reporter: Antoine Brochard
Priority: Critical
 Attachments: LongValueTest.java


 When a long value assigned to a property is too big, when restarting the 
 server the value become 0 !! 
 The test pass with versions 1.6.4 and 2.0

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (JCR-2960) Long values not properly stored

[Stefan Guggisberg (JIRA)]

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

Stefan Guggisberg reassigned JCR-2960:
--

Assignee: Jukka Zitting

 Long values not properly stored
 ---

 Key: JCR-2960
 URL: https://issues.apache.org/jira/browse/JCR-2960
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-core
Affects Versions: 2.2.0, 2.2.1, 2.2.4, 2.2.5
Reporter: Antoine Brochard
Assignee: Jukka Zitting
Priority: Critical
 Attachments: LongValueTest.java


 When a long value assigned to a property is too big, when restarting the 
 server the value become 0 !! 
 The test pass with versions 1.6.4 and 2.0

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (JCR-2962) InputStream not being explicitly closed

[Stefan Guggisberg (JIRA)]

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

Stefan Guggisberg resolved JCR-2962.


   Resolution: Fixed
Fix Version/s: 2.3.0

fixed in svn r1100242

thanks for reporting this issue and providing a patch

(i am trying to avoid finalize methods that's why
i've just moved the scope of the try/finally block).

 InputStream not being explicitly closed
 ---

 Key: JCR-2962
 URL: https://issues.apache.org/jira/browse/JCR-2962
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-core
Affects Versions: 2.2.5
 Environment: Glassfish version 3.1.
 Jackrabbit configured to use 
 org.apache.jackrabbit.core.persistence.pool.MySqlPersistenceManager as 
 PersistenceManager.
Reporter: Gustavo Orair
Priority: Trivial
  Labels: inputstream
 Fix For: 2.3.0

 Attachments: patch.txt

   Original Estimate: 10m
  Remaining Estimate: 10m

 After deploying a j2ee artifact that uses jackrabbit and 
 org.apache.jackrabbit.core.persistence.pool.MySqlPersistenceManager, 
 Glassfish starts complaining there are input streams without being explicitly 
 closed.
 The specific inputStream mey be found at 
 org.apache.jackrabbit.core.persistence.pool.BundleDbPersistenceManager.createCheckSchemaOperation(BundleDbPersistenceManager.java:584).
 I've checked the code and in BundleDbPersistenceManager:530 the run method is 
 invoked to the object CheckSchemaOperation.
 In run method CheckSchemaOperation:78, the finally block that calls 
 IOUtils.closeQuietly(ddl); to close the stream is inside the condition if 
 (!conHelper.tableExists(table)) (CheckSchemaOperation:79).
 So, if this condition is false, the inputStream will not be explicitly closed.
 In my opinion, there are two fix alternatives:
 The most robust should be:
 1 - insert a finalize() method:
 @Override
 protected void finalize() throws Throwable {
   if (ddl!=null){
 IOUtils.closeQuietly(ddl);
   }
   super.finalize();
   }
 Another alternative:
 2 - Put the condition if (!conHelper.tableExists(table)) inside try-finally 
 block.
 StackTrace:
 [#|2011-05-05T11:43:28.087-0300|WARNING|glassfish3.1|javax.enterprise.system.core.classloading.com.sun.enterprise.loader|_ThreadID=1233;_ThreadName=Thread-1;|Input
  stream has been finalized or forced closed without being explicitly closed; 
 stream instantiation reported in following stack trace
 java.lang.Throwable
 at 
 com.sun.enterprise.loader.ASURLClassLoader$SentinelInputStream.init(ASURLClassLoader.java:1230)
 at 
 com.sun.enterprise.loader.ASURLClassLoader$InternalJarURLConnection.getInputStream(ASURLClassLoader.java:1338)
 at java.net.URL.openStream(URL.java:1010)
 at java.lang.ClassLoader.getResourceAsStream(ClassLoader.java:1195)
 at 
 com.sun.enterprise.loader.ASURLClassLoader.getResourceAsStream(ASURLClassLoader.java:872)
 at java.lang.Class.getResourceAsStream(Class.java:2030)
 at 
 org.apache.jackrabbit.core.persistence.pool.BundleDbPersistenceManager.createCheckSchemaOperation(BundleDbPersistenceManager.java:584)
 at 
 org.apache.jackrabbit.core.persistence.pool.BundleDbPersistenceManager.init(BundleDbPersistenceManager.java:530)
 at 
 org.apache.jackrabbit.core.persistence.pool.MySqlPersistenceManager.init(MySqlPersistenceManager.java:51)
 at 
 org.apache.jackrabbit.core.RepositoryImpl.createPersistenceManager(RepositoryImpl.java:1353)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (JCR-2965) Show referencing nodes in debug log when trying to delete a node with references

[Stefan Guggisberg (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-2965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13029974#comment-13029974
 ] 

Stefan Guggisberg commented on JCR-2965:


i'd prefer that the property id's are only included in the debug msg,
not in the exception msg, i.e.

if (log.isDebugEnabled()) {
  ...
}

 Show referencing nodes in debug log when trying to delete a node with 
 references
 

 Key: JCR-2965
 URL: https://issues.apache.org/jira/browse/JCR-2965
 Project: Jackrabbit Content Repository
  Issue Type: Improvement
Reporter: Bart van der Schans
Priority: Trivial
 Fix For: 2.2.6, 2.3.0

 Attachments: show-references.patch


 This can be very useful when trying to analyze errors from non-interactive 
 applications in a production environment.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (JCR-2961) Improve logging of Session.save() to trace back root cause of externally modified nodes

[Stefan Guggisberg (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13029987#comment-13029987
 ] 

Stefan Guggisberg commented on JCR-2961:


i am unable to reproduce the NPE with the provided test case on current trunk. 
any idea why i am not getting those?

 Improve logging of Session.save() to trace back root cause of externally 
 modified nodes
 ---

 Key: JCR-2961
 URL: https://issues.apache.org/jira/browse/JCR-2961
 Project: Jackrabbit Content Repository
  Issue Type: New Feature
Reporter: Thomas Mueller
Assignee: Thomas Mueller
Priority: Minor
 Fix For: 2.3.0


 Currently it's very difficult to find the root cause of error like: 
 javax.jcr.InvalidItemStateException: UUID has been modified externally.
 To better trace back such issues, it would be nice to add DEBUG logging for 
 the Session.save() call.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (JCR-2953) PathParser accepts illegal paths containing curly brackets

[Stefan Guggisberg (JIRA)]

PathParser accepts illegal paths containing curly brackets
--

 Key: JCR-2953
 URL: https://issues.apache.org/jira/browse/JCR-2953
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-spi-commons
Reporter: Stefan Guggisberg
Priority: Critical


o.a.jackrabbit.spi.commons.conversion.PathParser accepts the following path:

/public/.{.}/private

the normalized resulting Path object represents /private 

that's a potential security risk.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (JCR-2951) Item.remove fails if a child-item is not visible to the editing session

[Stefan Guggisberg (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-2951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13026188#comment-13026188
 ] 

Stefan Guggisberg commented on JCR-2951:


+1 for the patch, thanks!

 Item.remove fails if a child-item is not visible to the editing session
 ---

 Key: JCR-2951
 URL: https://issues.apache.org/jira/browse/JCR-2951
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-core
Reporter: angela
Assignee: angela
 Attachments: JCR-2951.patch


 the following test setup fails:
 - a given session is allowed to remove a node
 - the node has a policy child node which is not visible to the editing 
 session (missing ac-read permission)
   OR the node has another invisible child item which could - based on the 
 permissions above - be removed by that session.
 calling Node.remove however fails with accessdeniedexception because the 
 internal remove
 mechanism accesses all child items to mark them removed. however, the access 
 is executed
 using the regular itemmgr calls that are used to retrieve the items using the 
 JCR API which
 results in accessdenied exception as those child items are not visible to the 
 session.
 since the items can be removed i would argue that this is a bug in the 
 internal remove process.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Threading-JCR

[Stefan Guggisberg]

On Fri, Apr 15, 2011 at 6:37 PM, PeriS pe...@kuali.org wrote:
 Scenerio: Need for persisting multiple files under a single node (Folder)

 Structure:

 Root
    - Folder
        - File1
        - File 2

 When trying to have multiple threads insert files under the same node,
 complains about locking. What are the alternatives?

please ask questions like this on the users list.

thanks
stefan


 Thanks
 -PeriS

Fwd: svn commit: r1084832 - in /jackrabbit/trunk: jackrabbit-core/src/main/java/org/apache/jackrabbit/core/ jackrabbit-core/src/main/java/org/apache/jackrabbit/core/query/lucene/ jackrabbit-core/src/m

[Stefan Guggisberg]

thanks!

BTW: could you please use space characters instead of tabs? i guess we don't
have a formal coding style document but it's common practice (at least in the
jackrabbit project) to avoid tab characters in source code because the indenting
is not consistent across different environments.

cheers
stefan

-- Forwarded message --
From:  dbros...@apache.org
Date: Thu, Mar 24, 2011 at 3:49 AM
Subject: svn commit: r1084832 - in /jackrabbit/trunk:
jackrabbit-core/src/main/java/org/apache/jackrabbit/core/
jackrabbit-core/src/main/java/org/apache/jackrabbit/core/query/lucene/
jackrabbit-core/src/main/java/org/apache/jackrabbit/core/security/authenticati...
To: comm...@jackrabbit.apache.org


Author: dbrosius
Date: Thu Mar 24 02:49:05 2011
New Revision: 1084832

URL: http://svn.apache.org/viewvc?rev=1084832view=rev
Log:
JCR-2929
Various places do map lookups in loops instead of using entrySet iterator

Modified:
   
jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/RemoveMixinOperation.java
   
jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/query/lucene/MoreLikeThis.java
   
jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/security/authentication/token/TokenBasedAuthentication.java
   
jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/security/authorization/AccessControlEntryImpl.java
   
jackrabbit/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/commons/privilege/PrivilegeXmlHandler.java
   
jackrabbit/trunk/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/webdav/jcr/WorkspaceResourceImpl.java

Modified: 
jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/RemoveMixinOperation.java
URL: 
http://svn.apache.org/viewvc/jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/RemoveMixinOperation.java?rev=1084832r1=1084831r2=1084832view=diff
==
--- 
jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/RemoveMixinOperation.java
(original)
+++ 
jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/RemoveMixinOperation.java
Thu Mar 24 02:49:05 2011
@@ -191,9 +191,10 @@ class RemoveMixinOperation implements Se
        // 2. remove item if 1. fails
        boolean success = false;
        try {
-            for (PropertyId id : affectedProps.keySet()) {
+               for (Map.EntryPropertyId, PropertyDefinition entry :
affectedProps.entrySet()) {
+                       PropertyId id = entry.getKey();
                PropertyImpl prop = (PropertyImpl) itemMgr.getItem(id);
-                PropertyDefinition oldDef = affectedProps.get(id);
+                PropertyDefinition oldDef = entry.getValue();

                if (oldDef.isProtected()) {
                    // remove 'orphaned' protected properties immediately

Modified: 
jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/query/lucene/MoreLikeThis.java
URL: 
http://svn.apache.org/viewvc/jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/query/lucene/MoreLikeThis.java?rev=1084832r1=1084831r2=1084832view=diff
==
--- 
jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/query/lucene/MoreLikeThis.java
(original)
+++ 
jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/query/lucene/MoreLikeThis.java
Thu Mar 24 02:49:05 2011
@@ -605,11 +605,12 @@ public final class MoreLikeThis {
        int numDocs = ir.numDocs();
        FreqQ res = new FreqQ(words.size()); // will order words by score

-        IteratorString it = words.keySet().iterator();
+        IteratorMap.EntryString, Int it = words.entrySet().iterator();
        while (it.hasNext()) { // for every word
-            String word = it.next();
+               Map.EntryString, Int entry = it.next();
+            String word = entry.getKey();

-            int tf = ((Int) words.get(word)).x; // term freq in the source doc
+            int tf = entry.getValue().x; // term freq in the source doc
            if (minTermFreq  0  tf  minTermFreq) {
                continue; // filter out words that don't occur enough
times in the source
            }

Modified: 
jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/security/authentication/token/TokenBasedAuthentication.java
URL: 
http://svn.apache.org/viewvc/jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/security/authentication/token/TokenBasedAuthentication.java?rev=1084832r1=1084831r2=1084832view=diff
==
--- 
jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/security/authentication/token/TokenBasedAuthentication.java
(original)
+++ 

[jira] [Updated] (JCR-2930) same named child nodes disappear on restore

[Stefan Guggisberg (JIRA)]

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

Stefan Guggisberg updated JCR-2930:
---

Component/s: versioning

 same named child nodes disappear on restore
 ---

 Key: JCR-2930
 URL: https://issues.apache.org/jira/browse/JCR-2930
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-core, versioning
Affects Versions: 2.2.4
Reporter: Marlis Lamp
Priority: Critical

 When restoring a versionable node which has several (non-versionable) child 
 nodes with the same name, some child nodes disappear. 
 Node node = session.getRootNode().addNode(myNode);
 node.addMixin(mix:versionable);
 for (int i = 1; i  6; i++) {
 Node child = node.addNode(child);
 child.setProperty(name, child_+i);
 }
 session.save();
 VersionManager versionManager = 
 session.getWorkspace().getVersionManager();
 versionManager.checkin(node.getPath());
 System.out.println(number of child nodes:  + 
 node.getNodes().getSize());
 versionManager.checkout(node.getPath());
 node.getNode(child).setProperty(name, modified);
 session.save();
 Version baseVersion = 
 versionManager.getBaseVersion(node.getPath());
 versionManager.restore(baseVersion, true);
 System.out.println(number of child nodes in restored node: 
 +node.getNodes().getSize());
 produces the following output:
 number of child nodes: 5
 number of child nodes in restored node: 3
 Giving unique names or adding the mixin versionable to the child nodes solves 
 the problem.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (JCR-2920) Workspace.copy(src, dest) throws unexpected RepositoryException (Invalid path)

[Stefan Guggisberg (JIRA)]

Workspace.copy(src, dest) throws unexpected RepositoryException (Invalid path)


 Key: JCR-2920
 URL: https://issues.apache.org/jira/browse/JCR-2920
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-spi2dav
Reporter: Stefan Guggisberg
 Fix For: 2.3.0


when using the davex remoting layer (jcr2spi-spi2davex), 
the following code fragment causes an unexpected RepositoryException:

snip
Node testNode1 = session.getRootNode().addNode(test, nt:folder);

Node copyDestination = testNode1.addNode(CopyDestination, nt:folder);
testNode1.addNode(CopySource, nt:folder).addNode(testCopyCommand, 
nt:folder).addNode(abc, nt:folder);
session.save();
copyDestination.addMixin(mix:referenceable);
session.save();

session.getWorkspace().copy(/test/CopySource/testCopyCommand, 
/test/CopyDestination/testCopyCommand);
/snip

== Caused by: javax.jcr.RepositoryException: Invalid 
path:/test/CopyDestination//testCopyCommand
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at 
org.apache.jackrabbit.spi2dav.ExceptionConverter.generate(ExceptionConverter.java:69)
at 
org.apache.jackrabbit.spi2dav.ExceptionConverter.generate(ExceptionConverter.java:51)
at 
org.apache.jackrabbit.spi2dav.RepositoryServiceImpl.execute(RepositoryServiceImpl.java:482)
at 
org.apache.jackrabbit.spi2dav.RepositoryServiceImpl.copy(RepositoryServiceImpl.java:1307)
at 
org.apache.jackrabbit.spi2davex.RepositoryServiceImpl.copy(RepositoryServiceImpl.java:326)
at 
org.apache.jackrabbit.jcr2spi.WorkspaceManager$OperationVisitorImpl.visit(WorkspaceManager.java:889)
at org.apache.jackrabbit.jcr2spi.operation.Copy.accept(Copy.java:48)
at 
org.apache.jackrabbit.jcr2spi.WorkspaceManager$OperationVisitorImpl.execute(WorkspaceManager.java:848)
at 
org.apache.jackrabbit.jcr2spi.WorkspaceManager$OperationVisitorImpl.access$400(WorkspaceManager.java:793)
at 
org.apache.jackrabbit.jcr2spi.WorkspaceManager.execute(WorkspaceManager.java:581)
at 
org.apache.jackrabbit.jcr2spi.WorkspaceImpl.copy(WorkspaceImpl.java:149)
[...]  


however, the following slightly altered code fragment works as expected:


snip
Node testNode1 = session.getRootNode().addNode(test, nt:folder);
/*
Node copyDestination = testNode1.addNode(CopyDestination, nt:folder);
testNode1.addNode(CopySource, nt:folder).addNode(testCopyCommand, 
nt:folder).addNode(abc, nt:folder);
session.save();
copyDestination.addMixin(mix:referenceable);
session.save();
*/
testNode1.addNode(CopyDestination, 
nt:folder).addMixin(NodeType.MIX_REFERENCEABLE);
Node n = testNode1.addNode(CopySource, 
nt:folder).addNode(testCopyCommand, nt:folder).addNode(abc, 
nt:folder);
session.save();

session.getWorkspace().copy(/test/CopySource/testCopyCommand, 
/test/CopyDestination/testCopyCommand);
/snip


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (JCR-2921) URIResolverImpl: use of bitwise instead of logical AND operator

[Stefan Guggisberg (JIRA)]

URIResolverImpl: use of bitwise instead of logical AND operator
---

 Key: JCR-2921
 URL: https://issues.apache.org/jira/browse/JCR-2921
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-spi2dav
Reporter: Stefan Guggisberg
Priority: Minor


URIResolverImpl, line 111: 

if (path != null  cache.containsItemId(uuidId)) {


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Resolved: (JCR-2921) URIResolverImpl: use of bitwise instead of logical AND operator

[Stefan Guggisberg (JIRA)]

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

Stefan Guggisberg resolved JCR-2921.


   Resolution: Fixed
Fix Version/s: 2.3.0

fixed in revision 1082599

 URIResolverImpl: use of bitwise instead of logical AND operator
 ---

 Key: JCR-2921
 URL: https://issues.apache.org/jira/browse/JCR-2921
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-spi2dav
Reporter: Stefan Guggisberg
Priority: Minor
 Fix For: 2.3.0


 URIResolverImpl, line 111: 
 if (path != null  cache.containsItemId(uuidId)) {

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (JCR-2922) JcrParser: use of bitwise instead of logical AND operator

[Stefan Guggisberg (JIRA)]

JcrParser: use of bitwise instead of logical AND operator
-

 Key: JCR-2922
 URL: https://issues.apache.org/jira/browse/JCR-2922
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-standalone
Reporter: Stefan Guggisberg
Priority: Minor


JcrParser, line 134:

if ((!insideSingleQuote  !insideDoubleQuote  Character


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Resolved: (JCR-2922) JcrParser: use of bitwise instead of logical AND operator

[Stefan Guggisberg (JIRA)]

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

Stefan Guggisberg resolved JCR-2922.


   Resolution: Fixed
Fix Version/s: 2.3.0

fixed in revision 1082611

 JcrParser: use of bitwise instead of logical AND operator
 -

 Key: JCR-2922
 URL: https://issues.apache.org/jira/browse/JCR-2922
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-standalone
Reporter: Stefan Guggisberg
Priority: Minor
 Fix For: 2.3.0


 JcrParser, line 134:
 if ((!insideSingleQuote  !insideDoubleQuote  Character

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Resolved: (JCR-2920) Workspace.copy(src, dest) throws unexpected RepositoryException (Invalid path)

[Stefan Guggisberg (JIRA)]

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

Stefan Guggisberg resolved JCR-2920.


Resolution: Fixed

fixed in trunk (#1082620)

 Workspace.copy(src, dest) throws unexpected RepositoryException (Invalid 
 path)
 

 Key: JCR-2920
 URL: https://issues.apache.org/jira/browse/JCR-2920
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-spi2dav
Reporter: Stefan Guggisberg
 Fix For: 2.3.0


 when using the davex remoting layer (jcr2spi-spi2davex), 
 the following code fragment causes an unexpected RepositoryException:
 snip
 Node testNode1 = session.getRootNode().addNode(test, nt:folder);
 Node copyDestination = testNode1.addNode(CopyDestination, nt:folder);
 testNode1.addNode(CopySource, nt:folder).addNode(testCopyCommand, 
 nt:folder).addNode(abc, nt:folder);
 session.save();
 copyDestination.addMixin(mix:referenceable);
 session.save();
 session.getWorkspace().copy(/test/CopySource/testCopyCommand, 
 /test/CopyDestination/testCopyCommand);
 /snip
 == Caused by: javax.jcr.RepositoryException: Invalid 
 path:/test/CopyDestination//testCopyCommand
   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
   at 
 sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
   at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
   at 
 org.apache.jackrabbit.spi2dav.ExceptionConverter.generate(ExceptionConverter.java:69)
   at 
 org.apache.jackrabbit.spi2dav.ExceptionConverter.generate(ExceptionConverter.java:51)
   at 
 org.apache.jackrabbit.spi2dav.RepositoryServiceImpl.execute(RepositoryServiceImpl.java:482)
   at 
 org.apache.jackrabbit.spi2dav.RepositoryServiceImpl.copy(RepositoryServiceImpl.java:1307)
   at 
 org.apache.jackrabbit.spi2davex.RepositoryServiceImpl.copy(RepositoryServiceImpl.java:326)
   at 
 org.apache.jackrabbit.jcr2spi.WorkspaceManager$OperationVisitorImpl.visit(WorkspaceManager.java:889)
   at org.apache.jackrabbit.jcr2spi.operation.Copy.accept(Copy.java:48)
   at 
 org.apache.jackrabbit.jcr2spi.WorkspaceManager$OperationVisitorImpl.execute(WorkspaceManager.java:848)
   at 
 org.apache.jackrabbit.jcr2spi.WorkspaceManager$OperationVisitorImpl.access$400(WorkspaceManager.java:793)
   at 
 org.apache.jackrabbit.jcr2spi.WorkspaceManager.execute(WorkspaceManager.java:581)
   at 
 org.apache.jackrabbit.jcr2spi.WorkspaceImpl.copy(WorkspaceImpl.java:149)
   [...]  
 however, the following slightly altered code fragment works as expected:
 snip
 Node testNode1 = session.getRootNode().addNode(test, nt:folder);
 /*
 Node copyDestination = testNode1.addNode(CopyDestination, nt:folder);
 testNode1.addNode(CopySource, nt:folder).addNode(testCopyCommand, 
 nt:folder).addNode(abc, nt:folder);
 session.save();
 copyDestination.addMixin(mix:referenceable);
 session.save();
 */
 testNode1.addNode(CopyDestination, 
 nt:folder).addMixin(NodeType.MIX_REFERENCEABLE);
 Node n = testNode1.addNode(CopySource, 
 nt:folder).addNode(testCopyCommand, nt:folder).addNode(abc, 
 nt:folder);
 session.save();
 session.getWorkspace().copy(/test/CopySource/testCopyCommand, 
 /test/CopyDestination/testCopyCommand);
 /snip

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (JCR-2914) Copying data from inputStream to OuputStream needs appropriate buffer size

[Stefan Guggisberg (JIRA)]

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

Stefan Guggisberg updated JCR-2914:
---

  Priority: Minor  (was: Major)
Issue Type: Improvement  (was: Bug)

 Copying data from inputStream to OuputStream needs appropriate buffer size
 --

 Key: JCR-2914
 URL: https://issues.apache.org/jira/browse/JCR-2914
 Project: Jackrabbit Content Repository
  Issue Type: Improvement
  Components: jackrabbit-jcr-server
Affects Versions: 2.2.2
Reporter: Xiaoming Shi
Priority: Minor

 In the file:
 ./jackrabbit-2.2.2/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/server/io/IOUtil.java
line:80
 The buffer size is fixed as 8192.
 To copy 10M data with 8192-byte buffer it takes 98,905,252 nano-second, while 
 it takes 37,642,842 nano-second with a 81920-byte buffer
 We need to find an appropriate buffer size based on the size of the 
 InputStream.
 This is similar to the Apache 
 Bug:https://issues.apache.org/bugzilla/show_bug.cgi?id=32546

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Resolved: (JCR-2914) Copying data from inputStream to OuputStream needs appropriate buffer size

[Stefan Guggisberg (JIRA)]

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

Stefan Guggisberg resolved JCR-2914.


Resolution: Won't Fix

 We need to find an appropriate buffer size based on the size of the 
 InputStream. 

IOUtil is a generic utility class. InputStream doesn't provide information 
about the size of the underlying data. 

i suggest you wrap your stream in a buffering input stream. 

 Copying data from inputStream to OuputStream needs appropriate buffer size
 --

 Key: JCR-2914
 URL: https://issues.apache.org/jira/browse/JCR-2914
 Project: Jackrabbit Content Repository
  Issue Type: Improvement
  Components: jackrabbit-jcr-server
Affects Versions: 2.2.2
Reporter: Xiaoming Shi
Priority: Minor

 In the file:
 ./jackrabbit-2.2.2/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/server/io/IOUtil.java
line:80
 The buffer size is fixed as 8192.
 To copy 10M data with 8192-byte buffer it takes 98,905,252 nano-second, while 
 it takes 37,642,842 nano-second with a 81920-byte buffer
 We need to find an appropriate buffer size based on the size of the 
 InputStream.
 This is similar to the Apache 
 Bug:https://issues.apache.org/bugzilla/show_bug.cgi?id=32546

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Resolved: (JCRSITE-31) Viewing a repository of jackrabbit on Tomcat

[Stefan Guggisberg (JIRA)]

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

Stefan Guggisberg resolved JCRSITE-31.
--

Resolution: Invalid

please post your questions on the jackrabbit users list.

you'll find more information about the jackrabbit mailing lists here:
http://jackrabbit.apache.org/mailing-lists.html

 Viewing a repository of jackrabbit on Tomcat
 

 Key: JCRSITE-31
 URL: https://issues.apache.org/jira/browse/JCRSITE-31
 Project: Jackrabbit Site
  Issue Type: Wish
Reporter: Kapil Garg

 I d like to know how could I szecure the repository on tomcat for jackrabbit. 
 I also would like to know if I could browse the respository on the browser 
 for jackrabbit running on tomcat. I know one can do it on standalone jar of 
 jackrabbit using /repository/default in the URL. Can anyone give pointers or 
 suggestions? 
 Also we would like to test the update on a same document on jackrabbit. IS 
 there a preferred wayto set the repository to avoid duplication or updates?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Resolved: (JCR-2912) VersionManager.restore fails with ItemExitsException although the removeExisting parameter is set to true

[Stefan Guggisberg (JIRA)]

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

Stefan Guggisberg resolved JCR-2912.


Resolution: Duplicate

duplicate of JCR-2891

 VersionManager.restore fails with ItemExitsException although the 
 removeExisting parameter is set to true
 -

 Key: JCR-2912
 URL: https://issues.apache.org/jira/browse/JCR-2912
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-core, versioning
Affects Versions: 2.2.4
Reporter: Marlis Lamp
   Original Estimate: 0.5h
  Remaining Estimate: 0.5h

 In some cases 
 versionManager.restore(versionManager.getBaseVersion(jcrNode.getPath()), 
 true); fails with the following stack trace:
 Caused by: javax.jcr.ItemExistsException: 
 22437573-07b6-4dcd-8819-31b2c98dbf9d/{http://my.namespace}mynode 
   at 
 org.apache.jackrabbit.core.version.NodeStateEx.moveFrom(NodeStateEx.java:603) 
   at 
 org.apache.jackrabbit.core.version.VersionManagerImplRestore.internalRestoreFrozen(VersionManagerImplRestore.java:561)
  
   at 
 org.apache.jackrabbit.core.version.VersionManagerImplRestore.internalRestore(VersionManagerImplRestore.java:294)
  
   at 
 org.apache.jackrabbit.core.version.VersionManagerImplRestore.internalRestore(VersionManagerImplRestore.java:240)
  
   at 
 org.apache.jackrabbit.core.VersionManagerImpl.access$1300(VersionManagerImpl.java:72)
  
   at 
 org.apache.jackrabbit.core.VersionManagerImpl$6.perform(VersionManagerImpl.java:247)
  
   at 
 org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:200)
  
   at 
 org.apache.jackrabbit.core.VersionManagerImpl.perform(VersionManagerImpl.java:95)
  
   at 
 org.apache.jackrabbit.core.VersionManagerImpl.restore(VersionManagerImpl.java:221)
  
   at 
 org.apache.jackrabbit.core.VersionManagerImpl.restore(VersionManagerImpl.java:213)
 I've figured out that the restoration only fails if the reference comparison 
 in VersionManagerImplRestore in line 557:
 if (restoredChild.getParentId() == state.getNodeId()) {
 fails, although restoredChild.getParendId().compareTo(state.getNodeId()) 
 returns 0.
 Changing the comparison to:
 if (restoredChild.getParentId().compareTo(state.getNodeId()) == 0) {
 solves the problem. Could you please tell me if the NodeId comparison 
 suffices in this case? If so, could you please fix it in the next jackrabbit 
 version? Thank you! 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (JCR-2581) Get NPE when custom node was updated

[Stefan Guggisberg (JIRA)]

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

Stefan Guggisberg updated JCR-2581:
---

Component/s: versioning

 Get NPE when custom node was updated
 

 Key: JCR-2581
 URL: https://issues.apache.org/jira/browse/JCR-2581
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-core, versioning
Affects Versions: 2.0.0
 Environment: Windows XP
 JDK 1.5.12
 JBoss 4.2.3
Reporter: Stas

 I try to upgrade jackrabbit version in my project from 1.6 to 2.0. Some 
 things from 2.0 are very usable. Thank you all for your job. But after 
 transition on new version i get magic problems. I often catch NPE exception 
 from inside jackrabbit api. After some investigations and tests i had found 
 one of many problems.
 What i do in my test?
 I declare custom node type in cnd file. Then register it.
  [my:test]  nt:folder
   orderable
   - myp:html (string)
   = ''
 autocreated
 copy
 Call method create.
 private void testCreate(String name, String html, CredentialsTO credentials){
 Node docRootNode;
 Session session = null;
 try {
 session = getSession(credentials);
 docRootNode = session.getRootNode();
 Node testNode = docRootNode.addNode(name, my:test);
 testNode.setProperty(myp:html, html);
 testNode.addMixin(mix:versionable);
 session.save();
 
 session.getWorkspace().getVersionManager().checkin(testNode.getPath());
 } catch (Exception e) {
 //do something
 } finally {
 logout(session);
 }
 }
 Then do update.
  private void testUpdate(String name, String html, CredentialsTO credentials){
 Session session = null;
 Node docRootNode;
 try {
 session = getSession(credentials);
 docRootNode = session.getRootNode();
 Node testNode =  docRootNode.getNode(name);
 
 session.getWorkspace().getVersionManager().checkout(testNode.getPath());
 testNode.setProperty(myp:html, html);
 session.save();
 
 session.getWorkspace().getVersionManager().checkin(testNode.getPath());
 }  catch (Exception e) {
 // do something
 } finally {
 logout(session);
 }
 }
 After last checkin in update method i always catch NullPointerException. I 
 had connected src of jcr and jackrabbit and done some debug. This is method 
 which throw exception in org.apache.jackrabbit.core.ItemManager.
  private boolean canRead(ItemData data, Path path) throws 
 AccessDeniedException, RepositoryException {
 // JCR-1601: cached item may just have been invalidated
 ItemState state = data.getState();
 if (state == null) {
 throw new InvalidItemStateException(data.getId() + : the item 
 does not exist anymore);
 }
 if (state.getStatus() == ItemState.STATUS_NEW 
 !data.getDefinition().isProtected()) {  // THIS IS RIGHT 
 PLACE data.getDefinition() = null
 // NEW items can always be read as long they have been added
 // through the API and NOT by the system (i.e. protected props).
 return true;
 } else {
 return (path == null) ?
 canRead(data.getId()) :
 session.getAccessManager().canRead(path);
 }
 }
 I don't understand when and why definition in NodeData can be null? This is 
 my fault, wrong settings of repository or bug of jackrabbit?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Resolved: (JCR-2903) Session.importXml should close the input stream (as to JSR 283/JCR 2.0)

[Stefan Guggisberg (JIRA)]

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

Stefan Guggisberg resolved JCR-2903.


   Resolution: Fixed
Fix Version/s: 2.3.0

fixed in svn r1077927

 Session.importXml should close the input stream (as to JSR 283/JCR 2.0)
 ---

 Key: JCR-2903
 URL: https://issues.apache.org/jira/browse/JCR-2903
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-core, jackrabbit-jcr-rmi, 
 jackrabbit-jcr-tests, jackrabbit-jcr2spi, JCR 2.0
Affects Versions: 2.0.0, 2.0.3, 2.1.0, 2.1.1, 2.1.2, 2.1.3, 2.2.0, 2.2.1, 
 2.2.2, 2.2.4
Reporter: Alex Parvulescu
Assignee: Stefan Guggisberg
 Fix For: 2.3.0


 http://markmail.org/thread/crwx27dkt2cnjjy7
 This is available for all that follow:
   Node.setProperty(String, InputStream)
   Property.setValue(InputStream)
   ValueFactory.createValue(InputStream)
   ValueFactory.createBinary(InputStream)
   Session.importXML(String, InputStream, int)
   Workspace.importXML(String, InputStream, int)

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (JCR-2908) deadbeef-face-babe-cafe-babecafebabe has been modified externally

[Stefan Guggisberg (JIRA)]

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

Stefan Guggisberg updated JCR-2908:
---

Component/s: (was: jackrabbit-core)
 versioning
 transactions

 deadbeef-face-babe-cafe-babecafebabe has been modified externally
 -

 Key: JCR-2908
 URL: https://issues.apache.org/jira/browse/JCR-2908
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: transactions, versioning
Affects Versions: 2.2.0
 Environment: JDK1.6
 WIN XP
Reporter: codeparser

 The use case is as follows:
 1. create two node named folder1 and folder2
 2. create one thread which create twenty versionable nodes under folder1 
 within a transaction.
 3. create another thread which create twenty versionable nodes under folder2 
 within a transaction.
 4. repeat step 2 and step3 and then it will throw below Exception:
 Caused by: org.apache.jackrabbit.core.state.StaleItemStateException: 
 deadbeef-face-babe-cafe-babecafebabe has been modified externally
   at 
 org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:663)
   at 
 org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:1457)
   at 
 org.apache.jackrabbit.core.state.XAItemStateManager.prepare(XAItemStateManager.java:163)
   ... 11 more

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (JCR-2903) Session.importXml should close the input stream (as to JSR 283/JCR 2.0)

[Stefan Guggisberg (JIRA)]

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

Stefan Guggisberg updated JCR-2903:
---

Component/s: JCR 2.0
 jackrabbit-jcr-tests

 Session.importXml should close the input stream (as to JSR 283/JCR 2.0)
 ---

 Key: JCR-2903
 URL: https://issues.apache.org/jira/browse/JCR-2903
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-core, jackrabbit-jcr-rmi, 
 jackrabbit-jcr-tests, jackrabbit-jcr2spi, JCR 2.0
Affects Versions: 2.0.0, 2.0.3, 2.1.0, 2.1.1, 2.1.2, 2.1.3, 2.2.0, 2.2.1, 
 2.2.2, 2.2.4
Reporter: Alex Parvulescu
Assignee: Stefan Guggisberg

 http://markmail.org/thread/crwx27dkt2cnjjy7
 This is available for all that follow:
   Node.setProperty(String, InputStream)
   Property.setValue(InputStream)
   ValueFactory.createValue(InputStream)
   ValueFactory.createBinary(InputStream)
   Session.importXML(String, InputStream, int)
   Workspace.importXML(String, InputStream, int)

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (JCR-2907) can't get versionable node's child property after restore within transaction

[Stefan Guggisberg (JIRA)]

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

Stefan Guggisberg updated JCR-2907:
---

Component/s: (was: jackrabbit-core)
 versioning
 transactions

 can't get versionable node's child property after restore within transaction
 

 Key: JCR-2907
 URL: https://issues.apache.org/jira/browse/JCR-2907
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: transactions, versioning
Affects Versions: 2.2.0
 Environment: WIN XP
 JDK 1.6
 JBOSS 4.2
Reporter: codeparser
 Attachments: restore_test_case.txt


 The case is as follows:
 1. create a versionable node named folder and create five child and add 
 some property to the children.
 2. checkout the node folder, and add a new child, and then save
 3. begin a transaction
 4. get a new jackrabbit session
 5. get the node folder, and restore to its base version
 6. get folder's child, all the children could be getton, but the children's 
 property lost.
 but after commit the transaction, the content in the database is corret.
 7.commit transaction

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (JCR-2906) Multivalued property sorted by last/random value

[Stefan Guggisberg (JIRA)]

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

Stefan Guggisberg updated JCR-2906:
---

Component/s: (was: jackrabbit-core)
 indexing

 Multivalued property sorted by last/random value
 

 Key: JCR-2906
 URL: https://issues.apache.org/jira/browse/JCR-2906
 Project: Jackrabbit Content Repository
  Issue Type: Improvement
  Components: indexing
Affects Versions: 2.2.0
 Environment: Windows 7, Sun JDK 1.6.0_23
Reporter: Paul Lysak
  Labels: multivalued, sort

 Sorting on multivalued property may produce incorrect result because sorting 
 is performed only by last value of multivalued property.
 Steps to reproduce:
 1. Create multivalued field in repository. Example from nodetypes file:
 propertyDefinition name=MyProperty requiredType=String 
 autoCreated=false mandatory=false
onParentVersion=COPY protected=false multiple=false
 2. Create few records so that all records except one would contain single 
 value for MyProperty and one record would contain 
 first value which is greater then of any other record and the second value is 
 somewhere in the middle. Here is an example:
 1st record: 
 2nd record: 
 3rd record: , 
 3. Run some query which sorts Example of XPath query:
 //*[...here are some criteria...] order by @MyProperty ascending
 The query would return documents in such order:
 
 , 
 
 which is not expected order (expected same order as they were entered - as 
   ,   )
 After some digging I found out that it happens because method 
 org.apache.jackrabbit.core.query.lucene.SharedFieldCache.getValueIndex
 (called from 
 org.apache.jackrabbit.core.query.lucene.SharedFieldSortComparator.SimpleScoreDocComparator
  constructor)
 returns only last Comparable of the document. Here is overwrites previous 
 value:
 retArray[termDocs.doc()] = getValue(value, type);
 I tried to concatenate comparables (just to check if it would work for my 
 case):
   if(retArray[termDocs.doc()] == null) {
   retArray[termDocs.doc()] = getValue(value, type);
   } else {
   retArray[termDocs.doc()] =
   retArray[termDocs.doc()] +   + 
 getValue(value, type);
   }
 But it didn't worked well either - TermEnum returns terms not in the same 
 order as JackRabbit returns values of multivalued field
 (as an example [qwer, asdf] may become [asdf, qwer] ). So, simple 
 concatenation doesn't help.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Assigned: (JCR-2903) Session.importXml should close the input stream (as to JSR 283/JCR 2.0)

[Stefan Guggisberg (JIRA)]

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

Stefan Guggisberg reassigned JCR-2903:
--

Assignee: Stefan Guggisberg

 Session.importXml should close the input stream (as to JSR 283/JCR 2.0)
 ---

 Key: JCR-2903
 URL: https://issues.apache.org/jira/browse/JCR-2903
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-core, jackrabbit-jcr-rmi, jackrabbit-jcr2spi
Affects Versions: 2.0.0, 2.0.3, 2.1.0, 2.1.1, 2.1.2, 2.1.3, 2.2.0, 2.2.1, 
 2.2.2, 2.2.4
Reporter: Alex Parvulescu
Assignee: Stefan Guggisberg

 http://markmail.org/thread/crwx27dkt2cnjjy7
 This is available for all that follow:
   Node.setProperty(String, InputStream)
   Property.setValue(InputStream)
   ValueFactory.createValue(InputStream)
   ValueFactory.createBinary(InputStream)
   Session.importXML(String, InputStream, int)
   Workspace.importXML(String, InputStream, int)

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (JCR-2903) Session.importXml should close the input stream (as to JSR 283/JCR 2.0)

[Stefan Guggisberg (JIRA)]

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

Stefan Guggisberg updated JCR-2903:
---

Component/s: jackrabbit-core
Summary: Session.importXml should close the input stream (as to JSR 
283/JCR 2.0)  (was: Session.importXml should close the inpust stream (as to JSR 
283/JCR 2.0))

 Session.importXml should close the input stream (as to JSR 283/JCR 2.0)
 ---

 Key: JCR-2903
 URL: https://issues.apache.org/jira/browse/JCR-2903
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-core, jackrabbit-jcr2spi
Reporter: Alex Parvulescu

 http://markmail.org/thread/crwx27dkt2cnjjy7
 This is available for all that follow:
   Node.setProperty(String, InputStream)
   Property.setValue(InputStream)
   ValueFactory.createValue(InputStream)
   ValueFactory.createBinary(InputStream)
   Session.importXML(String, InputStream, int)
   Workspace.importXML(String, InputStream, int)

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (JCR-2903) Session.importXml should close the input stream (as to JSR 283/JCR 2.0)

[Stefan Guggisberg (JIRA)]

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

Stefan Guggisberg updated JCR-2903:
---

Component/s: jackrabbit-jcr-rmi

the following methods do close the passed stream if the content size exceeds 
a certain limit (e.g. 1k); this is caused by the conditional use of 
java.io.SequenceInputStream.  

  Node.setProperty(String, InputStream)
  Property.setValue(InputStream)
  ValueFactory.createValue(InputStream)
  ValueFactory.createBinary(InputStream)


 Session.importXml should close the input stream (as to JSR 283/JCR 2.0)
 ---

 Key: JCR-2903
 URL: https://issues.apache.org/jira/browse/JCR-2903
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-core, jackrabbit-jcr-rmi, jackrabbit-jcr2spi
Reporter: Alex Parvulescu

 http://markmail.org/thread/crwx27dkt2cnjjy7
 This is available for all that follow:
   Node.setProperty(String, InputStream)
   Property.setValue(InputStream)
   ValueFactory.createValue(InputStream)
   ValueFactory.createBinary(InputStream)
   Session.importXML(String, InputStream, int)
   Workspace.importXML(String, InputStream, int)

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (JCR-2903) Session.importXml should close the input stream (as to JSR 283/JCR 2.0)

[Stefan Guggisberg (JIRA)]

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

Stefan Guggisberg updated JCR-2903:
---

Affects Version/s: 2.0.0
   2.0.3
   2.1.0
   2.1.1
   2.1.2
   2.1.3
   2.2.0
   2.2.1
   2.2.2
   2.2.4

 Session.importXml should close the input stream (as to JSR 283/JCR 2.0)
 ---

 Key: JCR-2903
 URL: https://issues.apache.org/jira/browse/JCR-2903
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-core, jackrabbit-jcr-rmi, jackrabbit-jcr2spi
Affects Versions: 2.0.0, 2.0.3, 2.1.0, 2.1.1, 2.1.2, 2.1.3, 2.2.0, 2.2.1, 
 2.2.2, 2.2.4
Reporter: Alex Parvulescu

 http://markmail.org/thread/crwx27dkt2cnjjy7
 This is available for all that follow:
   Node.setProperty(String, InputStream)
   Property.setValue(InputStream)
   ValueFactory.createValue(InputStream)
   ValueFactory.createBinary(InputStream)
   Session.importXML(String, InputStream, int)
   Workspace.importXML(String, InputStream, int)

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (JCR-2891) VersionManagerImplRestore internalRestoreFrozen method has identity versus equals bug

[Stefan Guggisberg (JIRA)]

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

Stefan Guggisberg updated JCR-2891:
---

Fix Version/s: (was: 2.2.2)
   2.3.0

 VersionManagerImplRestore internalRestoreFrozen method has identity versus 
 equals bug
 -

 Key: JCR-2891
 URL: https://issues.apache.org/jira/browse/JCR-2891
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-core
Affects Versions: 2.2.2
 Environment: Exists in 2.2.4 version of code base (as well as 2.3)
Reporter: Matt Goodwin
Assignee: Stefan Guggisberg
 Fix For: 2.3.0

   Original Estimate: 10m
  Remaining Estimate: 10m

 In method protected void internalRestoreFrozen(NodeStateEx state,
  InternalFrozenNode freeze,
  VersionSelector vsel,
  SetInternalVersion restored,
  boolean removeExisting,
  boolean copy)
 in the VersionManagerImplRestore class line 557 the code performs an == 
 instead of calling the NodeId.equals() method.  We ran into problems with the 
 code that executes below this (trying to restore a folder node throws an 
 ItemExistsException since same sibling not allowed on folder nodes)

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (JCR-2891) VersionManagerImplRestore internalRestoreFrozen method has identity versus equals bug

[Stefan Guggisberg (JIRA)]

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

Stefan Guggisberg updated JCR-2891:
---

Resolution: Fixed
Status: Resolved  (was: Patch Available)

fixed in trunk (svn rev. 1071562)

 VersionManagerImplRestore internalRestoreFrozen method has identity versus 
 equals bug
 -

 Key: JCR-2891
 URL: https://issues.apache.org/jira/browse/JCR-2891
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-core
Affects Versions: 2.2.2
 Environment: Exists in 2.2.4 version of code base (as well as 2.3)
Reporter: Matt Goodwin
Assignee: Stefan Guggisberg
 Fix For: 2.3.0

   Original Estimate: 10m
  Remaining Estimate: 10m

 In method protected void internalRestoreFrozen(NodeStateEx state,
  InternalFrozenNode freeze,
  VersionSelector vsel,
  SetInternalVersion restored,
  boolean removeExisting,
  boolean copy)
 in the VersionManagerImplRestore class line 557 the code performs an == 
 instead of calling the NodeId.equals() method.  We ran into problems with the 
 code that executes below this (trying to restore a folder node throws an 
 ItemExistsException since same sibling not allowed on folder nodes)

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Can anyone commit the namespace comparison bug for the next release?

[Stefan Guggisberg]

On 17.02.2011, at 11:14, Angela Schreiber anch...@adobe.com wrote:

 
 ... or submit patches! ;-)
 
 this only helps to a limited extend as still somebody (in this very
 case it looks as if this was me)

i can do that if you're too busy.

cheers 
stefan

 needs to review the patch.
 
 what definitely would help speeding it up was not only providing
 a patch but also providing tests and providing information if all
 integration tests were passing or not... in this particular case
 the possible areas of failure could include: litmus test suite, smoke
 tests with jcr-server implementations and spi2dav. i'm not saying
 that all of that needs to be tested but indicating with the patch
 which areas were already looked at would help a lot.
 
 angela

[jira] Commented: (JCR-2877) Extend the consistency check in BundleDbPersistenceManager's to fix child-parent relations

[Stefan Guggisberg (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-2877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12992407#comment-12992407
 ] 

Stefan Guggisberg commented on JCR-2877:


 Is there a way to determine the name of the node. The child node must add 
 itself to its parent node but normally only the parent knows the name of the 
 child node ?

*only* the parent knows the names of its child nodes. that's a core aspect of 
jackrabbit's data model.
you would have to make up a new (unique) name. the child node should IMO be 
easily identifiable as a 
resurrected orphaned child node.

 Extend the consistency check in BundleDbPersistenceManager's to fix 
 child-parent relations
 --

 Key: JCR-2877
 URL: https://issues.apache.org/jira/browse/JCR-2877
 Project: Jackrabbit Content Repository
  Issue Type: Improvement
  Components: jackrabbit-core
Affects Versions: 2.2.2
Reporter: Claus Köll
Assignee: Claus Köll
Priority: Minor
 Fix For: 2.3.0


 It could happen that a child node is not in the ChildNodeEntries of its 
 parent node.
 You will get something like (javax.jcr.ItemNotFoundException: failed to build 
 path of node1: parentNode has no child entry for node1) if you try to 
 retrieve the path from node1.
 We should handle such cases and fix it on consistency check

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: indexing, jackrabbit cqfs

[Stefan Guggisberg]

On Tue, Jun 14, 2005 at 3:19 PM, Boris Kraft boris.kr...@obinary.com wrote:
 On 14.06.2005, at 10:58, Marcel Reutegger wrote:

 Boris Kraft wrote:

 Is it still possible to turn of indexing (and versioning while I am at
  it) with the current release of jackrabbit?

 If you comment out the SearchIndex tag in the workspace.xml you can
 disable the QueryManager / Indexing.

 Thanks

 The reason why I am asking is that with my latest build (from last
  Saturday) I have serious problems to get a stable repository using  cqfs.
 In particular, the repository breaks and the indexer writes out  index.dat
 files with a size of ~100GB (yes, thats Gigabyte). Obviously,  I am not
 really happy about that.
 Does anybody else experience similar behavior?

 Nope, haven't seen this before.
 It seems that you are using CQFS as the underlying filesystem for the
 search index. If this is true, I recommend to use LocalFileSystem.

 One reason for the huge index.dat file might be that the configuration for
 CQFS is not apropriate for the use as a filesystem for search index. e.g.
 the blocksize parameter has an influence on the maxmimum file size that can
 be created in CQFS.

 Yes, that might be a good idea.

 I am currently moving from cqfs to filesystem and up to now this looks quite
 promising (except for the number of files I now have). The repository is now
 stable again. It might be an issue with CQFS on OSX, I'll let you know if

wrong list.
since cqfs is a commercial product, please contact your product support channel.

cheers
stefan

 problems go away when run on windows.

 Thanks again
 - Boris

Re: Ho wto delete content in Jack Rabbit???

[Stefan Guggisberg]

[1] is a good point to start.

and please ask questions like this on the 'users' list [2].


cheers
stefan

[1] http://jackrabbit.apache.org/getting-started-with-apache-jackrabbit.html
[2] http://jackrabbit.apache.org/mailing-lists.html

On Fri, Feb 4, 2011 at 8:57 AM,  raghavendra...@sungard.com wrote:
 Hi,



 I’m new to jack Rabbit. I’m trying to remove content from jack rabbit.



 Can I achieve this with an query? If so how can I do that, please let me
 know.



 If not programmatically how can I achieve this? Please let me know.



 Thanks  regards,

 Raghav.

[jira] Updated: (JCR-2879) SQL Azure support: clustered indexes

[Stefan Guggisberg (JIRA)]

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

Stefan Guggisberg updated JCR-2879:
---

Issue Type: New Feature  (was: Bug)

 SQL Azure support: clustered indexes
 

 Key: JCR-2879
 URL: https://issues.apache.org/jira/browse/JCR-2879
 Project: Jackrabbit Content Repository
  Issue Type: New Feature
  Components: jackrabbit-core
Affects Versions: 2.2.2
 Environment: Windows Azure cloud, 64-bit, SQL Azure
Reporter: Sander Wartenberg
 Fix For: 2.2.3, 2.3.0

 Attachments: CREATE_jackrabbit.sql


 We tried to install JackRabbit in the Windows Azure cloud using SQL Azure. 
 One of the limitations of SQL Azure is that it needs clustered indexes to 
 work but the current implementation of the JackRabbit creates the indexes not 
 clustered.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (JCR-2877) Extend the consistency check in BundleDbPersistenceManager's to fix child-parent relations

[Stefan Guggisberg (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-2877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12990090#comment-12990090
 ] 

Stefan Guggisberg commented on JCR-2877:


 It could happen that a child node is not in the ChildNodeEntries of its 
 parent node. 

do you still experience such problems with 2.2? if yes, are they reproducible?

i was under the impression that we had fixed all issues which could potentially 
lead to repository corruption.

 Extend the consistency check in BundleDbPersistenceManager's to fix 
 child-parent relations
 --

 Key: JCR-2877
 URL: https://issues.apache.org/jira/browse/JCR-2877
 Project: Jackrabbit Content Repository
  Issue Type: Improvement
  Components: jackrabbit-core
Affects Versions: 2.2.2
Reporter: Claus Köll
Assignee: Claus Köll
Priority: Minor
 Fix For: 2.3.0


 It could happen that a child node is not in the ChildNodeEntries of its 
 parent node.
 You will get something like (javax.jcr.ItemNotFoundException: failed to build 
 path of node1: parentNode has no child entry for node1) if you try to 
 retrieve the path from node1.
 We should handle such cases and fix it on consistency check

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (JCR-2871) NPE in ConcurrentCache when traversing newly loaded nodes

[Stefan Guggisberg (JIRA)]

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

Stefan Guggisberg updated JCR-2871:
---

Attachment: JCR-2871.patch

patch to help isolate the issue

 NPE in ConcurrentCache when traversing newly loaded nodes
 -

 Key: JCR-2871
 URL: https://issues.apache.org/jira/browse/JCR-2871
 Project: Jackrabbit Content Repository
  Issue Type: Bug
Affects Versions: 2.2.1
 Environment: Jackrabbit 2.2.1
 Red Hat Enterprise Linux Server 5.5
 Oracle repository
Reporter: Tom Palmer
 Attachments: JCR-2871.patch, bugdup.tar.gz


 Attached sample project duplicates an exception seen when creating a 
 repository, importing nodes, and then traversing those nodes.  Exception is:
 java.lang.NullPointerException
 at 
 org.apache.jackrabbit.core.cache.ConcurrentCache$E.access$000(ConcurrentCache.java:47)
 at 
 org.apache.jackrabbit.core.cache.ConcurrentCache$1.removeEldestEntry(ConcurrentCache.java:70)
 at java.util.LinkedHashMap.putImpl(LinkedHashMap.java:409)
 at java.util.LinkedHashMap.put(LinkedHashMap.java:370)
 at 
 org.apache.jackrabbit.core.cache.ConcurrentCache.shrinkIfNeeded(ConcurrentCache.java:249)
 at 
 org.apache.jackrabbit.core.cache.ConcurrentCache.put(ConcurrentCache.java:176)
 at 
 org.apache.jackrabbit.core.state.MLRUItemStateCache.cache(MLRUItemStateCache.java:83)
 at 
 org.apache.jackrabbit.core.state.ItemStateReferenceCache.cache(ItemStateReferenceCache.java:169)
 at 
 org.apache.jackrabbit.core.state.LocalItemStateManager.getPropertyState(LocalItemStateManager.java:136)
 at 
 org.apache.jackrabbit.core.state.LocalItemStateManager.getItemState(LocalItemStateManager.java:174)
 at 
 org.apache.jackrabbit.core.state.XAItemStateManager.getItemState(XAItemStateManager.java:260)
 at 
 org.apache.jackrabbit.core.state.SessionItemStateManager.getItemState(SessionItemStateManager.java:161)
 at 
 org.apache.jackrabbit.core.ItemManager.getItemData(ItemManager.java:370)
 at 
 org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:316)
 at 
 org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:610)
 at 
 org.apache.jackrabbit.core.LazyItemIterator.prefetchNext(LazyItemIterator.java:122)
 at 
 org.apache.jackrabbit.core.LazyItemIterator.init(LazyItemIterator.java:104)
 at 
 org.apache.jackrabbit.core.LazyItemIterator.init(LazyItemIterator.java:85)
 at 
 org.apache.jackrabbit.core.ItemManager.getChildProperties(ItemManager.java:777)
 at org.apache.jackrabbit.core.NodeImpl$10.perform(NodeImpl.java:2185)
 at org.apache.jackrabbit.core.NodeImpl$10.perform(NodeImpl.java:2181)
 at 
 org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:200)
 at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:91)
 at 
 org.apache.jackrabbit.core.NodeImpl.getProperties(NodeImpl.java:2181)
 at 
 javax.jcr.util.TraversingItemVisitor.visit(TraversingItemVisitor.java:185)
 at org.apache.jackrabbit.core.NodeImpl.accept(NodeImpl.java:1705)
 at 
 javax.jcr.util.TraversingItemVisitor.visit(TraversingItemVisitor.java:191)
 at org.apache.jackrabbit.core.NodeImpl.accept(NodeImpl.java:1705)
 at 
 javax.jcr.util.TraversingItemVisitor.visit(TraversingItemVisitor.java:191)
 at org.apache.jackrabbit.core.NodeImpl.accept(NodeImpl.java:1705)
 at 
 javax.jcr.util.TraversingItemVisitor.visit(TraversingItemVisitor.java:191)
 at org.apache.jackrabbit.core.NodeImpl.accept(NodeImpl.java:1705)
 at 
 javax.jcr.util.TraversingItemVisitor.visit(TraversingItemVisitor.java:191)
 at org.apache.jackrabbit.core.NodeImpl.accept(NodeImpl.java:1705)
 at com.att.bugdup.Main.run(Main.java:60)
 at com.att.bugdup.Main.main(Main.java:35)

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (JCR-2871) NPE in ConcurrentCache when traversing newly loaded nodes

[Stefan Guggisberg (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-2871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12988114#action_12988114
 ] 

Stefan Guggisberg commented on JCR-2871:


thanks for the test case.

i tried to reproduce it on my machine (macbook pro, sun java 6) 
using the default configuration (derby), but the problem didn't
show up.

the problem is IMO unrelated to your repository configuration (oracle etc).

looks like a subtle ConcurrentCache bug.  it seems to be gc-related and 
perhaps more likely to show up on specific jvm/platform combinations.



 NPE in ConcurrentCache when traversing newly loaded nodes
 -

 Key: JCR-2871
 URL: https://issues.apache.org/jira/browse/JCR-2871
 Project: Jackrabbit Content Repository
  Issue Type: Bug
Affects Versions: 2.2.1
 Environment: Jackrabbit 2.2.1
 Red Hat Enterprise Linux Server 5.5
 Oracle repository
Reporter: Tom Palmer
 Attachments: bugdup.tar.gz


 Attached sample project duplicates an exception seen when creating a 
 repository, importing nodes, and then traversing those nodes.  Exception is:
 java.lang.NullPointerException
 at 
 org.apache.jackrabbit.core.cache.ConcurrentCache$E.access$000(ConcurrentCache.java:47)
 at 
 org.apache.jackrabbit.core.cache.ConcurrentCache$1.removeEldestEntry(ConcurrentCache.java:70)
 at java.util.LinkedHashMap.putImpl(LinkedHashMap.java:409)
 at java.util.LinkedHashMap.put(LinkedHashMap.java:370)
 at 
 org.apache.jackrabbit.core.cache.ConcurrentCache.shrinkIfNeeded(ConcurrentCache.java:249)
 at 
 org.apache.jackrabbit.core.cache.ConcurrentCache.put(ConcurrentCache.java:176)
 at 
 org.apache.jackrabbit.core.state.MLRUItemStateCache.cache(MLRUItemStateCache.java:83)
 at 
 org.apache.jackrabbit.core.state.ItemStateReferenceCache.cache(ItemStateReferenceCache.java:169)
 at 
 org.apache.jackrabbit.core.state.LocalItemStateManager.getPropertyState(LocalItemStateManager.java:136)
 at 
 org.apache.jackrabbit.core.state.LocalItemStateManager.getItemState(LocalItemStateManager.java:174)
 at 
 org.apache.jackrabbit.core.state.XAItemStateManager.getItemState(XAItemStateManager.java:260)
 at 
 org.apache.jackrabbit.core.state.SessionItemStateManager.getItemState(SessionItemStateManager.java:161)
 at 
 org.apache.jackrabbit.core.ItemManager.getItemData(ItemManager.java:370)
 at 
 org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:316)
 at 
 org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:610)
 at 
 org.apache.jackrabbit.core.LazyItemIterator.prefetchNext(LazyItemIterator.java:122)
 at 
 org.apache.jackrabbit.core.LazyItemIterator.init(LazyItemIterator.java:104)
 at 
 org.apache.jackrabbit.core.LazyItemIterator.init(LazyItemIterator.java:85)
 at 
 org.apache.jackrabbit.core.ItemManager.getChildProperties(ItemManager.java:777)
 at org.apache.jackrabbit.core.NodeImpl$10.perform(NodeImpl.java:2185)
 at org.apache.jackrabbit.core.NodeImpl$10.perform(NodeImpl.java:2181)
 at 
 org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:200)
 at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:91)
 at 
 org.apache.jackrabbit.core.NodeImpl.getProperties(NodeImpl.java:2181)
 at 
 javax.jcr.util.TraversingItemVisitor.visit(TraversingItemVisitor.java:185)
 at org.apache.jackrabbit.core.NodeImpl.accept(NodeImpl.java:1705)
 at 
 javax.jcr.util.TraversingItemVisitor.visit(TraversingItemVisitor.java:191)
 at org.apache.jackrabbit.core.NodeImpl.accept(NodeImpl.java:1705)
 at 
 javax.jcr.util.TraversingItemVisitor.visit(TraversingItemVisitor.java:191)
 at org.apache.jackrabbit.core.NodeImpl.accept(NodeImpl.java:1705)
 at 
 javax.jcr.util.TraversingItemVisitor.visit(TraversingItemVisitor.java:191)
 at org.apache.jackrabbit.core.NodeImpl.accept(NodeImpl.java:1705)
 at 
 javax.jcr.util.TraversingItemVisitor.visit(TraversingItemVisitor.java:191)
 at org.apache.jackrabbit.core.NodeImpl.accept(NodeImpl.java:1705)
 at com.att.bugdup.Main.run(Main.java:60)
 at com.att.bugdup.Main.main(Main.java:35)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (JCR-2871) NPE in ConcurrentCache when traversing newly loaded nodes

[Stefan Guggisberg (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-2871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12988116#action_12988116
 ] 

Stefan Guggisberg commented on JCR-2871:


jukka should be able to help with ConcurrentCache issues.

 NPE in ConcurrentCache when traversing newly loaded nodes
 -

 Key: JCR-2871
 URL: https://issues.apache.org/jira/browse/JCR-2871
 Project: Jackrabbit Content Repository
  Issue Type: Bug
Affects Versions: 2.2.1
 Environment: Jackrabbit 2.2.1
 Red Hat Enterprise Linux Server 5.5
 Oracle repository
Reporter: Tom Palmer
 Attachments: bugdup.tar.gz


 Attached sample project duplicates an exception seen when creating a 
 repository, importing nodes, and then traversing those nodes.  Exception is:
 java.lang.NullPointerException
 at 
 org.apache.jackrabbit.core.cache.ConcurrentCache$E.access$000(ConcurrentCache.java:47)
 at 
 org.apache.jackrabbit.core.cache.ConcurrentCache$1.removeEldestEntry(ConcurrentCache.java:70)
 at java.util.LinkedHashMap.putImpl(LinkedHashMap.java:409)
 at java.util.LinkedHashMap.put(LinkedHashMap.java:370)
 at 
 org.apache.jackrabbit.core.cache.ConcurrentCache.shrinkIfNeeded(ConcurrentCache.java:249)
 at 
 org.apache.jackrabbit.core.cache.ConcurrentCache.put(ConcurrentCache.java:176)
 at 
 org.apache.jackrabbit.core.state.MLRUItemStateCache.cache(MLRUItemStateCache.java:83)
 at 
 org.apache.jackrabbit.core.state.ItemStateReferenceCache.cache(ItemStateReferenceCache.java:169)
 at 
 org.apache.jackrabbit.core.state.LocalItemStateManager.getPropertyState(LocalItemStateManager.java:136)
 at 
 org.apache.jackrabbit.core.state.LocalItemStateManager.getItemState(LocalItemStateManager.java:174)
 at 
 org.apache.jackrabbit.core.state.XAItemStateManager.getItemState(XAItemStateManager.java:260)
 at 
 org.apache.jackrabbit.core.state.SessionItemStateManager.getItemState(SessionItemStateManager.java:161)
 at 
 org.apache.jackrabbit.core.ItemManager.getItemData(ItemManager.java:370)
 at 
 org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:316)
 at 
 org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:610)
 at 
 org.apache.jackrabbit.core.LazyItemIterator.prefetchNext(LazyItemIterator.java:122)
 at 
 org.apache.jackrabbit.core.LazyItemIterator.init(LazyItemIterator.java:104)
 at 
 org.apache.jackrabbit.core.LazyItemIterator.init(LazyItemIterator.java:85)
 at 
 org.apache.jackrabbit.core.ItemManager.getChildProperties(ItemManager.java:777)
 at org.apache.jackrabbit.core.NodeImpl$10.perform(NodeImpl.java:2185)
 at org.apache.jackrabbit.core.NodeImpl$10.perform(NodeImpl.java:2181)
 at 
 org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:200)
 at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:91)
 at 
 org.apache.jackrabbit.core.NodeImpl.getProperties(NodeImpl.java:2181)
 at 
 javax.jcr.util.TraversingItemVisitor.visit(TraversingItemVisitor.java:185)
 at org.apache.jackrabbit.core.NodeImpl.accept(NodeImpl.java:1705)
 at 
 javax.jcr.util.TraversingItemVisitor.visit(TraversingItemVisitor.java:191)
 at org.apache.jackrabbit.core.NodeImpl.accept(NodeImpl.java:1705)
 at 
 javax.jcr.util.TraversingItemVisitor.visit(TraversingItemVisitor.java:191)
 at org.apache.jackrabbit.core.NodeImpl.accept(NodeImpl.java:1705)
 at 
 javax.jcr.util.TraversingItemVisitor.visit(TraversingItemVisitor.java:191)
 at org.apache.jackrabbit.core.NodeImpl.accept(NodeImpl.java:1705)
 at 
 javax.jcr.util.TraversingItemVisitor.visit(TraversingItemVisitor.java:191)
 at org.apache.jackrabbit.core.NodeImpl.accept(NodeImpl.java:1705)
 at com.att.bugdup.Main.run(Main.java:60)
 at com.att.bugdup.Main.main(Main.java:35)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (JCR-2863) Session#importXML can't handle properly uuid collision if user has insufficient permission

[Stefan Guggisberg (JIRA)]

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

Stefan Guggisberg resolved JCR-2863.


   Resolution: Fixed
Fix Version/s: 2.3.0

fixed in svn r1064213.

 Session#importXML can't handle properly uuid collision if user has 
 insufficient permission
 --

 Key: JCR-2863
 URL: https://issues.apache.org/jira/browse/JCR-2863
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-core, xml
Affects Versions: 1.6.1, 2.2.1
Reporter: Antoine Brochard
 Fix For: 2.3.0

 Attachments: exception.txt


 When importing referenceable nodes, if there are nodes with the same uuid in 
 the workspace but the session has no sufficient permission to read them then 
 the import will fail no matter what ImportUUIDBehavior is chosen. 
 But the same xml will be imported successfully in another repository or if 
 the user have read access.
 SessionImpl.java :
  public NodeImpl getNodeById(NodeId id) ...{
 ...
  try {
 return (NodeImpl) getItemManager().getItem(id);
 } catch (AccessDeniedException ade) {
 throw new ItemNotFoundException(id.toString());
 }
 }
 SessionImporter.java :
  public void startNode(NodeInfo nodeInfo, List propInfos)...{
 ...
   if (node == null) {
 // create node
 if (id == null) {
 ...
 } else {
 // potential uuid conflict
 NodeImpl conflicting;
 try {
 conflicting = session.getNodeById(id);
 } catch (ItemNotFoundException infe) {
 conflicting = null;
 }
 if (conflicting != null) {
 // resolve uuid conflict
  ...
}
 ...
 }
 In the JCR 1.0 spec says lack of read access to an item blocks access to 
 both information about the content of that item and information about the 
 existence of the item but this should probably not be true, internally, when 
 doing an import. 
 Otherwise it means that read access to an entire workspace must be granted to 
 a user so that it could successfully use the IMPORT_UUID_CREATE_NEW behaviour.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (JCR-2863) Session#importXML can't handle properly uuid collision if user has insufficient permission

[Stefan Guggisberg (JIRA)]

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

Stefan Guggisberg updated JCR-2863:
---

Summary: Session#importXML can't handle properly uuid collision if user has 
insufficient permission  (was: Import can't handle properly uuid collision if 
user has insufficient permission)

this issue is IMO specific to Session.importXML(). 
Workspace.importXML() should not be affected.

can please confirm this?

 Session#importXML can't handle properly uuid collision if user has 
 insufficient permission
 --

 Key: JCR-2863
 URL: https://issues.apache.org/jira/browse/JCR-2863
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-core, xml
Affects Versions: 1.6.1, 2.2.1
Reporter: Antoine Brochard
 Attachments: exception.txt


 When importing referenceable nodes, if there are nodes with the same uuid in 
 the workspace but the session has no sufficient permission to read them then 
 the import will fail no matter what ImportUUIDBehavior is chosen. 
 But the same xml will be imported successfully in another repository or if 
 the user have read access.
 SessionImpl.java :
  public NodeImpl getNodeById(NodeId id) ...{
 ...
  try {
 return (NodeImpl) getItemManager().getItem(id);
 } catch (AccessDeniedException ade) {
 throw new ItemNotFoundException(id.toString());
 }
 }
 SessionImporter.java :
  public void startNode(NodeInfo nodeInfo, List propInfos)...{
 ...
   if (node == null) {
 // create node
 if (id == null) {
 ...
 } else {
 // potential uuid conflict
 NodeImpl conflicting;
 try {
 conflicting = session.getNodeById(id);
 } catch (ItemNotFoundException infe) {
 conflicting = null;
 }
 if (conflicting != null) {
 // resolve uuid conflict
  ...
}
 ...
 }
 In the JCR 1.0 spec says lack of read access to an item blocks access to 
 both information about the content of that item and information about the 
 existence of the item but this should probably not be true, internally, when 
 doing an import. 
 Otherwise it means that read access to an entire workspace must be granted to 
 a user so that it could successfully use the IMPORT_UUID_CREATE_NEW behaviour.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (JCR-2833) Definition of a property with '-' in the name (e.g.: wrprop:e-mail) is wrongly interpreted by CompactNodeTypeDefReader

[Stefan Guggisberg (JIRA)]

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

Stefan Guggisberg resolved JCR-2833.


Resolution: Invalid

you should enclose the name in quotes , e.g.

tst = 'http://namespace.org/tst'
[tst:JCR2833] mixin
  - tst:e-mail (string)

see 25.2.3 CND Grammar of the JSR-283 spec:

quote
Quotes are used to allow for strings (i.e., names, prefixes,
URIs, values or constraint strings) with characters that
would otherwise be interpreted as delimiters in CND.
/quote

 Definition of  a property with '-' in the name (e.g.: wrprop:e-mail) is 
 wrongly interpreted by CompactNodeTypeDefReader
 ---

 Key: JCR-2833
 URL: https://issues.apache.org/jira/browse/JCR-2833
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-core
Affects Versions: 2.1.2
Reporter: Luca Tagliani

 Registering a nodetype with a property with '-' inside the name lead to the 
 creation of a property every '-' found.
 E.g.:
 ...
 - wrprop:e-mail
 ...
 creates a property wrprop:e and a property mail.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

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

[Stefan Guggisberg (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-2859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12977797#action_12977797
 ] 

Stefan Guggisberg commented on JCR-2859:


 There is a theoretical way of adding the lock token to another session, but 
 in most cases the lock token is not available. 

why? if a client does create an open-scoped lock (he has to do so explicitly) 
he's responsible for persisting the lock token
for future use. if the client doesn't want to do that he should use 
session-scoped locks instead.

 There is no API in JCR to get the lock token 

LockManager.lock(...) returns a Lock instance = Lock.getLockToken()

  I think it would make sense to allow all sessions from the same user to 
 unlock the node

-1, i'd consider this rather a hack; the current behavior is IMO correct. 

 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.0
Reporter: Carsten Ziegeler

 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 not available.
 Fortunately, the spec allows to relax this behaviour and I think it would 
 make sense to allow all sessions from the same user to unlock the node - this 
 is still in compliance with the spec but would make unlocked locked nodes 
 possible in a programmatic way.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

unable to build trunk: missing dependency

[Stefan Guggisberg]

hi,

i am unable to build jackrabbit trunk (r1043943).
maven is complaining about some missing dependency,

edu.ucar:netcdf:jar:4.2-min

am i the only one having problems?
what is this dependency for?

cheers
stefan

Re: unable to build trunk: missing dependency

[Stefan Guggisberg]

never mind, the build succeeds again. seems like some temporary
maven repo problem.

however, i don't know what this jackrabbit-core dependency is good for...

cheers
stefan

On Thu, Dec 9, 2010 at 1:49 PM, Stefan Guggisberg
stefan.guggisb...@gmail.com wrote:
 hi,

 i am unable to build jackrabbit trunk (r1043943).
 maven is complaining about some missing dependency,

 edu.ucar:netcdf:jar:4.2-min

 am i the only one having problems?
 what is this dependency for?

 cheers
 stefan

[jira] Resolved: (JCR-2839) o.a.jr.c.p.pool.DerbyPersistenceManager not compatible with o.a.jr.c.p.db.DerbyPersistenceManager

[Stefan Guggisberg (JIRA)]

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

Stefan Guggisberg resolved JCR-2839.


Resolution: Not A Problem

o.a.jr.c.p.pool.DerbyPersistenceManager is a SimpleDbPersistenceManager
(every node and property is stored in a single record)

o.a.jr.c.p.db.DerbyPersistenceManager is a BundleDbPersistenceManager
(a node and its properties are 'bundled' in 1 record)

apparently, they use different schemas to store the content. they were 
never meant to be compatible.

 o.a.jr.c.p.pool.DerbyPersistenceManager not compatible with 
 o.a.jr.c.p.db.DerbyPersistenceManager
 ---

 Key: JCR-2839
 URL: https://issues.apache.org/jira/browse/JCR-2839
 Project: Jackrabbit Content Repository
  Issue Type: Bug
Affects Versions: 2.1.1, 2.3.0
Reporter: Clemens Wyss

  I create a copy of a jackrabbit repository with 
 org.apache.jackrabbit.core.RepositoryCopier (using  
 org.apache.jackrabbit.core.persistence.pool.DerbyPersistenceManager).
 Trying to access this copy with 
 org.apache.jackrabbit.core.persistence.db.DerbyPersistenceManager
  fails.
 Testcase:
 1) create a repository.xml file with 
 org.apache.jackrabbit.core.persistence.pool.DerbyPersistenceManager
 2) start/stop jackrabbit
 3) change repository.xml to 
 org.apache.jackrabbit.core.persistence.db.DerbyPersistenceManager
 4) start jackrabbit
 or vice versa

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (JCR-2839) o.a.jr.c.p.pool.DerbyPersistenceManager not compatible with o.a.jr.c.p.db.DerbyPersistenceManager

[Stefan Guggisberg (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-2839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12969864#action_12969864
 ] 

Stefan Guggisberg commented on JCR-2839:


 To be clear, it's actually the reverse... 

mea culpa, sorry

justin is of course right

 o.a.jr.c.p.pool.DerbyPersistenceManager not compatible with 
 o.a.jr.c.p.db.DerbyPersistenceManager
 ---

 Key: JCR-2839
 URL: https://issues.apache.org/jira/browse/JCR-2839
 Project: Jackrabbit Content Repository
  Issue Type: Bug
Affects Versions: 2.1.1, 2.3.0
Reporter: Clemens Wyss

  I create a copy of a jackrabbit repository with 
 org.apache.jackrabbit.core.RepositoryCopier (using  
 org.apache.jackrabbit.core.persistence.pool.DerbyPersistenceManager).
 Trying to access this copy with 
 org.apache.jackrabbit.core.persistence.db.DerbyPersistenceManager
  fails.
 Testcase:
 1) create a repository.xml file with 
 org.apache.jackrabbit.core.persistence.pool.DerbyPersistenceManager
 2) start/stop jackrabbit
 3) change repository.xml to 
 org.apache.jackrabbit.core.persistence.db.DerbyPersistenceManager
 4) start jackrabbit
 or vice versa

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [jr3] One Project

[Stefan Guggisberg]

On Tue, Nov 30, 2010 at 9:06 PM, Alexander Klimetschek
aklim...@adobe.com wrote:
 On 30.11.10 20:59, Alexander Klimetschek aklim...@adobe.com wrote:

On 30.11.10 15:21, Thomas Mueller muel...@adobe.com wrote:
But I don't think there are too many
projects inside Jackrabbit.

So a single class project / jar file is desirable?

No, I meant the current modularization is fine.

 Except for: it should be easier to plugin things like custom ACLproviders
 or Persistence Managers.

sure, do you now of any serious db engine where the persistence layer
is pluggable?

that's a big -1 from my side.

cheers
stefan

 This has indirect influence on the modularization.

 Regards,
 Alex

 --
 Alexander Klimetschek
 Developer // Adobe (Day) // Berlin - Basel

Re: [jr3] One Project

[Stefan Guggisberg]

On Wed, Dec 1, 2010 at 10:43 AM, Bertrand Delacretaz
bdelacre...@apache.org wrote:
 On Wed, Dec 1, 2010 at 10:36 AM, Stefan Guggisberg
 stefan.guggisb...@gmail.com wrote:
 On Tue, Nov 30, 2010 at 9:06 PM, Alexander Klimetschek
 aklim...@adobe.com wrote:
 On 30.11.10 20:59, Alexander Klimetschek aklim...@adobe.com wrote:
 ...Except for: it should be easier to plugin things like custom ACLproviders
 or Persistence Managers.

 sure, do you now of any serious db engine where the persistence layer
 is pluggable?...

 See http://dev.mysql.com/doc/refman/5.1/en/storage-engines.html for example.

got me ;) i guess i wasn't clear enough, sorry. i interpreted easier
to plugin
with dynamically plugin or hot pluggable.

FWIW: the 'pluggable' storage engines concept of mysql comes at a
certain cost.
see e.g. [1] for related comments.

when i could go back in time i wouldn't make PersistanceManager a
public api anymore ;)

cheers
stefan

[1] 
http://www.mysqlperformanceblog.com/2010/05/08/the-doom-of-multiple-storage-engines/


 -Bertrand

Re: [jr3] One Project

[Stefan Guggisberg]

On Tue, Nov 30, 2010 at 1:46 PM, Bertrand Delacretaz
bdelacre...@apache.org wrote:
 Hi,

 (I'm not a developer here, so consider this peanut gallery talk)

 On Tue, Nov 30, 2010 at 11:42 AM, Thomas Mueller muel...@adobe.com wrote:
 I think reducing the number of
 projects for Jackrabbit 3 will result in a simpler, more standard build

 Reducing the number of Maven modules probably makes sense, but just
 one module is probably too much of a restriction. Granularity is a
 hard problem, and extreme views on that usually don't work, in my
 experience.

 ...If we include all dependencies (such as Apache Commons jar files) you
 would need a special class loader, right? Otherwise there may be conflicts
 with if somebody already uses a different version of a Apache Commons
 library that Jackrabbit also uses. That would be quite complex I guess, so
 I wouldn't do that. Instead, I would just concentrate on having as few jar
 files as possible...

 OSGi solves that problem nicely,

so you can have multiple versions of the same jar/bundle concurrently
deployed in the same osgi container?

 and the base framework is not heavy at all.

 Having a small set of OSGi-friendly (but maybe not OSGi-based, for
 broad use) jars for jr3, and combining them with an OSGi runtime for
 the out-of-the-box jr3 runnable jar, might be the best way to solve
 this.

... I think it would be an advantage if we could reduce the
 number of dependencies however (maybe even make Lucene optional - that
 would allow to use Jackrabbit on Android)

 Agree about making indexing/search pluggable - I have a few use cases
 in mind (like using Solr or what Apache Stanbol is starting to create)
 where alternate/multiple indexing systems would add a lot of value.

 BTW, is there an agreed upon set of goals for jr3 somewhere?

 There have been discussions on this list, but if jr3 development is
 about to ramp up now might be a good time to make sure all developers
 are on the same page w.r.t development goals and constraints.

 -Bertrand

Re: [jr3] One Project

[Stefan Guggisberg]

On Wed, Dec 1, 2010 at 12:15 PM, Bertrand Delacretaz
bdelacre...@apache.org wrote:
 On Wed, Dec 1, 2010 at 11:42 AM, Stefan Guggisberg
 stefan.guggisb...@gmail.com wrote:
 On Tue, Nov 30, 2010 at 1:46 PM, Bertrand Delacretaz
 bdelacre...@apache.org wrote:
 On Tue, Nov 30, 2010 at 11:42 AM, Thomas Mueller muel...@adobe.com wrote:
 I think reducing the number of
 ...If we include all dependencies (such as Apache Commons jar files) you
 would need a special class loader, right? Otherwise there may be conflicts
 with if somebody already uses a different version of a Apache Commons
 library that Jackrabbit also uses. That would be quite complex I guess, so
 I wouldn't do that. Instead, I would just concentrate on having as few jar
 files as possible...

 OSGi solves that problem nicely,

 so you can have multiple versions of the same jar/bundle concurrently
 deployed in the same osgi container?

 Yes, either by embedding problematic jars in others and hiding them as
 private packages, or by setting the right version numbers in the OSGi
 manifests, so that bundles get wired to the right libraries.

 That's in theory, you know how practice goes ;-)

i take that as in practice, OSGi *doesn't* solves that problem nicely ;-)

cheers
stefan


 Anyway, right now my ideal view as a Jackrabbit user would be to get
 OSGi-friendly jars of the various Jackrabbit modules (core, indexing,
 webdav etc.) to be able to assemble them in my OSGi container, and
 replace the ones that I'd like to replace with my own variants.

 Whether the Jackrabbit runnable jar uses OSGi is up to the Jackrabbit
 developers, but from the user's point of view I think that's important
 - two major users of Jackrabbit are Day/Adobe and Sakai, which both
 run on  OSGi, and with the current jars replacing/extending some
 things is a bit painful.

 -Bertrand

Re: [jr3] One Project

[Stefan Guggisberg]

On Wed, Dec 1, 2010 at 2:10 PM, Bertrand Delacretaz
bdelacre...@apache.org wrote:
 On Wed, Dec 1, 2010 at 2:04 PM, Stefan Guggisberg
 stefan.guggisb...@gmail.com wrote:
 On Wed, Dec 1, 2010 at 12:15 PM, Bertrand Delacretaz
 bdelacre...@apache.org wrote:
 On Wed, Dec 1, 2010 at 11:42 AM, Stefan Guggisberg
...
 OSGi solves that problem nicely,

 so you can have multiple versions of the same jar/bundle concurrently
 deployed in the same osgi container?

 Yes, either by embedding problematic jars in others and hiding them as
 private packages, or by setting the right version numbers in the OSGi
 manifests, so that bundles get wired to the right libraries.

 That's in theory, you know how practice goes ;-)

 i take that as in practice, OSGi *doesn't* solves that problem nicely ;-)

 I should have been clearer, I suggested two ways of solving the
 problem of conflictings jars with OSGi:

 a) embed them in bundles as private packages
 b) use OSGi version numbers to get the proper wiring

 Both are fully supported by OSGi, and by Apache Felix AFAIK.

 As for myself, I have not tried b) yet, so I cannot confirm that this
 works in practice, or how well.

i tried b) with apache felix in the past, and it didn't work...


 I have used a) however, and that works fine and is easy to implement.

agreed, but that's not what i thought 'componentized' design is all about... ;)

cheers
stefan


 Just to be clear ;-)
 -Bertrand

[jira] Updated: (JCR-2740) On missing child node, automatically rename entry when trying to add a node with the same name

[Stefan Guggisberg (JIRA)]

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

Stefan Guggisberg updated JCR-2740:
---

Attachment: JCR-2740-d.patch

fixed some copypaste errors,
+1 for JCR-2740-d.patch

thanks!

 On missing child node, automatically rename entry when trying to add a node 
 with the same name
 --

 Key: JCR-2740
 URL: https://issues.apache.org/jira/browse/JCR-2740
 Project: Jackrabbit Content Repository
  Issue Type: New Feature
  Components: jackrabbit-core
Reporter: Thomas Mueller
Assignee: Thomas Mueller
 Attachments: jcr-2740-b.patch, jcr-2740-c.patch, JCR-2740-d.patch, 
 jcr-2740.patch


 If a node points to a non-existing child node (which is a repository 
 inconsistency), currently this child node is silently ignored for read 
 operations (as far as I can tell). However, when trying to add another child 
 node with the same name, an exception is thrown with a message saying a child 
 node with this name already exists.
 I suggest to rename the missing child node entry in that case (for example 
 add the current date/time, or a random digit until there is no conflict), and 
 then continue with adding the new child node. I wouldn't automatically remove 
 the bad entry, because the node might appear later (after a restore), and 
 because removing data from the repository seems wrong.
 It's not a perfect solution, but it might be better than throwing an 
 exception and basically preventing changes.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (JCR-2813) overwriting cached entry warnings

[Stefan Guggisberg (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-2813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12935358#action_12935358
 ] 

Stefan Guggisberg commented on JCR-2813:


 In revision 1038201 I added a mechanism that avoids the big synchronization 
 block but still makes sure that no two threads can concurrently load the same 
 item.

excellent, thanks!

 overwriting cached entry warnings
 ---

 Key: JCR-2813
 URL: https://issues.apache.org/jira/browse/JCR-2813
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-core
Reporter: Stefan Guggisberg
Priority: Critical
 Fix For: 2.0.4, 2.1.3, 2.2.0


 when using multiple concurrent sessions you'll find *lots* of log entries 
 like:
 03.11.2010 21:17:03 *WARN * ItemStateReferenceCache: overwriting cached 
 entry ad79ca57-5eb1-4b7d-a439-a9fd73cc8c5a (ItemStateReferenceCache.java, 
 line 176)
 those are actually legitimate warnings since there's a siginificant risk of 
 data loss/inconsistency involved.
 this is apparently a regression of changes introduced by JCR-2699, 
 specifically svn r1004223

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (JCR-2740) On missing child node, automatically rename entry when trying to add a node with the same name

[Stefan Guggisberg (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-2740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12935412#action_12935412
 ] 

Stefan Guggisberg commented on JCR-2740:


+1 for jcr-2740-b.patch in general, thanks!

some minor concerns:

- i'd rather use getters instead of direct field access. 
  we could avoid direct field access by passing a 
  SessionContext instance instead of ItemManager 
  in the LazyItemIterator constructor.

- instead of printing a stacktrace directly to System.err 
  i'd prefer to log the error 

 On missing child node, automatically rename entry when trying to add a node 
 with the same name
 --

 Key: JCR-2740
 URL: https://issues.apache.org/jira/browse/JCR-2740
 Project: Jackrabbit Content Repository
  Issue Type: New Feature
  Components: jackrabbit-core
Reporter: Thomas Mueller
Assignee: Thomas Mueller
 Attachments: jcr-2740-b.patch, jcr-2740.patch


 If a node points to a non-existing child node (which is a repository 
 inconsistency), currently this child node is silently ignored for read 
 operations (as far as I can tell). However, when trying to add another child 
 node with the same name, an exception is thrown with a message saying a child 
 node with this name already exists.
 I suggest to rename the missing child node entry in that case (for example 
 add the current date/time, or a random digit until there is no conflict), and 
 then continue with adding the new child node. I wouldn't automatically remove 
 the bad entry, because the node might appear later (after a restore), and 
 because removing data from the repository seems wrong.
 It's not a perfect solution, but it might be better than throwing an 
 exception and basically preventing changes.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: mongodb or couchdb?

[Stefan Guggisberg]

On Fri, Nov 19, 2010 at 8:41 PM, John Langley
john.lang...@mathworks.com wrote:
 Has anyone recently looked at creating a persistence manager based on either
 mongodb or couchdb?

what kind of improvements would you expect from a mongodb or couchdb
persistence manager?

if you're after raw performance, i'm rather skeptical. the ideal
persistance store is IMO
a simple but highly optimized in-proc key-value store (e.g. something
like an embedded
java berkeley db). embedded derby, although a full rdbms, comes IMO
pretty close.

i doubt that a standalone engine (couch/mongo) will be able to provide
a better performance
than an embedded engine, but i might be wrong ;-)

BTW: implementing a couchdb/mongodb pm should be straight forward.
the PersistenceManager interface is pretty simple [1].

cheers
stefan

[1] 
http://jackrabbit.apache.org/api/2.1/org/apache/jackrabbit/core/persistence/PersistenceManager.html




 I did see the discussion about Unified Persistence and jr3. But it doesn’t
 seem like anyone’s considering doing this for jackrabbit 2.x Is that right?
 Are there reasons not to?



 Thanks in advance for any pointers



 -  Langley

[jira] Created: (JCR-2813) overwriting cached entry warnings

[Stefan Guggisberg (JIRA)]

overwriting cached entry warnings
---

 Key: JCR-2813
 URL: https://issues.apache.org/jira/browse/JCR-2813
 Project: Jackrabbit Content Repository
  Issue Type: Bug
Reporter: Stefan Guggisberg
Priority: Critical


when using multiple concurrent sessions you'll find *lots* of log entries like:

03.11.2010 21:17:03 *WARN * ItemStateReferenceCache: overwriting cached 
entry ad79ca57-5eb1-4b7d-a439-a9fd73cc8c5a (ItemStateReferenceCache.java, line 
176)

those are actually legitimate warnings since there's a siginificant risk of 
data loss/inconsistency involved.

this is apparently a regression of changes introduced by JCR-2699, specifically 
svn r1004223

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (JCR-2813) overwriting cached entry warnings

[Stefan Guggisberg (JIRA)]

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

Stefan Guggisberg resolved JCR-2813.


Resolution: Fixed

partially reverted changes of svn r1004223, 

New Revision: 1036117

 overwriting cached entry warnings
 ---

 Key: JCR-2813
 URL: https://issues.apache.org/jira/browse/JCR-2813
 Project: Jackrabbit Content Repository
  Issue Type: Bug
Reporter: Stefan Guggisberg
Priority: Critical

 when using multiple concurrent sessions you'll find *lots* of log entries 
 like:
 03.11.2010 21:17:03 *WARN * ItemStateReferenceCache: overwriting cached 
 entry ad79ca57-5eb1-4b7d-a439-a9fd73cc8c5a (ItemStateReferenceCache.java, 
 line 176)
 those are actually legitimate warnings since there's a siginificant risk of 
 data loss/inconsistency involved.
 this is apparently a regression of changes introduced by JCR-2699, 
 specifically svn r1004223

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (JCR-2807) ConcurrentModificationException in SessionItemStateManager.getIdOfRootTransientNodeState()

[Stefan Guggisberg (JIRA)]

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

Stefan Guggisberg resolved JCR-2807.


   Resolution: Fixed
Fix Version/s: 2.2.0

fixed in svn r1034395

 ConcurrentModificationException in 
 SessionItemStateManager.getIdOfRootTransientNodeState()
 --

 Key: JCR-2807
 URL: https://issues.apache.org/jira/browse/JCR-2807
 Project: Jackrabbit Content Repository
  Issue Type: Bug
Affects Versions: 2.1.2
Reporter: Weston Bustraan
Assignee: Stefan Guggisberg
 Fix For: 2.2.0


 SessionItemStateManager.getIdOfRootTransientNodeState() is throwing a 
 ConcurrentModificationException on line 607:
 Here's a snippet of the code:
 {code}
 for (NodeId id : candidateIds) {
 if (nodeId.equals(id) || hierMgr.isAncestor(id, 
 nodeId)) {
 // already a candidate or a descendant thereof
 // = skip
 skip = true;
 break;
 }
 if (hierMgr.isAncestor(nodeId, id)) {
 // candidate is a descendant = remove
 candidateIds.remove(id);
 }
 }
 {code}
 Can't use Collection.remove(Object) in the middle of iterating. It should 
 probably be changed to use Iterator.remove():
 {code}
 IteratorNodeId nodeIdItor = candidateIds.iterator();
 while (nodeIdItor.hasNext()) {
 NodeId id = nodeIdItor.next();
 if (nodeId.equals(id) || hierMgr.isAncestor(id, 
 nodeId)) {
 // already a candidate or a descendant thereof
 // = skip
 skip = true;
 break;
 }
 if (hierMgr.isAncestor(nodeId, id)) {
 // candidate is a descendant = remove
 nodeIdItor.remove();
 }
 }
 {code}
 Any idea what I could do differently to workaround the issue?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (JCR-2740) On missing child node, automatically rename entry when trying to add a node with the same name

[Stefan Guggisberg (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-2740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12930986#action_12930986
 ] 

Stefan Guggisberg commented on JCR-2740:


thanks for the patch, a few comments:

- i like the idea of automatically fixing inconsistencies when they're 
encountered;
  however, i am a bit concerned that the corresponding warnings in the log 
  don't get noticed and the user might be unaware of a repository becoming 
gradually 
  corrupt. i suggest to control the proposed behavior through a flag (e.g. a 
system property),
  and that this feature is disabled by default.

- there's a potential problem in the patched addNode() method.

+// loop until we either find an existing child node,
+// or we are sure no such child node exists
+ChildNodeEntry cne = thisState.getChildNodeEntry(nodeName, 1);
+existing = null;
+if (cne != null) {
+try {
+existing = itemMgr.getNode(cne.getId(), getNodeId());
+} catch (ItemNotFoundException e) {
+// the item was removed in the persistence manager,
+// which is a repository inconsistency - there is nothing
+// we can do, so the child node entry is removed now
+log.warn(Node  + getPath() + / + cne.getName() +   +
+(index  + cne.getIndex() + , id  + cne.getId() 
+
+parent id  + getId() + )  +
+not found; removing, e);
+removeChildNode(cne.getId());
+continue;
+}
+}
 
  the existence is checked through the ItemManager which 
  depends on access control, i.e. an ItemNotFoundException might 
  be thrown because the current session is not allowed to read 
  that particular node...
  

 On missing child node, automatically rename entry when trying to add a node 
 with the same name
 --

 Key: JCR-2740
 URL: https://issues.apache.org/jira/browse/JCR-2740
 Project: Jackrabbit Content Repository
  Issue Type: New Feature
  Components: jackrabbit-core
Reporter: Thomas Mueller
Assignee: Thomas Mueller
 Attachments: jcr-2740.patch


 If a node points to a non-existing child node (which is a repository 
 inconsistency), currently this child node is silently ignored for read 
 operations (as far as I can tell). However, when trying to add another child 
 node with the same name, an exception is thrown with a message saying a child 
 node with this name already exists.
 I suggest to rename the missing child node entry in that case (for example 
 add the current date/time, or a random digit until there is no conflict), and 
 then continue with adding the new child node. I wouldn't automatically remove 
 the bad entry, because the node might appear later (after a restore), and 
 because removing data from the repository seems wrong.
 It's not a perfect solution, but it might be better than throwing an 
 exception and basically preventing changes.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (JCR-2807) ConcurrentModificationException in SessionItemStateManager.getIdOfRootTransientNodeState()

[Stefan Guggisberg (JIRA)]

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

Stefan Guggisberg reassigned JCR-2807:
--

Assignee: Stefan Guggisberg

 ConcurrentModificationException in 
 SessionItemStateManager.getIdOfRootTransientNodeState()
 --

 Key: JCR-2807
 URL: https://issues.apache.org/jira/browse/JCR-2807
 Project: Jackrabbit Content Repository
  Issue Type: Bug
Affects Versions: 2.1.2
Reporter: Weston Bustraan
Assignee: Stefan Guggisberg

 SessionItemStateManager.getIdOfRootTransientNodeState() is throwing a 
 ConcurrentModificationException on line 607:
 Here's a snippet of the code:
 {code}
 for (NodeId id : candidateIds) {
 if (nodeId.equals(id) || hierMgr.isAncestor(id, 
 nodeId)) {
 // already a candidate or a descendant thereof
 // = skip
 skip = true;
 break;
 }
 if (hierMgr.isAncestor(nodeId, id)) {
 // candidate is a descendant = remove
 candidateIds.remove(id);
 }
 }
 {code}
 Can't use Collection.remove(Object) in the middle of iterating. It should 
 probably be changed to use Iterator.remove():
 {code}
 IteratorNodeId nodeIdItor = candidateIds.iterator();
 while (nodeIdItor.hasNext()) {
 NodeId id = nodeIdItor.next();
 if (nodeId.equals(id) || hierMgr.isAncestor(id, 
 nodeId)) {
 // already a candidate or a descendant thereof
 // = skip
 skip = true;
 break;
 }
 if (hierMgr.isAncestor(nodeId, id)) {
 // candidate is a descendant = remove
 nodeIdItor.remove();
 }
 }
 {code}
 Any idea what I could do differently to workaround the issue?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (JCR-2807) ConcurrentModificationException in SessionItemStateManager.getIdOfRootTransientNodeState()

[Stefan Guggisberg (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-2807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12928972#action_12928972
 ] 

Stefan Guggisberg commented on JCR-2807:


 Any idea what I could do differently to workaround the issue?

this code is only executed when the current session doesn't 
have read permission on root node.

so either grant read access on root or call save() on the
'dirty' node directly instead of calling session.save() or
rootNode.Save().

 ConcurrentModificationException in 
 SessionItemStateManager.getIdOfRootTransientNodeState()
 --

 Key: JCR-2807
 URL: https://issues.apache.org/jira/browse/JCR-2807
 Project: Jackrabbit Content Repository
  Issue Type: Bug
Affects Versions: 2.1.2
Reporter: Weston Bustraan
Assignee: Stefan Guggisberg

 SessionItemStateManager.getIdOfRootTransientNodeState() is throwing a 
 ConcurrentModificationException on line 607:
 Here's a snippet of the code:
 {code}
 for (NodeId id : candidateIds) {
 if (nodeId.equals(id) || hierMgr.isAncestor(id, 
 nodeId)) {
 // already a candidate or a descendant thereof
 // = skip
 skip = true;
 break;
 }
 if (hierMgr.isAncestor(nodeId, id)) {
 // candidate is a descendant = remove
 candidateIds.remove(id);
 }
 }
 {code}
 Can't use Collection.remove(Object) in the middle of iterating. It should 
 probably be changed to use Iterator.remove():
 {code}
 IteratorNodeId nodeIdItor = candidateIds.iterator();
 while (nodeIdItor.hasNext()) {
 NodeId id = nodeIdItor.next();
 if (nodeId.equals(id) || hierMgr.isAncestor(id, 
 nodeId)) {
 // already a candidate or a descendant thereof
 // = skip
 skip = true;
 break;
 }
 if (hierMgr.isAncestor(nodeId, id)) {
 // candidate is a descendant = remove
 nodeIdItor.remove();
 }
 }
 {code}
 Any idea what I could do differently to workaround the issue?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (JCR-2802) Deprecate all non-bundle persistence managers

[Stefan Guggisberg (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-2802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12927876#action_12927876
 ] 

Stefan Guggisberg commented on JCR-2802:


+1

 Deprecate all non-bundle persistence managers
 -

 Key: JCR-2802
 URL: https://issues.apache.org/jira/browse/JCR-2802
 Project: Jackrabbit Content Repository
  Issue Type: Improvement
  Components: config, jackrabbit-core
Reporter: Jukka Zitting
 Fix For: 2.2.0


 Bundle persistence has been the recommended default since Jackrabbit 1.3, and 
 there is little reason for anyone to be using non-bundle persistence anymore. 
 Thus I'd like to deprecate all non-bundle PMs in Jackrabbit 2.2 and target 
 for their removal in Jackrabbit 3.0.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Images problem in jackrabbit

[Stefan Guggisberg]

On Thu, Oct 28, 2010 at 3:50 PM, Bhavesh Bhanushali
b.r.bhanush...@gmail.com wrote:
 Hi,

 I am newbie in using jackrabbit, I am facing a strange issue when i am
 storing and retrieving images from jackrabbit. The text in the images
 fetched are garbled and size is reduced.

 I apologize if i am sending to wrong mailing list. I tried to subscribe to
 user's mailing list but it is throwing errors.

 Meanwhile, here is the strange problem.

 The image is stored into jackrabbit by using following piece of code

 -
  Node fileNode = contentNode.addNode(content.getFileName(),
 NodeType.NT_FILE);
                                 Node _fileContentNode =
 fileNode.addNode(JcrConstants.JCR_CONTENT, NodeType.NT_RESOURCE);

  _fileContentNode.setProperty(JcrConstants.JCR_MIMETYPE,
 content.getMimeType());

  _fileContentNode.setProperty(JcrConstants.JCR_DATA,
 ValueFactoryImpl.getInstance().createBinary(new
 ByteArrayInputStream(IOUtils.toByteArray(content.getFile().getInputStream();

just a detail, but ...  why don't you pass the stream directly?

e.g.
InputStream stream = content.getFile().getInputStream();
try {
_fileContentNode.setProperty(JcrConstants.JCR_DATA,
ValueFactoryImpl.getInstance().createBinary(stream));
} finally {
IOUtils. closeQuietly(stream);
}

cheers
stefan

                                  session.save();
 -

 when i retrieve the image using the proper path, the image is fetched with
 no problem but the text of the image is garbled and is not readable.

 Please refer attachment, actual image uploaded is
 math_eq1_to_repository.png and fetched image is
 math_eq1_from_repository.png

 Same thing happens with GIF and JPEG images.

 I am not sure what is the wrong in the above code.

 Request you all to help me to fix this strange issue.

 Jackrabbit version used is 2.1.0

 Thanks,
 Bhavesh R Bhanushali

[jira] Created: (JCR-2799) QPropertyDefinitionImpl.equals() is implemented incorrectly

[Stefan Guggisberg (JIRA)]

QPropertyDefinitionImpl.equals() is implemented incorrectly 


 Key: JCR-2799
 URL: https://issues.apache.org/jira/browse/JCR-2799
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-spi-commons
Reporter: Stefan Guggisberg
 Fix For: 2.2.0




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (JCR-2799) QPropertyDefinitionImpl.equals() is implemented incorrectly

[Stefan Guggisberg (JIRA)]

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

Stefan Guggisberg resolved JCR-2799.


Resolution: Fixed

fixed in svn r1027182

 QPropertyDefinitionImpl.equals() is implemented incorrectly 
 

 Key: JCR-2799
 URL: https://issues.apache.org/jira/browse/JCR-2799
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-spi-commons
Reporter: Stefan Guggisberg
 Fix For: 2.2.0




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (JCR-2788) Provide a JackrabbitNode#setMixins(String[] mixinNames) method

[Stefan Guggisberg (JIRA)]

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

Stefan Guggisberg resolved JCR-2788.


Resolution: Fixed

implemented in svn r1027183

 Provide a JackrabbitNode#setMixins(String[] mixinNames) method
 --

 Key: JCR-2788
 URL: https://issues.apache.org/jira/browse/JCR-2788
 Project: Jackrabbit Content Repository
  Issue Type: New Feature
  Components: jackrabbit-api, jackrabbit-core
Reporter: Stefan Guggisberg
 Fix For: 2.2.0


 assume the following scenario:
 - mixin A declares the mandatory property p
 - mixin A' extends from A
 - node n has mixin A'
 - we'd like to migrate/downgrade node n from mixin A' to A
 currently there's no easy way of replacing the assigned mixins.
 assigning A first results in a NOP since A would be redundant.
 removing A' first removes the mandatory property p.
 a new method setMixins(String[]) would allow to migrate
 a node from mixin A' to A while preserving 'shared' content.
 the semantics of setMixins(String[]) would be similar to
 Node.setPrimaryType(String).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (JCR-2772) replacing an extended mixin with it's supertype is problematic

[Stefan Guggisberg (JIRA)]

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

Stefan Guggisberg resolved JCR-2772.


   Resolution: Fixed
Fix Version/s: 2.2.0

resolved as duplicate of JCR-2788

 replacing an extended mixin with it's supertype is problematic
 --

 Key: JCR-2772
 URL: https://issues.apache.org/jira/browse/JCR-2772
 Project: Jackrabbit Content Repository
  Issue Type: Improvement
  Components: jackrabbit-core
Affects Versions: 2.0.0
Reporter: Tobias Bocanegra
 Fix For: 2.2.0


 node.addMixin() / node.removeMixin() have some checks to avoid redundant 
 mixin settings on a node and not only when the node is saved.
 eg: have 2 mixins: mix:A and mix:AA where mix:AA  mix:A and a node (N with 
 mix:AA) on it.
 then, N.addMixin(mix:A)  has no effect, since it's regarded as redundant.  so 
 you have to remove mix:AA first and then add mix:A.
 there is the first problem when applying mixin types programmatically, just 
 be sure to remove them first before adding new ones.
 the 2nd problem occurs when mix:A has a mandatory property. then somehow when 
 downgrading from mix:AA to mix:A, some information is lost, and a save call 
 results in
 Unable to save node 'N': javax.jcr.nodetype.ConstraintViolationException: 
 /test/A: mandatory property {}prop does not exist.
 you need to touch the property, otherwise it will not work.
 so only this works:
 N.removeMixin(mix:AA);
 N.addMixin(mix:A);
 N.setProperty(prop, N.getProperty(prop).getValue());
 session.save();

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (JCR-2011) Replacing mixin type doesn't preserve properties

[Stefan Guggisberg (JIRA)]

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

Stefan Guggisberg resolved JCR-2011.


   Resolution: Fixed
Fix Version/s: 2.2.0

resolved as duplicate of JCR-2788

 Replacing mixin type doesn't preserve properties
 

 Key: JCR-2011
 URL: https://issues.apache.org/jira/browse/JCR-2011
 Project: Jackrabbit Content Repository
  Issue Type: Improvement
  Components: jackrabbit-core
Reporter: Charles Brooking
Priority: Minor
 Fix For: 2.2.0


 NodeImpl.setPrimaryType(String) attempts to redefine nodes and properties 
 that were defined by the previous node type if they also appear in the new 
 type. If there is no matching definition for a node/property in the new type 
 - or value conversion for matched node/property fails - only then are 
 children removed. For example, say I have a node harry, with a primary type 
 Human that defines a bloodgroup property. If I set the primary type to be 
 an unrelated type Animal that has a similar bloodgroup property, then its 
 property value will survive the call to setPrimaryType(Animal).
 The same is apparently not possible with mixins. NodeImpl.removeMixin(Name) 
 immediately removes all children that were defined by the mixin (strictly, 
 those that are not present in the effective node type resulting from the 
 mixin being removed). In addition, NodeImpl.addMixin(Name) immediately throws 
 a NodeTypeConflictException if you attempt to add a mixin defining an 
 identically-named property prior to calling removeMixin. For example, say I 
 have a node matrix, with a mixin type movie that defines a title 
 property. If I wish to replace the movie mixin on that node with another 
 jcr:title mixin type, the existing title property will be deleted.
 This occurs regardless of the order in which removeMixin and addMixin are 
 called, and without session.save() being called between them. One option for 
 coding this is to defer validation (and possible node/property removal) until 
 session.save() is called.
 This is not strictly a bug, as JSR-283 seems to leave the details of 
 assigning node types (section 5.5) unspecified. However, it does say for 
 Node.removeMixin(String) that Both the semantic change in effective node 
 type and the persistence of the
 change to the jcr:mixinTypes property occur on save and ideally we could 
 emulate the nice behaviour in NodeImpl.setPrimaryType(String) for mixin types.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (JCR-2780) Best effort merge if concurrent modifications include changes to mixin types

[Stefan Guggisberg (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-2780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12923480#action_12923480
 ] 

Stefan Guggisberg commented on JCR-2780:


+1 for the patch, thanks!

 Best effort merge if concurrent modifications include changes to mixin types
 

 Key: JCR-2780
 URL: https://issues.apache.org/jira/browse/JCR-2780
 Project: Jackrabbit Content Repository
  Issue Type: Improvement
  Components: jackrabbit-core
Reporter: angela
Assignee: angela
 Fix For: 2.2.0

 Attachments: JCR-2780.patch


 currently the NodeStateMerger#merge method immediately aborts if the mixin 
 types of the 2 nodes are not the same.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (JCR-2788) Provide a JackrabbitNode#setMixins(String[] mixinNames) method

[Stefan Guggisberg (JIRA)]

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

Stefan Guggisberg updated JCR-2788:
---

Component/s: jackrabbit-api

 Provide a JackrabbitNode#setMixins(String[] mixinNames) method
 --

 Key: JCR-2788
 URL: https://issues.apache.org/jira/browse/JCR-2788
 Project: Jackrabbit Content Repository
  Issue Type: New Feature
  Components: jackrabbit-api, jackrabbit-core
Reporter: Stefan Guggisberg
 Fix For: 2.2.0


 assume the following scenario:
 - mixin A declares the mandatory property p
 - mixin A' extends from A
 - node n has mixin A'
 - we'd like to migrate/downgrade node n from mixin A' to A
 currently there's no easy way of replacing the assigned mixins.
 assigning A first results in a NOP since A would be redundant.
 removing A' first removes the mandatory property p.
 a new method setMixins(String[]) would allow to migrate
 a node from mixin A' to A while preserving 'shared' content.
 the semantics of setMixins(String[]) would be similar to
 Node.setPrimaryType(String).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (JCR-2788) Provide a JackrabbitNode#setMixins(String[] mixinNames) method

[Stefan Guggisberg (JIRA)]

Provide a JackrabbitNode#setMixins(String[] mixinNames) method
--

 Key: JCR-2788
 URL: https://issues.apache.org/jira/browse/JCR-2788
 Project: Jackrabbit Content Repository
  Issue Type: New Feature
  Components: jackrabbit-core
Reporter: Stefan Guggisberg
 Fix For: 2.2.0


assume the following scenario:

- mixin A declares the mandatory property p
- mixin A' extends from A
- node n has mixin A'
- we'd like to migrate/downgrade node n from mixin A' to A

currently there's no easy way of replacing the assigned mixins.

assigning A first results in a NOP since A would be redundant.
removing A' first removes the mandatory property p.

a new method setMixins(String[]) would allow to migrate
a node from mixin A' to A while preserving 'shared' content.
the semantics of setMixins(String[]) would be similar to
Node.setPrimaryType(String).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (JCR-2789) toString() causes StackOverflowError

[Stefan Guggisberg (JIRA)]

toString() causes StackOverflowError


 Key: JCR-2789
 URL: https://issues.apache.org/jira/browse/JCR-2789
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-core
Reporter: Stefan Guggisberg
 Fix For: 2.2.0


further regressions of JCR-27893...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (JCR-2789) toString() causes StackOverflowError

[Stefan Guggisberg (JIRA)]

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

Stefan Guggisberg resolved JCR-2789.


Resolution: Fixed

fixed in svn r1023820

 toString() causes StackOverflowError
 

 Key: JCR-2789
 URL: https://issues.apache.org/jira/browse/JCR-2789
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-core
Reporter: Stefan Guggisberg
 Fix For: 2.2.0


 further regressions of JCR-27893...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (JCR-2789) toString() causes StackOverflowError

[Stefan Guggisberg (JIRA)]

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

Stefan Guggisberg updated JCR-2789:
---

Description: further regressions of JCR-2763...  (was: further regressions 
of JCR-27893...)

 toString() causes StackOverflowError
 

 Key: JCR-2789
 URL: https://issues.apache.org/jira/browse/JCR-2789
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-core
Reporter: Stefan Guggisberg
 Fix For: 2.2.0


 further regressions of JCR-2763...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (JCR-2783) ItemStateManager.toString() causes StackOverflowError

[Stefan Guggisberg (JIRA)]

ItemStateManager.toString() causes StackOverflowError
-

 Key: JCR-2783
 URL: https://issues.apache.org/jira/browse/JCR-2783
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-core
Reporter: Stefan Guggisberg
 Fix For: 2.2.0




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (JCR-2783) ItemManager.toString() causes StackOverflowError

[Stefan Guggisberg (JIRA)]

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

Stefan Guggisberg updated JCR-2783:
---

Summary: ItemManager.toString() causes StackOverflowError  (was: 
ItemStateManager.toString() causes StackOverflowError)

 ItemManager.toString() causes StackOverflowError
 

 Key: JCR-2783
 URL: https://issues.apache.org/jira/browse/JCR-2783
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-core
Reporter: Stefan Guggisberg
 Fix For: 2.2.0




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (JCR-2783) ItemManager.toString() causes StackOverflowError

[Stefan Guggisberg (JIRA)]

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

Stefan Guggisberg resolved JCR-2783.


Resolution: Fixed

fixed in svn r1022410

 ItemManager.toString() causes StackOverflowError
 

 Key: JCR-2783
 URL: https://issues.apache.org/jira/browse/JCR-2783
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-core
Reporter: Stefan Guggisberg
 Fix For: 2.2.0




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (JCR-2785) EffectiveNodeType#getNamedNodeDefs returns array QItemDefinition instead of QNodeDefinition

[Stefan Guggisberg (JIRA)]

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

Stefan Guggisberg resolved JCR-2785.


   Resolution: Fixed
Fix Version/s: 2.2.0

fixed in svn r1042494

 EffectiveNodeType#getNamedNodeDefs returns array QItemDefinition instead of 
 QNodeDefinition
 ---

 Key: JCR-2785
 URL: https://issues.apache.org/jira/browse/JCR-2785
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-core
Reporter: angela
 Fix For: 2.2.0


 ... thus requires unnecessary casting...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (JCR-2762) Optimize bundle serialization

[Stefan Guggisberg (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-2762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12920468#action_12920468
 ] 

Stefan Guggisberg commented on JCR-2762:


 The question therefore is, should we do this now for Jackrabbit 2.2 or 
 postpone this for 2.3? I

+1 for  2.2


 Optimize bundle serialization
 -

 Key: JCR-2762
 URL: https://issues.apache.org/jira/browse/JCR-2762
 Project: Jackrabbit Content Repository
  Issue Type: Improvement
  Components: jackrabbit-core
Reporter: Jukka Zitting
Priority: Minor
 Attachments: 0001-JCR-2762-Optimize-bundle-serialization.patch, 
 0002-JCR-2762-Optimize-bundle-serialization.patch, 
 0003-JCR-2762-Optimize-bundle-serialization.patch, 
 0004-JCR-2762-Optimize-bundle-serialization.patch


 There are a number of ways we could use to make bundle serialization more 
 optimized. Thomas has already done some work on this in the Jackrabbit 3 
 sandbox, and I'd like to apply some of the optimizations also to the trunk.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (JCR-2778) Node.removeMixin fails if the mixin defines a protected child node

[Stefan Guggisberg (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12920493#action_12920493
 ] 

Stefan Guggisberg commented on JCR-2778:


FWIW: this issue is a regression of JCR-890, i.e. the refactoring involved 
(r982520).
there might be more hidden issues like this.

 Node.removeMixin fails if the mixin defines a protected child node
 --

 Key: JCR-2778
 URL: https://issues.apache.org/jira/browse/JCR-2778
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-core
Reporter: angela
Assignee: angela
 Fix For: 2.2.0


 Node.removeMixin fails if the mixin to removed defines a protected child 
 node the problem is caused by line 253 of RemoveMixinOperation.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (JCR-2779) A jcr:uuid property added manually isn't attached to the parent node

[Stefan Guggisberg (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12920624#action_12920624
 ] 

Stefan Guggisberg commented on JCR-2779:


this issue is caused by the implementation of
AbstractBundlePersistanceManager.load(PropertyId id);

this method always returns 'jcr:uuid' PropertyState instances, whether
such a property is declared on the node or not.

this may lead to inconsistent NodeState/PropertyState 
instances, as demonstrated by this issue. 

before r1001707 (JCR-2699) the problem was not apparent since
the existence was checked in SharedItemStateManager.getItemState()
by calling hasNonVirtualItemState().

 A jcr:uuid property added manually isn't attached to the parent node
 

 Key: JCR-2779
 URL: https://issues.apache.org/jira/browse/JCR-2779
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-core
Reporter: angela
 Fix For: 2.2.0


 - take a nt:unstructured node without any mixins.
 - set a property with name jcr:uuid
 - the parent obtained from that property is the same as the test node 
 (expected)
 - the declaring node type of that property is nt:unstructured as expected
 but:
 - the property isn't new (instead it is modified) 
 - there is no property-name entry for it in the parent node.
 if it was illegal to add a jcr:uuid property that is not defined by 
 mix:referenceable i would expect
 that the setProperty-call fails.
 the following test illustrates the behaviour:
 public void testAddJcrUUIDProperty() throws RepositoryException {
 Node testNode = testRootNode.addNode(nodeName2, nt:unstructured);
 superuser.save();
 assertFalse(testNode.hasProperty(jcr:mixinTypes));
 assertFalse(testNode.isNodeType(mixReferenceable));
 Property p = testNode.setProperty(jcr:uuid, 
 superuser.getValueFactory().createValue(false));
 assertTrue(testNode.isSame(p.getParent()));
 assertEquals(nt:unstructured, 
 p.getDefinition().getDeclaringNodeType().getName());
 assertTrue(p.isNew());
 assertTrue(testNode.hasProperty(jcr:uuid));
 }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (JCR-2772) replacing an extended mixin with it's supertype is problematic

[Stefan Guggisberg (JIRA)]

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

Stefan Guggisberg updated JCR-2772:
---

Issue Type: Improvement  (was: Bug)

not a bug since the current behavior is according to the spec.

 replacing an extended mixin with it's supertype is problematic
 --

 Key: JCR-2772
 URL: https://issues.apache.org/jira/browse/JCR-2772
 Project: Jackrabbit Content Repository
  Issue Type: Improvement
  Components: jackrabbit-core
Affects Versions: 2.0.0
Reporter: Tobias Bocanegra

 node.addMixin() / node.removeMixin() have some checks to avoid redundant 
 mixin settings on a node and not only when the node is saved.
 eg: have 2 mixins: mix:A and mix:AA where mix:AA  mix:A and a node (N with 
 mix:AA) on it.
 then, N.addMixin(mix:A)  has no effect, since it's regarded as redundant.  so 
 you have to remove mix:AA first and then add mix:A.
 there is the first problem when applying mixin types programmatically, just 
 be sure to remove them first before adding new ones.
 the 2nd problem occurs when mix:A has a mandatory property. then somehow when 
 downgrading from mix:AA to mix:A, some information is lost, and a save call 
 results in
 Unable to save node 'N': javax.jcr.nodetype.ConstraintViolationException: 
 /test/A: mandatory property {}prop does not exist.
 you need to touch the property, otherwise it will not work.
 so only this works:
 N.removeMixin(mix:AA);
 N.addMixin(mix:A);
 N.setProperty(prop, N.getProperty(prop).getValue());
 session.save();

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (JCR-1867) Missing conflict when adding a mixin, whose protected items have been manually added before

[Stefan Guggisberg (JIRA)]

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

Stefan Guggisberg resolved JCR-1867.


   Resolution: Fixed
Fix Version/s: 1.6.2
   2.0-alpha1

non-reproducible on 2.2 trunk, most likely fixed through resolution of JCR-2170.

 Missing conflict when adding a mixin, whose protected items have been 
 manually added before
 ---

 Key: JCR-1867
 URL: https://issues.apache.org/jira/browse/JCR-1867
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-core
Reporter: angela
 Fix For: 2.0-alpha1, 1.6.2


 with a unstructured node it is possible to manually create protected items of 
 the jcr namespace such
 as e.g. jcr:uuid. while this obviously isn't recommended, but it currently 
 works fine... 
 however i would expect that subsequently adding a mixin-type that defines 
 those items (in the example mix:referenceable) would either
 - fail with constraintviolationexception or
 - at least redefine the items according to the mixin definition.
 test case for illustration of the problem that no only applies to jcr:uuid 
 but to any protected item defined by a built-in or custom node type.
 public void testConflictingJcrUUID() throws RepositoryException {
 // adding a custom jcr:uuid property is definitely not recommended
 // but it currently works...
 Node n = testRootNode.addNode(nodeName1, 
 JcrConstants.NT_UNSTRUCTURED);
 n.setProperty(JcrConstants.JCR_UUID, true);
 testRootNode.save();
 assertTrue(n.hasProperty(JcrConstants.JCR_UUID));
 assertFalse(n.isNodeType(JcrConstants.MIX_REFERENCEABLE));
 Property p = n.getProperty(JcrConstants.JCR_UUID);
 assertEquals(PropertyType.BOOLEAN, p.getType());
 NodeType nt = p.getDefinition().getDeclaringNodeType();
 assertEquals(JcrConstants.NT_UNSTRUCTURED, nt.getName());
 // ... test effect of adding mix:referenceable now
 n.addMixin(JcrConstants.MIX_REFERENCEABLE);
 n.save();
 assertTrue(n.isNodeType(JcrConstants.MIX_REFERENCEABLE));
 assertEquals(PropertyType.STRING, p.getType());   == false. 
 type is still 
 UUID.fromString(p.getString());   
   == fails. value is still 'true'
 nt = p.getDefinition().getDeclaringNodeType();   
 assertEquals(mix:referenceable, nt.getName());   == false. 
 declaring nt is still nt:unstructured
 }
 in order to avoid unexpected (and maybe hard to analyze) behavior, i would 
 prefer if 
 adding the mixin (or saving the changes) would fail in the first place 
 indicating to the API
 user that existing content conflicts with the mixin to be added.
 btw:
 i didn't test Node#setPrimaryType(String) but after all i would expected a 
 corresponding validation.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (JCR-2772) replacing an extended mixin with it's supertype is problematic

[Stefan Guggisberg (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-2772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12919878#action_12919878
 ] 

Stefan Guggisberg commented on JCR-2772:


  checks to avoid redundant mixin 

 is this mandated by the specification?

yes, see [1].

quote
If this node is already of type mixinName (either due to a previously added 
mixin or due to its primary type, through inheritance) then this method has no 
effect. Otherwise mixinName is added to this node's jcr:mixinTypes property.
/quote

there's also a TCK test which expects the current behavior (adding a redundant 
mixin results in a nop).

[1] 
http://www.day.com/maven/jsr170/javadocs/jcr-2.0/javax/jcr/Node.html#addMixin(java.lang.String)

 replacing an extended mixin with it's supertype is problematic
 --

 Key: JCR-2772
 URL: https://issues.apache.org/jira/browse/JCR-2772
 Project: Jackrabbit Content Repository
  Issue Type: Improvement
  Components: jackrabbit-core
Affects Versions: 2.0.0
Reporter: Tobias Bocanegra

 node.addMixin() / node.removeMixin() have some checks to avoid redundant 
 mixin settings on a node and not only when the node is saved.
 eg: have 2 mixins: mix:A and mix:AA where mix:AA  mix:A and a node (N with 
 mix:AA) on it.
 then, N.addMixin(mix:A)  has no effect, since it's regarded as redundant.  so 
 you have to remove mix:AA first and then add mix:A.
 there is the first problem when applying mixin types programmatically, just 
 be sure to remove them first before adding new ones.
 the 2nd problem occurs when mix:A has a mandatory property. then somehow when 
 downgrading from mix:AA to mix:A, some information is lost, and a save call 
 results in
 Unable to save node 'N': javax.jcr.nodetype.ConstraintViolationException: 
 /test/A: mandatory property {}prop does not exist.
 you need to touch the property, otherwise it will not work.
 so only this works:
 N.removeMixin(mix:AA);
 N.addMixin(mix:A);
 N.setProperty(prop, N.getProperty(prop).getValue());
 session.save();

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (JCR-2763) Drop the Dumpable interface

[Stefan Guggisberg (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-2763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12918482#action_12918482
 ] 

Stefan Guggisberg commented on JCR-2763:


what about SessionImpl.dump()? it used to dump the internal session state, e.g. 
transient items etc.
it proofed to be quite useful while debugging, at least for me.

btw: i fail to see any benefit in removing this interface.  what was your 
motivation?

 Drop the Dumpable interface
 ---

 Key: JCR-2763
 URL: https://issues.apache.org/jira/browse/JCR-2763
 Project: Jackrabbit Content Repository
  Issue Type: Improvement
  Components: jackrabbit-core, jackrabbit-spi2jcr
Reporter: Jukka Zitting
Priority: Trivial

 I belive the o.a.j.core.util.Dumpable interface was originally used for 
 diagnostic purposes, but AFAIUI we don't use it anywhere anymore. I'd like to 
 drop the interface and refactor the dump() methods in various Jackrabbit 
 classes to more detailed toString() methods that would be more useful to 
 debuggers and other general-purpose diagnostic tools.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (JCR-2763) Drop the Dumpable interface

[Stefan Guggisberg (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-2763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12918516#action_12918516
 ] 

Stefan Guggisberg commented on JCR-2763:


 In revision 1005019 I restored the essential functionality of 
 SessionImpl.dump() in the SessionContext.toString() method.

thanks!

 Drop the Dumpable interface
 ---

 Key: JCR-2763
 URL: https://issues.apache.org/jira/browse/JCR-2763
 Project: Jackrabbit Content Repository
  Issue Type: Improvement
  Components: jackrabbit-core, jackrabbit-spi2jcr
Reporter: Jukka Zitting
Priority: Trivial

 I belive the o.a.j.core.util.Dumpable interface was originally used for 
 diagnostic purposes, but AFAIUI we don't use it anywhere anymore. I'd like to 
 drop the interface and refactor the dump() methods in various Jackrabbit 
 classes to more detailed toString() methods that would be more useful to 
 debuggers and other general-purpose diagnostic tools.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.