[jira] Created: (JCR-1467) Hide ugly repository init code for OCM
Hide ugly repository init code for OCM -- Key: JCR-1467 URL: https://issues.apache.org/jira/browse/JCR-1467 Project: Jackrabbit Issue Type: New Feature Components: jackrabbit-ocm Environment: All Reporter: Alex Lukin Fix For: 1.5 Hide repository namespace registration and ocm:discriminator node type registration in implementation of OCM -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1467) Hide ugly repository init code for OCM
[ https://issues.apache.org/jira/browse/JCR-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Lukin updated JCR-1467: Attachment: jackrabbit-OCM-repoinit.patch This patch applies only to implememntation code. It's upt to author of OCM to put it into interface Hide ugly repository init code for OCM -- Key: JCR-1467 URL: https://issues.apache.org/jira/browse/JCR-1467 Project: Jackrabbit Issue Type: New Feature Components: jackrabbit-ocm Environment: All Reporter: Alex Lukin Fix For: 1.5 Attachments: jackrabbit-OCM-repoinit.patch Original Estimate: 1h Remaining Estimate: 1h Hide repository namespace registration and ocm:discriminator node type registration in implementation of OCM -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: OCM: why not to hide ugly init code?
Wednesday 12 March 2008 00:34:27 Christophe Lombart написав: Just one comment : The OCM has to be completely independent of Jackrabbit core. By this way, it can be used with other JCR implementation. As you can see, Jackrabbit core is only used for the unit tests. That's why the code is so ugly ... until there is a standard way to add new node types. I see. So my Jira Isuue and patch has to be deleted. Node type registration is standard in JSR-283 so we have to wait when it will be ready. Anyway, use of custom node types is not quite mandatory for OCM. It is possible to use some hidden property to store needed info. -- SY, Alex Lukin RIPE NIC HDL: LEXA1-RIPE
Re: Project Idea for GSoC based on Jackrabbit
On Tue, Mar 11, 2008 at 9:50 AM, Jukka Zitting [EMAIL PROTECTED] wrote: ...On Mon, Mar 10, 2008 at 10:34 AM, Thilina Buddhika [EMAIL PROTECTED] wrote: I am really interested in Apache Jackrabbit project. I have been building some applications on top of Jackrabbit, and I am realizing the potential of Jackrabbit. So I thought of doing a GSoC project based on Apache Jackrabbit ...unfortunately I don't think I have enough spare cycles for mentoring next summer. Would someone else from the Jackrabbit team be interested?... I don't want to steer you away from Jackrabbit, but if no one from Jackrabbit is willing/able to mentor this, such a project could also happen over at Sling [1], where we currently need such demo applications. -Bertrand [1] http://incubator.apache.org/sling
[jira] Closed: (JCR-1336) Bug in duplicate mapping check
[
https://issues.apache.org/jira/browse/JCR-1336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler closed JCR-1336.
-
Looks good to me. Thanks!
Bug in duplicate mapping check
--
Key: JCR-1336
URL: https://issues.apache.org/jira/browse/JCR-1336
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-ocm
Affects Versions: 1.4
Reporter: Carsten Ziegeler
Assignee: Christophe Lombart
Fix For: 1.5
There is a bug in the MappingDescriptor for checking if a mapping for a node
type is already available. The following patch solves this problem:
Index:
/Users/cziegeler/Developer/workspaces/default/jackrabbit/jackrabbit-ocm/src/main/java/org/apache/jackrabbit/ocm/mapper/model/MappingDescriptor.java
===
---
/Users/cziegeler/Developer/workspaces/default/jackrabbit/jackrabbit-ocm/src/main/java/org/apache/jackrabbit/ocm/mapper/model/MappingDescriptor.java
(revision 614136)
+++
/Users/cziegeler/Developer/workspaces/default/jackrabbit/jackrabbit-ocm/src/main/java/org/apache/jackrabbit/ocm/mapper/model/MappingDescriptor.java
(working copy)
@@ -75,7 +75,7 @@
if (null != classDescriptor.getJcrType() !
.equals(classDescriptor.getJcrType())
!
ManagerConstant.NT_UNSTRUCTURED.equals(classDescriptor.getJcrType()))
{
- if
((classDescriptorsByNodeType.get(classDescriptor.getClassName()) != null)
+ if
((classDescriptorsByNodeType.get(classDescriptor.getJcrType()) != null)
classDescriptor.usesNodeTypePerConcreteClassStrategy()
)
{
log.warn(Duplicate classdescriptor for node type : +
classDescriptor.getJcrType());
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: OCM: why not to hide ugly init code?
Wednesday 12 March 2008 10:52:58 Christophe Lombart написав: If I understand you, your proposal is something like this : 1. If the class is mapped to the unstructured node type or a node type that gives you the possibility to add extra properties, create a new property ocm_classname. 2. If it is not possible to add this property due to strong constrains in the corresponding node type, try to add the mixin type ocm:discriminator (if necessary). Is it something like this ? Yes, exactly. I doubd pople are using restrictive node types in real life with OCM. Counting that jcr-1.0 does not support custom node types ... So it will be rather rare exception to use some mixin type to store mapping class info. For instance JCROM OCM implementation does not require any custom node registration. BTW, it easy maps binary content. See http://code.google.com/p/jcrom/ -- SY, Alex Lukin RIPE NIC HDL: LEXA1-RIPE
Re: OCM: why not to hide ugly init code?
If I understand you, your proposal is something like this : 1. If the class is mapped to the unstructured node type or a node type that gives you the possibility to add extra properties, create a new property ocm_classname. 2. If it is not possible to add this property due to strong constrains in the corresponding node type, try to add the mixin type ocm:discriminator (if necessary). Is it something like this ? Christophe On Wed, Mar 12, 2008 at 8:59 AM, Alex Lukin [EMAIL PROTECTED] wrote: Wednesday 12 March 2008 00:34:27 Christophe Lombart написав: Just one comment : The OCM has to be completely independent of Jackrabbit core. By this way, it can be used with other JCR implementation. As you can see, Jackrabbit core is only used for the unit tests. That's why the code is so ugly ... until there is a standard way to add new node types. I see. So my Jira Isuue and patch has to be deleted. Node type registration is standard in JSR-283 so we have to wait when it will be ready. Anyway, use of custom node types is not quite mandatory for OCM. It is possible to use some hidden property to store needed info. -- SY, Alex Lukin RIPE NIC HDL: LEXA1-RIPE
[jira] Commented: (JCR-1467) Hide ugly repository init code for OCM
[ https://issues.apache.org/jira/browse/JCR-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577787#action_12577787 ] Christophe Lombart commented on JCR-1467: - The full story : http://www.mail-archive.com/dev@jackrabbit.apache.org/msg11205.html Hide ugly repository init code for OCM -- Key: JCR-1467 URL: https://issues.apache.org/jira/browse/JCR-1467 Project: Jackrabbit Issue Type: New Feature Components: jackrabbit-ocm Environment: All Reporter: Alex Lukin Fix For: 1.5 Attachments: jackrabbit-OCM-repoinit.patch Original Estimate: 1h Remaining Estimate: 1h Hide repository namespace registration and ocm:discriminator node type registration in implementation of OCM -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1461) Deadlock on concurrent commit/checkin operations
[ https://issues.apache.org/jira/browse/JCR-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated JCR-1461: -- Attachment: JCR-1461.patch So far I haven't been able to reproduce the deadlock with a test. Just looking at the thread dump we can avoid the deadlock by pulling the getPath() in LockManagerImpl.getLockInfo() out of the acquire/release() scope. I've attached a patch with that change. Przemo, can you please build jackrabbit-core-1.3.4-rc1 again with this patch applied and check if the deadlock still occurs? It also seems that there's another thread involved in the deadlock. Can you please attach the complete thread dump? Stripping off application specific stack frames is of course OK. Deadlock on concurrent commit/checkin operations Key: JCR-1461 URL: https://issues.apache.org/jira/browse/JCR-1461 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-core Affects Versions: 1.3.3, 1.3.4 Reporter: Przemo Pakulski Priority: Critical Attachments: JCR-1461.patch, thread-dump.txt Running concurrently jackrabbit transactions including checkin operations leads to deadlock. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1463) Core: Failing version tests (testRestore....)
[
https://issues.apache.org/jira/browse/JCR-1463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577802#action_12577802
]
angela commented on JCR-1463:
-
once more:
testRestoreName(org.apache.jackrabbit.test.api.version.RestoreTest) Time
elapsed: 0.109 sec FAILURE!
junit.framework.ComparisonFailure: Node.restore('test') must restore child node
version 1.0. expected:...0 but was:...1
at junit.framework.Assert.assertEquals(Assert.java:81)
at
org.apache.jackrabbit.test.api.version.RestoreTest.testRestoreName(RestoreTest.java:362)
Core: Failing version tests (testRestore)
-
Key: JCR-1463
URL: https://issues.apache.org/jira/browse/JCR-1463
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-core
Reporter: angela
Attachments:
TEST-org.apache.jackrabbit.core.integration.JCRAPITest.xml
i run into failing restore test in the core project while trying to reproduce
JCR-1293.
since that i had similar (or the same) tests failing more than once.
therefore i guess this is really caused by a bug in the restore code or in
the corresponding tests and not an maven-artifact.
the next time i get it, i will attach the surefire report.
regards
angela
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1468) LockTest.testLogout fails to refresh session before checking lock from other session
LockTest.testLogout fails to refresh session before checking lock from other session Key: JCR-1468 URL: https://issues.apache.org/jira/browse/JCR-1468 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-jcr-tests Reporter: Julian Reschke Assignee: Julian Reschke Priority: Minor LockTest.testLogout() fails to refresh the session before checking the lock state of a node that was locked by another session. Proposal: Insert n1.refresh(false); before assertTrue(node must be locked, n1.isLocked()); -- 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-1468) LockTest.testLogout fails to refresh session before checking lock from other session
[ https://issues.apache.org/jira/browse/JCR-1468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577836#action_12577836 ] reschke edited comment on JCR-1468 at 3/12/08 5:50 AM: -- Fixed with revision 636305. was (Author: reschke): Wixed with revision 636305. LockTest.testLogout fails to refresh session before checking lock from other session Key: JCR-1468 URL: https://issues.apache.org/jira/browse/JCR-1468 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-jcr-tests Reporter: Julian Reschke Assignee: Julian Reschke Priority: Minor LockTest.testLogout() fails to refresh the session before checking the lock state of a node that was locked by another session. Proposal: Insert n1.refresh(false); before assertTrue(node must be locked, n1.isLocked()); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1468) LockTest.testLogout fails to refresh session before checking lock from other session
[ https://issues.apache.org/jira/browse/JCR-1468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke resolved JCR-1468. - Resolution: Fixed Wixed with revision 636305. LockTest.testLogout fails to refresh session before checking lock from other session Key: JCR-1468 URL: https://issues.apache.org/jira/browse/JCR-1468 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-jcr-tests Reporter: Julian Reschke Assignee: Julian Reschke Priority: Minor LockTest.testLogout() fails to refresh the session before checking the lock state of a node that was locked by another session. Proposal: Insert n1.refresh(false); before assertTrue(node must be locked, n1.isLocked()); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Repository BackUp and Restore
Hi All I am working on Project Mirage (https://mirage.dev.java.net) which uses JackRabbit as content repository. I wanted to backup/restore the entire content when we migrate from one database to another. I have gone through some earlier mail threads and found about JECARS and JCR-Backup Tools. I have tried out JECARS , but it hangs indefinitely after exporting namespaces and nodetypes. Look's like it is hanging while exporting content. But there is not much content stored in my repository. And with JCR-BackUp tool I couldn't try out because ,I couldn't find any kind of help or documentation . Looks like both of these tools are still in development phase and not fully feature complete. Can anyone suggest how we can go about , entire repository backup/restore ,specially when DbPersistenceManager is used and all the content is being stored in a database. Restore should be able to import entire node structure ,create tables and store the entire content in the new database . Any help would be appreciated. Regards K.Joshna
[continuum] BUILD FAILURE: Apache Jackrabbit - Apache Jackrabbit - Build Def: Jackrabbit build with Java 1.4
Online report : http://jackrabbit.zones.apache.org/continuum/buildResult.action?buildId=3172projectId=2 Build statistics: State: Failed Previous State: Ok Started at: Wed 12 Mar 2008 13:48:48 + Finished at: Wed 12 Mar 2008 13:55:55 + Total time: 7m 6s Build Trigger: Schedule Build Number: 174 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: reschke @ Wed 12 Mar 2008 12:50:20 + Comment: JCR-1468: add missing call to refresh() Files changed: /jackrabbit/trunk/jackrabbit-jcr-tests/src/main/java/org/apache/jackrabbit/test/api/lock/LockTest.java ( 636305 ) Dependencies Changes: No dependencies changed Build Defintion: POM filename: pom.xml Goals: clean deploy Arguments: --batch-mode 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: 2850 Failures: 0 Total time: 398.767
[jira] Created: (JCR-1469) Data store garbage collection: ScanEventListener not working
Data store garbage collection: ScanEventListener not working Key: JCR-1469 URL: https://issues.apache.org/jira/browse/JCR-1469 Project: Jackrabbit Issue Type: Bug Affects Versions: core 1.4.1 Reporter: Thomas Mueller Assignee: Thomas Mueller Fix For: core 1.4.2 The ScanEventListener is currently only called when using the 'scan all nodes recursively' strategy. It is not called when all persistence managers implement IterablePersistenceManager (GarbageCollector.scanPersistenceManagers). The ScanEventListener should be called in every case, otherwise it is not possible to see the progress of the garbage collection. However there is a problem: IterablePersistenceManager.getAllNodeIds() doesn't return Node objects, and it would make little sense to create real node objects (the performance advantage of scanPersistenceManagers would be lost). Therefore, I propose a workaround: the ScanEventListener is called using a 'PseudoNode'. This is a class that implements Node but only has meaningful getUUID() and toString() methods. This allows to create a meaningful progress bar (as the UUIDs are returned in order). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1470) NPE in BeanReferenceCollectionConverterImpl on update on empty collection
NPE in BeanReferenceCollectionConverterImpl on update on empty collection
-
Key: JCR-1470
URL: https://issues.apache.org/jira/browse/JCR-1470
Project: Jackrabbit
Issue Type: Bug
Components: observation
Affects Versions: 1.5
Environment: mac os leopard, java5
Reporter: Stephane Landelle
use case :
in the same transaction :
*) retrieve an object that has a collection of references, yet empty
*) add an element in the collection
*) update the object
consequence :
org.apache.jackrabbit.ocm.exception.ObjectContentManagerException: Cannot
insert collection field : authors of class com.weka.content.api.model.Folder;
nested exception is java.lang.NullPointerException: null
java.lang.NullPointerException
at
org.apache.jackrabbit.ocm.manager.collectionconverter.impl.ManageableArrayList$$EnhancerByCGLIB$$8f15dde4.getSize(generated)
at
org.apache.jackrabbit.ocm.manager.collectionconverter.impl.BeanReferenceCollectionConverterImpl.addUuidProperties(BeanReferenceCollectionConverterImpl.java:154)
at
org.apache.jackrabbit.ocm.manager.collectionconverter.impl.BeanReferenceCollectionConverterImpl.doUpdateCollection(BeanReferenceCollectionConverterImpl.java:101)
The failing line is in addUuidProperties :
Value[] values = new Value[collection.getSize()];
It seems the CGlib enhanced collection fails and needs to be initialized before.
For example, in doUpdateCollection, if I code :
// Delete existing values
if (parentNode.hasProperty(jcrName)) {
parentNode.setProperty(jcrName, (Value[]) null);
}
if (collection != null) {
collection.getSize();
}
I get a NPE on collection.getSize();
but if I code :
if (collection != null) {
collection.getSize();
}
// Delete existing values
if (parentNode.hasProperty(jcrName)) {
parentNode.setProperty(jcrName, (Value[]) null);
}
everything runs fine?!
--
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 - Apache Jackrabbit - Build Def: Jackrabbit build with Java 1.4
Hi, On Mon, Mar 12, 0008 at 3:56 PM, Jackrabbit Continuum [EMAIL PROTECTED] wrote: Build statistics: State: Failed There seems to be a random concurrent addNode() test error in trunk at the moment. The details are in: http://jackrabbit.zones.apache.org:8080/continuum/buildResult.action?buildId=3172projectId=2projectGroupId=6 http://jackrabbit.zones.apache.org:8080/continuum/buildResult.action?buildId=3167projectId=2projectGroupId=6 The issue seems to be a case where two concurrent treads add a child node with the same name to the same parent. There seems to be a case (critical line is 770 in NodeImpl.java) where the shared node state contains the child node added by the first thread but the underlying ItemManager throws an ItemNotFoundException, when the second thread tries to access that child node. I'll see if I can qualify the problem better or come up with a more reliable test case, and will file a bug report on this. BR, Jukka Zitting
[jira] Commented: (JCR-1233) Create org.apache.jackrabbit.core.id
[ https://issues.apache.org/jira/browse/JCR-1233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577875#action_12577875 ] Felix Meschberger commented on JCR-1233: Just my €.02 from the perspective of an OSGi user and modularization lover: Having all these classes mixed with internal implementation code prevents proper separation of API and implementation and in fact prevents proper OSGi separation. For example, it would be almost impossible to make the API externally visible and not at the same time make the implementation visible ... IMHO this is not a matter of making jackrabbit look better in code quality tools, it is a matter of good programming style (oh yeah, another one from pandorra's box) supporting separation of concern. Create org.apache.jackrabbit.core.id Key: JCR-1233 URL: https://issues.apache.org/jira/browse/JCR-1233 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Reporter: Jukka Zitting Priority: Minor I'd like to create a separate package for the identifier interfaces and classes in jackrabbit-core. Currently all the identifiers are in org.apache.jackrabbit.core, which makes almost all the other packages have dependencies to o.a.j.core and causes trouble for various package-level code quality and dependency analysis tools. For now the package would contain the ItemId, NodeId, and PropertyId classes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Repository BackUp and Restore
I've tested JCR-Backup and work... more or less. They are migrating to Jacrabbit 1.4 because actually only supports 1.3 repositories. And i'm not sure it exports/imports version history. El mié, 12-03-2008 a las 18:25 +0530, Joshna Reddy escribió: Hi All I am working on Project Mirage (https://mirage.dev.java.net) which uses JackRabbit as content repository. I wanted to backup/restore the entire content when we migrate from one database to another. I have gone through some earlier mail threads and found about JECARS and JCR-Backup Tools. I have tried out JECARS , but it hangs indefinitely after exporting namespaces and nodetypes. Look's like it is hanging while exporting content. But there is not much content stored in my repository. And with JCR-BackUp tool I couldn't try out because ,I couldn't find any kind of help or documentation . Looks like both of these tools are still in development phase and not fully feature complete. Can anyone suggest how we can go about , entire repository backup/restore ,specially when DbPersistenceManager is used and all the content is being stored in a database. Restore should be able to import entire node structure ,create tables and store the entire content in the new database . Any help would be appreciated. Regards K.Joshna -- Paco Avila [EMAIL PROTECTED] GIT Consultors
[jira] Commented: (JCR-1233) Create org.apache.jackrabbit.core.id
[ https://issues.apache.org/jira/browse/JCR-1233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577900#action_12577900 ] Jukka Zitting commented on JCR-1233: Side note: IMHO for code to look good in code quality tools is or at least should be equivalent to good programming style. If not, then there's something wrong with the tools. :-) As for why I think moving the Ids to a separate package is especially important for code quality tools: as long as they are in o.a.j.core many tools have trouble identifying circular dependencies and other design issues beyond the obvious o.a.j.core.foo - o.a.j.core dependencies caused by the Id classes. Creating o.a.j.core.id will not solve those issues, but will at least make them more visible and thus easier to solve. Create org.apache.jackrabbit.core.id Key: JCR-1233 URL: https://issues.apache.org/jira/browse/JCR-1233 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Reporter: Jukka Zitting Priority: Minor I'd like to create a separate package for the identifier interfaces and classes in jackrabbit-core. Currently all the identifiers are in org.apache.jackrabbit.core, which makes almost all the other packages have dependencies to o.a.j.core and causes trouble for various package-level code quality and dependency analysis tools. For now the package would contain the ItemId, NodeId, and PropertyId classes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1461) Deadlock on concurrent commit/checkin operations
[ https://issues.apache.org/jira/browse/JCR-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577929#action_12577929 ] Przemo Pakulski commented on JCR-1461: -- Hm, deadlock occured when running 2 threads only. How do you know that another thread was involved ? Deadlock on concurrent commit/checkin operations Key: JCR-1461 URL: https://issues.apache.org/jira/browse/JCR-1461 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-core Affects Versions: 1.3.3, 1.3.4 Reporter: Przemo Pakulski Priority: Critical Attachments: JCR-1461.patch, thread-dump.txt Running concurrently jackrabbit transactions including checkin operations leads to deadlock. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Request releases of RMI and commons libraries
Hi all, Over in the Sling project we are slowly but steadily approaching a first release and are now trying to resolve any existing SNAPSHOT dependencies. Two of these dependencies are Jackrabbit dependencies: * jackrabbit-jcr-rmi The current snapshot contains fixes for the JCR-1406 and JCR-1454 which we are depending on in the Sling project * jackrabbit-jcr-commons The interesting point about this snapshot is an extension to the pom which effectively makes the jar file an OSGi bundle so that we can directly use this in Sling. Would it be possible to get 1.4.1 releases of these libraries with (at least) the mentioned fixes backported to the 1.4 branch ? Thanks for any help. Regards Felix
[jira] Updated: (JCR-1440) NPE Thrown when two Cluster Nodes are hitting the same underlying database.
[ https://issues.apache.org/jira/browse/JCR-1440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Micah Whitacre updated JCR-1440: Attachment: repository1.xml I've played around with my configuration a bit more and am still not able to get rid of the NPE. In this attachment I modified the repository1.xml file to use the bundle.PersistenceManager and configured a DbDataStore. For the testing purposes repository2.xml is an exact duplicate of the attachment (with a different cluster id). This change in configuration does not fix the NPE. This still seems like an Jackrabbit issue instead of an error in my configuration. NPE Thrown when two Cluster Nodes are hitting the same underlying database. --- Key: JCR-1440 URL: https://issues.apache.org/jira/browse/JCR-1440 Project: Jackrabbit Issue Type: Bug Affects Versions: 1.4, core 1.4.1 Environment: Vista JDK 1.5.0_12. Using Derby and Derby Client 10.1.2.1 Reporter: Micah Whitacre Priority: Critical Attachments: repository1.xml, SimpleJackRabbitTest.zip I've created a test that creates two repositories with clustering enabled that are backed by the same database. Using the following workflow causes a NullPointerException to be thrown. The workflow I'm using is: The root node is versioned. ClusterNode1 creates a versioned child node named foo. The test waits to make sure the syncDelay has passed so ClusterNode2 will notice the newly created node. ClusterNode2 retrieves the foo child node and removes it. The test waits for the change ClusterNode1 to sync with that change. ClusterNode1 tries to create another new node however a NullPointerException is thrown when the it tries to checkout the rootNode. java.lang.NullPointerException: null values not allowed at org.apache.commons.collections.map.AbstractReferenceMap.put(AbstractReferenceMap.java:251) at org.apache.jackrabbit.core.version.VersionManagerImpl.getItem(VersionManagerImpl.java:280) at org.apache.jackrabbit.core.version.XAVersionManager.getItem(XAVersionManager.java:334) at org.apache.jackrabbit.core.version.AbstractVersionManager.getVersion(AbstractVersionManager.java:87) at org.apache.jackrabbit.core.NodeImpl.getBaseVersion(NodeImpl.java:3198) at org.apache.jackrabbit.core.NodeImpl.checkout(NodeImpl.java:2991) at com.cerner.system.configuration.repository.jcr.SimpleJackrabbitConflictTest.testNullPointerExceptionThrown(SimpleJackrabbitConflictTest.java:96) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1440) NPE Thrown when two Cluster Nodes are hitting the same underlying database.
[
https://issues.apache.org/jira/browse/JCR-1440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Micah Whitacre updated JCR-1440:
Attachment: SimpleJackrabbitConflictTest.java
I have been playing around with the test a bit and have found that if I don't
wait for the clusters to synchronize after deleting the node foo that I will
get the following stack trace when trying to check out the root node of he
first session again.
Not completely related to this bug but thought I'd post what I was finding.
javax.jcr.InvalidItemStateException:
cafebabe-cafe-babe-cafe-babecafebabe/{http://www.jcp.org/jcr/1.0}isCheckedOut
has been modified externally
at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1248)
at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:896)
at org.apache.jackrabbit.core.NodeImpl.checkout(NodeImpl.java:3001)
at
com.cerner.system.configuration.repository.jcr.SimpleJackrabbitConflictTest.testNullPointerExceptionThrown(SimpleJackrabbitConflictTest.java:99)
NPE Thrown when two Cluster Nodes are hitting the same underlying database.
---
Key: JCR-1440
URL: https://issues.apache.org/jira/browse/JCR-1440
Project: Jackrabbit
Issue Type: Bug
Affects Versions: 1.4, core 1.4.1
Environment: Vista JDK 1.5.0_12. Using Derby and Derby Client
10.1.2.1
Reporter: Micah Whitacre
Priority: Critical
Attachments: repository1.xml, SimpleJackrabbitConflictTest.java,
SimpleJackRabbitTest.zip
I've created a test that creates two repositories with clustering enabled
that are backed by the same database. Using the following workflow causes a
NullPointerException to be thrown.
The workflow I'm using is:
The root node is versioned.
ClusterNode1 creates a versioned child node named foo.
The test waits to make sure the syncDelay has passed so ClusterNode2 will
notice the newly created node.
ClusterNode2 retrieves the foo child node and removes it.
The test waits for the change ClusterNode1 to sync with that change.
ClusterNode1 tries to create another new node however a NullPointerException
is thrown when the it tries to checkout the rootNode.
java.lang.NullPointerException: null values not allowed
at
org.apache.commons.collections.map.AbstractReferenceMap.put(AbstractReferenceMap.java:251)
at
org.apache.jackrabbit.core.version.VersionManagerImpl.getItem(VersionManagerImpl.java:280)
at
org.apache.jackrabbit.core.version.XAVersionManager.getItem(XAVersionManager.java:334)
at
org.apache.jackrabbit.core.version.AbstractVersionManager.getVersion(AbstractVersionManager.java:87)
at
org.apache.jackrabbit.core.NodeImpl.getBaseVersion(NodeImpl.java:3198)
at org.apache.jackrabbit.core.NodeImpl.checkout(NodeImpl.java:2991)
at
com.cerner.system.configuration.repository.jcr.SimpleJackrabbitConflictTest.testNullPointerExceptionThrown(SimpleJackrabbitConflictTest.java:96)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Request releases of RMI and commons libraries
Hi, On Wed, Mar 12, 2008 at 9:20 PM, Felix Meschberger [EMAIL PROTECTED] wrote: Would it be possible to get 1.4.1 releases of these libraries with (at least) the mentioned fixes backported to the 1.4 branch ? Sure, no problem. The only thing I'm wondering about is whether we should upgrade the component versions to 1.5, as your requirements go beyond strict bug fixes. However, I'm not sure if we're still at a point where everyone would feel comfortable going to a fully unsynchronized release process. But I'm fine releasing the updated components either as 1.4.1 or 1.5. Do you (or someone else) want to take a shot on managing the releases? I wouldn't mind doing it myself, but it would be good to make other people more familiar with the release process. BR, Jukka Zitting
Re: Repository BackUp and Restore
Hello, On Wed, Mar 12, 2008 at 1:55 PM, Joshna Reddy [EMAIL PROTECTED] wrote: Hi All I am working on Project Mirage (https://mirage.dev.java.net) which uses JackRabbit as content repository. I wanted to backup/restore the entire content when we migrate from one database to another. I have gone through some earlier mail threads and found about JECARS and JCR-Backup Tools. I have tried out JECARS , but it hangs indefinitely after exporting namespaces and nodetypes. Look's like it is hanging while exporting content. But there is not much content stored in my repository. Can you give me more information about the hanging perhaps the repository itself so that I can debug the problem? Greetings, Jacco -- - Jacco van Weert -- [EMAIL PROTECTED] JCR Controller -- http://www.xs4all.nl/~weertj/jcr JeCARS -- http://jecars.sourceforge.net
Re: Request releases of RMI and commons libraries
Hi, Am Mittwoch, den 12.03.2008, 23:06 +0200 schrieb Jukka Zitting: Hi, On Wed, Mar 12, 2008 at 9:20 PM, Felix Meschberger [EMAIL PROTECTED] wrote: Would it be possible to get 1.4.1 releases of these libraries with (at least) the mentioned fixes backported to the 1.4 branch ? Sure, no problem. Cool. The only thing I'm wondering about is whether we should upgrade the component versions to 1.5, as your requirements go beyond strict bug fixes. The pom extension of the jackrabbit-jcr-commons just adds some headers to the manifest file. No code changes. But right, this is not exactly bug fixing ... But I don't think this change warrants a minor version release, either. The JCR-1406 and JCR-1454 issues IMHO are real bug fixes as classes are missing, which should be there or a NullPointerException is to be prevented. However, I'm not sure if we're still at a point where everyone would feel comfortable going to a fully unsynchronized release process. But I'm fine releasing the updated components either as 1.4.1 or 1.5. Agreed, that is why, I proposed a minor release - also because I do not consider the changes justify for a minor release ... Do you (or someone else) want to take a shot on managing the releases? I wouldn't mind doing it myself, but it would be good to make other people more familiar with the release process. Sure, I can give it a try. Thanks and Regards Felix
[jira] Created: (JCR-1471) Error when registering nodetype with same propdef as supertype
Error when registering nodetype with same propdef as supertype
--
Key: JCR-1471
URL: https://issues.apache.org/jira/browse/JCR-1471
Project: Jackrabbit
Issue Type: Bug
Components: nodetype
Affects Versions: core 1.4.1, 1.4
Reporter: Tobias Bocanegra
Assignee: Tobias Bocanegra
error in check:
if (pd.getRequiredType() ==
epd.getRequiredType()
pd.isMultiple() == epd.isMultiple())
{
// conflict
String msg = The property definition for '
+ name + ' in node type '
+ def.getDeclaringNodeType()
+ ' conflicts with node type '
+ existingDef.getDeclaringNodeType()
+ ': ambiguous property
definition;
log.debug(msg);
throw new NodeTypeConflictException(msg);
}
if needs to be inverted.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1471) Error when registering nodetype with same propdef as supertype
[
https://issues.apache.org/jira/browse/JCR-1471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra resolved JCR-1471.
---
Resolution: Fixed
Fix Version/s: 1.5
fixed. candiate for backport to 1.4.2
Error when registering nodetype with same propdef as supertype
--
Key: JCR-1471
URL: https://issues.apache.org/jira/browse/JCR-1471
Project: Jackrabbit
Issue Type: Bug
Components: nodetype
Affects Versions: 1.4, core 1.4.1
Reporter: Tobias Bocanegra
Assignee: Tobias Bocanegra
Fix For: 1.5
error in check:
if (pd.getRequiredType() ==
epd.getRequiredType()
pd.isMultiple() ==
epd.isMultiple()) {
// conflict
String msg = The property definition for
'
+ name + ' in node type '
+ def.getDeclaringNodeType()
+ ' conflicts with node type '
+
existingDef.getDeclaringNodeType()
+ ': ambiguous property
definition;
log.debug(msg);
throw new NodeTypeConflictException(msg);
}
if needs to be inverted.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
