date:20080116


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

Tobias Bocanegra commented on JCR-1314:
---

i think the spec is wrong:

in 8.2.10 it says:

If N is currently checked-in then: 
  1) If V' is a successor (to any degree) of V, then the merge result for N is 
update. 
  2) If V' is a predecessor (to any degree) of V or if V and V' are identical 
(i.e., are actually the same version), 
   then the merge result for N is leave. 
  3) If V is neither a successor of, predecessor of, nor identical with V', 
then the merge result for N is failed. 

If N is currently checked-out then: 
  4) If V' is a predecessor (to any degree) of V or if V and V' are identical 
(i.e., are actually the same version), 
   then the merge result for N is leave. 

1) means, if the version you merge against is newer, do an update
2,4) mean, if the version you merge against is older or same, leave it

where as in 8.2.10.1:
 a) if v' is a successor of v and n is not checked-in doupdate(n, n'). 
 b) else if v is equal to or a predecessor of v' doleave(n). 

a) means, if the version you merge against is newer and checked-out, do update. 
which is the same as 1)
b) means, if the version you merge against is newer or same, do leave. which is 
not the same as 2,4)

so i think the code is correct. which also makes sense, since you don't want to 
update to an older version.

are you sure you did the merge the right way around ? can you provide a test 
class ?

 Node incorrectly overridden when performing a merge
 ---

 Key: JCR-1314
 URL: https://issues.apache.org/jira/browse/JCR-1314
 Project: Jackrabbit
  Issue Type: Bug
  Components: versioning
Affects Versions: 1.4, 1.5
Reporter: Bob Wieler
Priority: Critical

 The implementation of the merge algorithm provided in the JCR specification 
 is incorrect and can result in nodes being overridden. This can be 
 demonstrated by the following simple steps:
 1. Create a repository with a nt:file node containing whatever data (n')
 2. Commit the changes to the node to create the initial version (v')
 3. Copy the node to a new workspace
 4. Edit the node in the second workspace (n)
 5. Commit the changes to the second workspace to create the second version (v)
 6. Merge the changes from the first workspace into the second workspace
 According to the JCR specification (from 8.2.10.1):
 if v' is a successor of v and n is not checked-in doupdate(n, n'). 
 else if v is equal to or a predecessor of v' doleave(n). 
 else dofail(n, v').
 In the above example, v' is a predecessor of v so the doupdate(n, n') is not 
 done. v and v' are also not equal and v is not a predecessor of v' so the 
 doleaven(n) is not done. Therefore the dofail(n, v') is what should be called.
 The code in NodeImpl.java is not however doing what is expected. Line 3337 in 
 NodeImpl.java (subversion revision 611855) has the following:
 } else if (v.isSame(vp) || v.isMoreRecent(vp)) {
 // If V' is a predecessor (to any degree) of V or if V and V' are
 // identical (i.e., are actually the same version), then the merge
 // result for N is leave. This case can be thought of as the case 
 where
 // N' is older or the same age as N and therefore N should be 
 left alone.
 return null;
 } else {
 The doMergeTest method returns null (essentially a doleave(n) in the spec 
 algorithm) if v and v' are the same or v' is a predecessor to v - in other 
 words if v and v' are the same or v is a _successor_ to v' - which is exactly 
 the opposite to what the specification  requires (if v is equal to or a 
 _predecessor_ of v'). The proper if statement would be to have:
 } else if (v.isSame(vp) || vp.isMoreRecent(v)) {
 Unfortunately, this was causing us to lose data when performing a merge. I 
 have updated our version of jackrabbit with the above change and merging now 
 works as expected.

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

[jira] Issue Comment Edited: (JCR-1312) Get rid of DOM for XML support

2008-01-16 Thread Felix Meschberger (JIRA)

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

fmeschbe edited comment on JCR-1312 at 1/16/08 7:41 AM:
-

Performance: kXml is about twice as fast as Xerces for both parsing to DOM and
serializing from DOM.

Memory Footprint:
xercesimpl 2.8.1 Impl: 1.2MB
kxml 2.2.2: 10KB

To be honest: using kxml instead of xerces requires the additional classes I
added in the second patch to JCR-1261 [1]. But these are small, and one has
even been copied ...

To me theses figures are quite impressive.

[1] https://issues.apache.org/jira/secure/attachment/12371412/JCR-1261_2.patch

was (Author: fmeschbe):
Performance: kXml is about twice as fast as Xerces for both parsing and
serializing

Memory Footprint:
xercesimpl 2.8.1 Impl: 1.2MB
kxml 2.2.2: 10KB

To be honest: using kxml instead of xerces requires the additional classes I
added in the second patch to JCR-1261 [1]. But these are small, and one has
even been copied ...

To me theses figures are quite impressive.

[1] https://issues.apache.org/jira/secure/attachment/12371412/JCR-1261_2.patch

Get rid of DOM for XML support
--

Key: JCR-1312
URL: https://issues.apache.org/jira/browse/JCR-1312
Project: Jackrabbit
Issue Type: Improvement
Components: jackrabbit-webdav
Reporter: Felix Meschberger

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

Re: [jira] Commented: (JCR-1312) Get rid of DOM for XML support

2008-01-16 Thread Thomas Mueller

Hi,

My experience is that all XML parser are a little bit different. I
don't know about you, but I did run into quite many problems because
of XML parser incompatibilities. If we always use the same parser we
would be sure we always get the same result on all systems. I believe
that would be a big advantage, what do you think?

Regards,
Thomas

[jira] Commented: (JCR-872) Cache framework integration


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

Padraic Hannon commented on JCR-872:


I'm working on ehcache now. 

I probably was confusing in my statement re. hibernate. I was looking at the 
hibernate Cache/CacheProvider pattern as starting point for how we might want 
to create a pluggable infrastructure. I *do not* want to rely on their 
infrastructure. However, since there stuff is easily configurable I thought it 
would be good to look at what they did as an example.

 Cache framework integration
 ---

 Key: JCR-872
 URL: https://issues.apache.org/jira/browse/JCR-872
 Project: Jackrabbit
  Issue Type: Task
  Components: jackrabbit-ocm
Reporter: Christophe Lombart
 Attachments: observableCache.patch


 OCM should work with a cache manager. 
 * The Spring frameworks offer a nice solution to integrate an application 
 with a cache manager (based on AOP). 
 * Which cache framework to use ? oscache, JCS, ...
 * A more detailled proposal is required

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

[OCM] ObjectContentManager and Sessions

2008-01-16 Thread Padraic Hannon

While working with the caches and with our own internal content  
mapping project I have noticed a slight disconnect between how OCM  
handles sessions and how jackrabbit seems to want to handle them. With  
the OCM one tends to have a long lived object content manager that is  
potentially used by multiple threads. This would mean that the session  
would be re-used across multiple reader and writer threads. See http://markmail.org/message/f5lbenhnmdc2vxhx 
 for details on threading and sessions.


I think this points to the need to have sessions opened and closed  
much like in the hibernate model. To accomplish this I think we should  
create a ObjectContentManagerFactory which can create the managers so  
that each thread can get its own copy. When creating a manager the  
factory could use a session factory much like the one that spring has  
for JCR (org.springmodules.jcr.JcrSessionFactory). This would allow  
sessions to be pooled or created as needed and then be passed to  
ObjectContentManagers. The factory could also preload the mapping  
classes and other configuration items (like say the cache  
implementation factory?). The threads could share a cache (if the  
implementation is EhCache or something intelligent) or the cache could  
just be a simple hashmap and the assumption would be that the managers  
are short lived and the cache is there to eliminate the infinite load  
issue.


WDYT?

-paddy

[jira] Created: (JCR-1318) Repository Home locked not released despite RepositoryException being thrown.

2008-01-16 Thread Micah Whitacre (JIRA)

Repository Home locked not released despite RepositoryException being thrown.
-

 Key: JCR-1318
 URL: https://issues.apache.org/jira/browse/JCR-1318
 Project: Jackrabbit
  Issue Type: Bug
  Components: jackrabbit-core
Affects Versions: 1.3.3
 Environment: windows vista  jdk 5
Reporter: Micah Whitacre


When an exception is thrown when calling RepositoryImpl.create(...) a .lock 
file is created in the repository home directory and not removed despite there 
no longer being an active connection.  If the user attempts to create the 
repository again (e.g recover from the exception because the url of the 
repository was temporarily unavailable) a RepositoryException is thrown again 
indicating that the repository home is locked by another process because there 
is a .lock file.  If a Repository is not successfully created then the 
repository home should not be locked.

The lock is only released when the repository is shutdown but in this case the 
Repository object is never created successfully for that method to be called.



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

Re: [OCM] ObjectContentManager and Sessions

2008-01-16 Thread Christophe Lombart

+1


On Jan 16, 2008 6:47 PM, Padraic Hannon [EMAIL PROTECTED] wrote:

 The factory could also preload the mapping
 classes and other configuration items (like say the cache
 implementation factory?).


If I understand, there is 3 factories :
one for the ObjectcontentManager
one for the JCR session
one for the Cache impl

It is correct ?


Christophe

[jira] Commented: (JCR-872) Cache framework integration


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

Padraic Hannon commented on JCR-872:


Please disregard the patch I created. I messed up due to not taking the time to 
understand what was going on. I am working on revising it now.

 Cache framework integration
 ---

 Key: JCR-872
 URL: https://issues.apache.org/jira/browse/JCR-872
 Project: Jackrabbit
  Issue Type: Task
  Components: jackrabbit-ocm
Reporter: Christophe Lombart
 Attachments: observableCache.patch


 OCM should work with a cache manager. 
 * The Spring frameworks offer a nice solution to integrate an application 
 with a cache manager (based on AOP). 
 * Which cache framework to use ? oscache, JCS, ...
 * A more detailled proposal is required

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

[jira] Updated: (JCR-872) Cache framework integration


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

Padraic Hannon updated JCR-872:
---

Attachment: (was: observableCache.patch)

 Cache framework integration
 ---

 Key: JCR-872
 URL: https://issues.apache.org/jira/browse/JCR-872
 Project: Jackrabbit
  Issue Type: Task
  Components: jackrabbit-ocm
Reporter: Christophe Lombart

 OCM should work with a cache manager. 
 * The Spring frameworks offer a nice solution to integrate an application 
 with a cache manager (based on AOP). 
 * Which cache framework to use ? oscache, JCS, ...
 * A more detailled proposal is required

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

[jira] Issue Comment Edited: (JCR-872) Cache framework integration


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

hannonpi edited comment on JCR-872 at 1/16/08 1:12 PM:
-

Please disregard the patch I created. I messed up due to not taking the time to 
understand what was going on. I am going to remove the patch. I thought I was 
working on a second level cache. The RequestObjectCache is a first level cache 
which as Christophe pointed out and I didn't follow  is basically used only to 
prevent infinite recursion.

  was (Author: hannonpi):
Please disregard the patch I created. I messed up due to not taking the 
time to understand what was going on. I am working on revising it now.
  
 Cache framework integration
 ---

 Key: JCR-872
 URL: https://issues.apache.org/jira/browse/JCR-872
 Project: Jackrabbit
  Issue Type: Task
  Components: jackrabbit-ocm
Reporter: Christophe Lombart

 OCM should work with a cache manager. 
 * The Spring frameworks offer a nice solution to integrate an application 
 with a cache manager (based on AOP). 
 * Which cache framework to use ? oscache, JCS, ...
 * A more detailled proposal is required

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

[jira] Resolved: (JCR-1314) Node incorrectly overridden when performing a merge


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

Bob Wieler resolved JCR-1314.
-

Resolution: Invalid

You're right. This is an bug/inconsistency with the the specification. The 
problem is actually  with the fix to JCR-1046 that I supplied with that issue.

The problem is that on a leave(n), all of children of n are being updated which 
is not valid. Only the versionable children of n should be updated. The 
solution that I proposed for JCR-1046 updates only the versionable children 
only if the merge result is a failure, not if the merge result is leave.

The data in our repository is stored as versionable nt:folder and versionable 
nt:file nodes with non-versionable nt:resource nodes. The merge result for the 
versionable nt:file node would be leave, however it would then go about merging 
all of the non-versionable children of that node, specifically the nt:resource 
node. As a result, our data, stored primarily in the nt:resource node, would be 
overridden.

One solution would be to change the fix for JCR-1046 to only merge 
non-versionable children if the merge result is leave or fail. I'm not sure if 
this is the correct solution to these issues as it becomes very difficult to 
deal with versioned and non-versioned nodes mixed together.

I'm marking this issue as invalid and I'll update JCR-1046 with this 
information.

 Node incorrectly overridden when performing a merge
 ---

 Key: JCR-1314
 URL: https://issues.apache.org/jira/browse/JCR-1314
 Project: Jackrabbit
  Issue Type: Bug
  Components: versioning
Affects Versions: 1.4, 1.5
Reporter: Bob Wieler
Priority: Critical

 The implementation of the merge algorithm provided in the JCR specification 
 is incorrect and can result in nodes being overridden. This can be 
 demonstrated by the following simple steps:
 1. Create a repository with a nt:file node containing whatever data (n')
 2. Commit the changes to the node to create the initial version (v')
 3. Copy the node to a new workspace
 4. Edit the node in the second workspace (n)
 5. Commit the changes to the second workspace to create the second version (v)
 6. Merge the changes from the first workspace into the second workspace
 According to the JCR specification (from 8.2.10.1):
 if v' is a successor of v and n is not checked-in doupdate(n, n'). 
 else if v is equal to or a predecessor of v' doleave(n). 
 else dofail(n, v').
 In the above example, v' is a predecessor of v so the doupdate(n, n') is not 
 done. v and v' are also not equal and v is not a predecessor of v' so the 
 doleaven(n) is not done. Therefore the dofail(n, v') is what should be called.
 The code in NodeImpl.java is not however doing what is expected. Line 3337 in 
 NodeImpl.java (subversion revision 611855) has the following:
 } else if (v.isSame(vp) || v.isMoreRecent(vp)) {
 // If V' is a predecessor (to any degree) of V or if V and V' are
 // identical (i.e., are actually the same version), then the merge
 // result for N is leave. This case can be thought of as the case 
 where
 // N' is older or the same age as N and therefore N should be 
 left alone.
 return null;
 } else {
 The doMergeTest method returns null (essentially a doleave(n) in the spec 
 algorithm) if v and v' are the same or v' is a predecessor to v - in other 
 words if v and v' are the same or v is a _successor_ to v' - which is exactly 
 the opposite to what the specification  requires (if v is equal to or a 
 _predecessor_ of v'). The proper if statement would be to have:
 } else if (v.isSame(vp) || vp.isMoreRecent(v)) {
 Unfortunately, this was causing us to lose data when performing a merge. I 
 have updated our version of jackrabbit with the above change and merging now 
 works as expected.

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

[jira] Updated: (JCR-1046) Non-versionable children of a versionable node should not be updated when a merge fails


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

Bob Wieler updated JCR-1046:


Attachment: (was: jcr1046.diff)

 Non-versionable children of a versionable node should not be updated when a 
 merge fails
 ---

 Key: JCR-1046
 URL: https://issues.apache.org/jira/browse/JCR-1046
 Project: Jackrabbit
  Issue Type: Bug
  Components: versioning
Affects Versions: 1.3
Reporter: Bob Wieler
 Attachments: jcr1046.diff


 The JCR specification (JSR-170) includes a merge algorithm that is 
 inconsistent with the functionality described elsewhere in the JCR 
 specification. Specifically from JSR-170 section 8.2.10 Merge:
 In either case, (regardless of whether bestEffort is true or false) for each 
 non-versionable node (including both referenceable and non-referenceable), if 
 the merge result of its nearest versionable ancestor is update, or if it has 
 no versionable ancestor, then it is updated to reflect the state of its 
 corresponding node. Otherwise, it is left unchanged.
 The algorithm presented in 8.2.10.1 of the specification goes against the 
 above statement as it does not take into consideration the merge result of 
 the nearest versionable ancestor.
 One solution would be to have the doLeave(n) call that dofail(n, v') calls 
 altered to only perform a merge on the versionable children rather than all 
 of the children. The merging of all children (versionable and 
 non-versionable) should only be done if the nearest parent is not in a failed 
 merge state regardless of whether the failure occurred from the current merge 
 operation or a previous merge operation.
 I will attach a patch file that makes what I think is the required change.

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

[jira] Commented: (JCR-1046) Non-versionable children of a versionable node should not be updated when a merge fails

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

Bob Wieler commented on JCR-1046:
-

The fix I supplied for this should actually only merge non-versionable children
if the result of the merge is a fail or a leave, not just if it is a failure.
Otherwise, non-versionable children will always be merged regardless of the
merge status of the nearest versionable parent.

I will update the attached diff with a different proposed fixed. More
information on this issue can be found in JCR-1314.

Non-versionable children of a versionable node should not be updated when a
merge fails
---

Key: JCR-1046
URL: https://issues.apache.org/jira/browse/JCR-1046
Project: Jackrabbit
Issue Type: Bug
Components: versioning
Affects Versions: 1.3
Reporter: Bob Wieler
Attachments: jcr1046.diff

The JCR specification (JSR-170) includes a merge algorithm that is
inconsistent with the functionality described elsewhere in the JCR
specification. Specifically from JSR-170 section 8.2.10 Merge:
In either case, (regardless of whether bestEffort is true or false) for each
non-versionable node (including both referenceable and non-referenceable), if
the merge result of its nearest versionable ancestor is update, or if it has
no versionable ancestor, then it is updated to reflect the state of its
corresponding node. Otherwise, it is left unchanged.
The algorithm presented in 8.2.10.1 of the specification goes against the
above statement as it does not take into consideration the merge result of
the nearest versionable ancestor.
One solution would be to have the doLeave(n) call that dofail(n, v') calls
altered to only perform a merge on the versionable children rather than all
of the children. The merging of all children (versionable and
non-versionable) should only be done if the nearest parent is not in a failed
merge state regardless of whether the failure occurred from the current merge
operation or a previous merge operation.
I will attach a patch file that makes what I think is the required change.

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

[jira] Updated: (JCR-1046) Non-versionable children of a versionable node should not be updated when a merge fails

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

Bob Wieler updated JCR-1046:

Attachment: jcr1046.diff

Updated patch.

Non-versionable children of a versionable node should not be updated when a
merge fails
---

Key: JCR-1046
URL: https://issues.apache.org/jira/browse/JCR-1046
Project: Jackrabbit
Issue Type: Bug
Components: versioning
Affects Versions: 1.3
Reporter: Bob Wieler
Attachments: jcr1046.diff

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

[jira] Commented: (JCR-1046) Non-versionable children of a versionable node should not be updated when a merge fails

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

Tobias Bocanegra commented on JCR-1046:
---

yes, i think your (latest) patch is correct. thanks for finding this!

Non-versionable children of a versionable node should not be updated when a
merge fails
---

Key: JCR-1046
URL: https://issues.apache.org/jira/browse/JCR-1046
Project: Jackrabbit
Issue Type: Bug
Components: versioning
Affects Versions: 1.3
Reporter: Bob Wieler
Assignee: Tobias Bocanegra
Attachments: jcr1046.diff

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

[jira] Assigned: (JCR-1046) Non-versionable children of a versionable node should not be updated when a merge fails


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

Tobias Bocanegra reassigned JCR-1046:
-

Assignee: Tobias Bocanegra

 Non-versionable children of a versionable node should not be updated when a 
 merge fails
 ---

 Key: JCR-1046
 URL: https://issues.apache.org/jira/browse/JCR-1046
 Project: Jackrabbit
  Issue Type: Bug
  Components: versioning
Affects Versions: 1.3
Reporter: Bob Wieler
Assignee: Tobias Bocanegra
 Attachments: jcr1046.diff


 The JCR specification (JSR-170) includes a merge algorithm that is 
 inconsistent with the functionality described elsewhere in the JCR 
 specification. Specifically from JSR-170 section 8.2.10 Merge:
 In either case, (regardless of whether bestEffort is true or false) for each 
 non-versionable node (including both referenceable and non-referenceable), if 
 the merge result of its nearest versionable ancestor is update, or if it has 
 no versionable ancestor, then it is updated to reflect the state of its 
 corresponding node. Otherwise, it is left unchanged.
 The algorithm presented in 8.2.10.1 of the specification goes against the 
 above statement as it does not take into consideration the merge result of 
 the nearest versionable ancestor.
 One solution would be to have the doLeave(n) call that dofail(n, v') calls 
 altered to only perform a merge on the versionable children rather than all 
 of the children. The merging of all children (versionable and 
 non-versionable) should only be done if the nearest parent is not in a failed 
 merge state regardless of whether the failure occurred from the current merge 
 operation or a previous merge operation.
 I will attach a patch file that makes what I think is the required change.

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

[jira] Updated: (JCR-1318) Repository Home locked not released despite RepositoryException being thrown.

2008-01-16 Thread Micah Whitacre (JIRA)

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

Micah Whitacre updated JCR-1318:

Attachment: JCR_1318_tests.zip

Created a testcase which will demonstrate the behavior I'm talking about.
Dropping the testcase and the repository.xml in the root of a java project that
is setup with jackrabbit 1.3.3 as a dependency and JUnit 4.4 is all that should
be needed.

As mentioned the behavior you should be seeing is that the first attempt to
create a RepositoryImpl will fail because there are no suitable drivers to
connect to a database whose URL is jdbc:foo:bar. The second attempt to
connect however doesn't fail for the same reason and instead fails because of
the .lock file being present.

Repository Home locked not released despite RepositoryException being thrown.
-

Key: JCR-1318
URL: https://issues.apache.org/jira/browse/JCR-1318
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-core
Affects Versions: 1.3.3
Environment: windows vista jdk 5
Reporter: Micah Whitacre
Attachments: JCR_1318_tests.zip

When an exception is thrown when calling RepositoryImpl.create(...) a .lock
file is created in the repository home directory and not removed despite
there no longer being an active connection. If the user attempts to create
the repository again (e.g recover from the exception because the url of the
repository was temporarily unavailable) a RepositoryException is thrown again
indicating that the repository home is locked by another process because
there is a .lock file. If a Repository is not successfully created then the
repository home should not be locked.
The lock is only released when the repository is shutdown but in this case
the Repository object is never created successfully for that method to be
called.

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

[jira] Resolved: (JCR-1046) Non-versionable children of a versionable node should not be updated when a merge fails

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

Tobias Bocanegra resolved JCR-1046.
---

Resolution: Fixed
Fix Version/s: 1.5

fixed as proposed.

Non-versionable children of a versionable node should not be updated when a
merge fails
---

Key: JCR-1046
URL: https://issues.apache.org/jira/browse/JCR-1046
Project: Jackrabbit
Issue Type: Bug
Components: versioning
Affects Versions: 1.3, 1.3.1, 1.3.3, 1.4, 1.5
Reporter: Bob Wieler
Assignee: Tobias Bocanegra
Fix For: 1.5

Attachments: jcr1046.diff

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

[jira] Updated: (JCR-1046) Non-versionable children of a versionable node should not be updated when a merge fails


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

Tobias Bocanegra updated JCR-1046:
--

Affects Version/s: 1.5
   1.3.1
   1.3.3
   1.4

 Non-versionable children of a versionable node should not be updated when a 
 merge fails
 ---

 Key: JCR-1046
 URL: https://issues.apache.org/jira/browse/JCR-1046
 Project: Jackrabbit
  Issue Type: Bug
  Components: versioning
Affects Versions: 1.3, 1.3.1, 1.3.3, 1.4, 1.5
Reporter: Bob Wieler
Assignee: Tobias Bocanegra
 Fix For: 1.5

 Attachments: jcr1046.diff


 The JCR specification (JSR-170) includes a merge algorithm that is 
 inconsistent with the functionality described elsewhere in the JCR 
 specification. Specifically from JSR-170 section 8.2.10 Merge:
 In either case, (regardless of whether bestEffort is true or false) for each 
 non-versionable node (including both referenceable and non-referenceable), if 
 the merge result of its nearest versionable ancestor is update, or if it has 
 no versionable ancestor, then it is updated to reflect the state of its 
 corresponding node. Otherwise, it is left unchanged.
 The algorithm presented in 8.2.10.1 of the specification goes against the 
 above statement as it does not take into consideration the merge result of 
 the nearest versionable ancestor.
 One solution would be to have the doLeave(n) call that dofail(n, v') calls 
 altered to only perform a merge on the versionable children rather than all 
 of the children. The merging of all children (versionable and 
 non-versionable) should only be done if the nearest parent is not in a failed 
 merge state regardless of whether the failure occurred from the current merge 
 operation or a previous merge operation.
 I will attach a patch file that makes what I think is the required change.

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

Fwd: [continuum] BUILD FAILURE: Apache Jackrabbit - Jackrabbit Core - Build Def: Jackrabbit build with Java 1.4

2008-01-16 Thread Jukka Zitting

Hi,

Yes, I still need to fix the email notifications...

Anyway, it seems like the JCR-1046 fix broke something.

BR,

Jukka Zitting

-- Forwarded message --
From: [EMAIL PROTECTED] [EMAIL PROTECTED]
Date: Jan 17, 0008 1:10 AM
Subject: [continuum] BUILD FAILURE: Apache Jackrabbit - Jackrabbit
Core - Build Def: Jackrabbit build with Java 1.4
To: [EMAIL PROTECTED]


Online report :
http://jackrabbit.zones.apache.org/continuum/buildResult.action?buildId=1735projectId=6

Build statistics:
  State: Failed
  Previous State: Ok
  Started at: Wed 16 Jan 2008 23:07:42 +
  Finished at: Wed 16 Jan 2008 23:10:38 +
  Total time: 2m 55s
  Build Trigger: Schedule
  Build Number: 86
  Exit code: 1
  Building machine hostname: jackrabbit.zones
  Operating system : SunOS(unknown)
  Java Home version :
  java version 1.4.2_06
  Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03)
  Java HotSpot(TM) Client VM (build 1.4.2_06-b03, mixed mode)

  Builder version :
  Maven version: 2.0.7
  Java version: 1.4.2_06
  OS name: sunos version: 5.10 arch: x86


SCM Changes:

Changed: tripod @ Wed 16 Jan 2008 22:48:22 +
Comment: JCR-1046 Non-versionable children of a versionable node
should not be updated when a merge fails
Files changed:
  
/jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/NodeImpl.java
( 612604 )


Dependencies Changes:

org.apache.jackrabbit:jackrabbit-api:1.5-SNAPSHOT

org.apache.jackrabbit:jackrabbit-jcr-commons:1.5-SNAPSHOT

org.apache.jackrabbit:jackrabbit-spi-commons:1.5-SNAPSHOT

org.apache.jackrabbit:jackrabbit-spi:1.5-SNAPSHOT

org.apache.jackrabbit:jackrabbit-text-extractors:1.5-SNAPSHOT

org.apache.jackrabbit:jackrabbit-jcr-tests:1.5-SNAPSHOT

org.apache.jackrabbit:jackrabbit:1.5-SNAPSHOT



Build Defintion:

POM filename: pom.xml
Goals: clean deploy
Arguments: --batch-mode --non-recursive -DuniqueVersion=false
Build Fresh: false
Always Build: false
Default Build Definition: true
Schedule: DEFAULT_SCHEDULE
Profile Name: Java 1.4
Description: Jackrabbit build with Java 1.4


Test Summary:

Tests: 1262
Failures: 1
Total time: 106.81


Test Failures:


JCRAPITest
testMergeNodeNonVersionableSubNodeUpdate :
  junit.framework.AssertionFailedError
  junit.framework.AssertionFailedError
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.assertTrue(Assert.java:20)
at junit.framework.Assert.assertTrue(Assert.java:27)
at 
org.apache.jackrabbit.test.api.version.MergeNonVersionableSubNodeTest.testMergeNodeNonVersionableSubNodeUpdate(MergeNonVersionableSubNodeTest.java:86)

[jira] Updated: (JCR-1318) Repository Home locked not released despite RepositoryException being thrown.

2008-01-16 Thread Micah Whitacre (JIRA)


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

Micah Whitacre updated JCR-1318:


Attachment: JCR_1318-patch.txt

I created a patch based on the 1.3 branch of jackrabbit-core that isn't 
necessarily pretty but does at least make the testcase i provided repeatedly 
generate the same stack trace for attempts to create an instance of 
RepositoryImpl.  This could probably be simplified a bit if the shutdown() 
method was a little bit more tolerant of everything not necessarily being 
initialized by that point.  

 Repository Home locked not released despite RepositoryException being thrown.
 -

 Key: JCR-1318
 URL: https://issues.apache.org/jira/browse/JCR-1318
 Project: Jackrabbit
  Issue Type: Bug
  Components: jackrabbit-core
Affects Versions: 1.3.3
 Environment: windows vista  jdk 5
Reporter: Micah Whitacre
 Attachments: JCR_1318-patch.txt, JCR_1318_tests.zip


 When an exception is thrown when calling RepositoryImpl.create(...) a .lock 
 file is created in the repository home directory and not removed despite 
 there no longer being an active connection.  If the user attempts to create 
 the repository again (e.g recover from the exception because the url of the 
 repository was temporarily unavailable) a RepositoryException is thrown again 
 indicating that the repository home is locked by another process because 
 there is a .lock file.  If a Repository is not successfully created then the 
 repository home should not be locked.
 The lock is only released when the repository is shutdown but in this case 
 the Repository object is never created successfully for that method to be 
 called.

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

Re: [continuum] BUILD FAILURE: Apache Jackrabbit - Jackrabbit Core - Build Def: Jackrabbit build with Java 1.4

2008-01-16 Thread Tobias Bocanegra

ok, i will take a look at it more closely.
regards, toby


On 1/17/08, Jukka Zitting [EMAIL PROTECTED] wrote:
 Hi,

 Yes, I still need to fix the email notifications...

 Anyway, it seems like the JCR-1046 fix broke something.

 BR,

 Jukka Zitting

 -- Forwarded message --
 From: [EMAIL PROTECTED] [EMAIL PROTECTED]
 Date: Jan 17, 0008 1:10 AM
 Subject: [continuum] BUILD FAILURE: Apache Jackrabbit - Jackrabbit
 Core - Build Def: Jackrabbit build with Java 1.4
 To: [EMAIL PROTECTED]


 Online report :
 http://jackrabbit.zones.apache.org/continuum/buildResult.action?buildId=1735projectId=6

 Build statistics:
   State: Failed
   Previous State: Ok
   Started at: Wed 16 Jan 2008 23:07:42 +
   Finished at: Wed 16 Jan 2008 23:10:38 +
   Total time: 2m 55s
   Build Trigger: Schedule
   Build Number: 86
   Exit code: 1
   Building machine hostname: jackrabbit.zones
   Operating system : SunOS(unknown)
   Java Home version :
   java version 1.4.2_06
   Java(TM) 2 Runtime Environment, Standard Edition (build 
 1.4.2_06-b03)
   Java HotSpot(TM) Client VM (build 1.4.2_06-b03, mixed mode)

   Builder version :
   Maven version: 2.0.7
   Java version: 1.4.2_06
   OS name: sunos version: 5.10 arch: x86

 
 SCM Changes:
 
 Changed: tripod @ Wed 16 Jan 2008 22:48:22 +
 Comment: JCR-1046 Non-versionable children of a versionable node
 should not be updated when a merge fails
 Files changed:
   
 /jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/NodeImpl.java
 ( 612604 )

 
 Dependencies Changes:
 
 org.apache.jackrabbit:jackrabbit-api:1.5-SNAPSHOT

 org.apache.jackrabbit:jackrabbit-jcr-commons:1.5-SNAPSHOT

 org.apache.jackrabbit:jackrabbit-spi-commons:1.5-SNAPSHOT

 org.apache.jackrabbit:jackrabbit-spi:1.5-SNAPSHOT

 org.apache.jackrabbit:jackrabbit-text-extractors:1.5-SNAPSHOT

 org.apache.jackrabbit:jackrabbit-jcr-tests:1.5-SNAPSHOT

 org.apache.jackrabbit:jackrabbit:1.5-SNAPSHOT


 
 Build Defintion:
 
 POM filename: pom.xml
 Goals: clean deploy
 Arguments: --batch-mode --non-recursive -DuniqueVersion=false
 Build Fresh: false
 Always Build: false
 Default Build Definition: true
 Schedule: DEFAULT_SCHEDULE
 Profile Name: Java 1.4
 Description: Jackrabbit build with Java 1.4

 
 Test Summary:
 
 Tests: 1262
 Failures: 1
 Total time: 106.81

 
 Test Failures:
 

 JCRAPITest
 testMergeNodeNonVersionableSubNodeUpdate :
   junit.framework.AssertionFailedError
   junit.framework.AssertionFailedError
 at junit.framework.Assert.fail(Assert.java:47)
 at junit.framework.Assert.assertTrue(Assert.java:20)
 at junit.framework.Assert.assertTrue(Assert.java:27)
 at 
 org.apache.jackrabbit.test.api.version.MergeNonVersionableSubNodeTest.testMergeNodeNonVersionableSubNodeUpdate(MergeNonVersionableSubNodeTest.java:86)



-- 
- [EMAIL PROTECTED] ---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
--- http://www.day.com ---

[jira] Commented: (JCR-1312) Get rid of DOM for XML support

2008-01-16 Thread Felix Meschberger (JIRA)


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

Felix Meschberger commented on JCR-1312:


 Jackrabbit is not an XML parser project. 

Definitely agreed on that one.

 Why doesn't kxml come with the DocumentBuilder implementation?

Probably, they don't need it. But if you look at the patch, we are discussing 
three classes:

   * XmlPullDocumentBuilderFactory: A very simple class backed by a JAXP 
DocumentBuilderFactory
   * XmlPullDocumentBuilder: Also very simple, just one method of real 
complication, of which the
   most part is taken to guess the streams character encoding
   * DOM2XmlPullBuilder: The actual builder converting Pull Events to DOM. This 
class is copied
   from xmlpull.org
   * XmlPullDomSerializer: Straight forward and simple as well.

IMHO given advantages (memory footprint (1% of Xerces) and performance (40-60% 
of Xerces)) this is probably a small price to pay :-)

 Get rid of DOM for XML support
 --

 Key: JCR-1312
 URL: https://issues.apache.org/jira/browse/JCR-1312
 Project: Jackrabbit
  Issue Type: Improvement
  Components: jackrabbit-webdav
Reporter: Felix Meschberger

 Currently the web dav library uses Xerces and DOM to parse and create XML 
 data. This mechanism is well-known but has two major issues: It is slow and 
 it has a big memory footprint. In order to solve these two issues, I suggest 
 to drop the use of the W3C DOM in webdav in favor of something easier and 
 more straight forward to use.
 One candidate could be (out of my head and based on my bias towards KXml) 
 KDOM. See also http://www.kxml.org.ww
 See also JCR-1261 for more discussions on this issue.

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

[jira] Reopened: (JCR-1046) Non-versionable children of a versionable node should not be updated when a merge fails