[jira] Reopened: (JCR-466) Modified values of REFERENCE property not stored correctly
[ http://issues.apache.org/jira/browse/JCR-466?page=all ]
Tobias Bocanegra reopened JCR-466:
--
reading david's comment, this probably only happens when referring to items in
the version storage.
btw: the patch does not fix this problem
Modified values of REFERENCE property not stored correctly
--
Key: JCR-466
URL: http://issues.apache.org/jira/browse/JCR-466
Project: Jackrabbit
Type: Bug
Components: core
Reporter: David Garcia
Assignee: Stefan Guggisberg
Attachments: VersionManagerImpl_patch.diff
Hi,
In a multi-valued property of type REFERENCE, when its values are changed
most of the references are lost upon save().
I can´t attach a test case, but here is what I´ve been able to test:
1. REFERENCE property has values [A, B] (A and B being node UUIDs).
2. A new reference (to node C) is appended to the array of values. New
value should be [A, B, C].
3. save().
4. Reopen session and reload.
5. New value is [C]. References to A and B are lost.
I´ve checked that the PersistenceManager gets a NodeReference object with
just one reference to node C, so the bug must be before the store().
I don´t know the internals of Jackrabbit, but I´ve found a possible source of
the problem in o.a.j.core.version.VersionManagerImpl#setNodeReferences().
When it filters out version storage references it also wipes out previous
references to A and B in the example above.
One thing that has worked for me is to remove the not (!) in the condition:
if (!hasItem(id.getParentId())) {
refs.addReference(id);
}
But now even version storage references are persisted (and this shouldn´t be
happening?).
Anyway, please check whether that solution is OK.
A patch file to change the condition is attached.
Thanks a lot.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Assigned: (JCR-466) Modified values of REFERENCE property not stored correctly
[ http://issues.apache.org/jira/browse/JCR-466?page=all ]
Tobias Bocanegra reassigned JCR-466:
Assign To: Tobias Bocanegra (was: Stefan Guggisberg)
Modified values of REFERENCE property not stored correctly
--
Key: JCR-466
URL: http://issues.apache.org/jira/browse/JCR-466
Project: Jackrabbit
Type: Bug
Components: core
Reporter: David Garcia
Assignee: Tobias Bocanegra
Attachments: VersionManagerImpl_patch.diff
Hi,
In a multi-valued property of type REFERENCE, when its values are changed
most of the references are lost upon save().
I can´t attach a test case, but here is what I´ve been able to test:
1. REFERENCE property has values [A, B] (A and B being node UUIDs).
2. A new reference (to node C) is appended to the array of values. New
value should be [A, B, C].
3. save().
4. Reopen session and reload.
5. New value is [C]. References to A and B are lost.
I´ve checked that the PersistenceManager gets a NodeReference object with
just one reference to node C, so the bug must be before the store().
I don´t know the internals of Jackrabbit, but I´ve found a possible source of
the problem in o.a.j.core.version.VersionManagerImpl#setNodeReferences().
When it filters out version storage references it also wipes out previous
references to A and B in the example above.
One thing that has worked for me is to remove the not (!) in the condition:
if (!hasItem(id.getParentId())) {
refs.addReference(id);
}
But now even version storage references are persisted (and this shouldn´t be
happening?).
Anyway, please check whether that solution is OK.
A patch file to change the condition is attached.
Thanks a lot.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Strange exception: javax.jcr.ItemNotFoundException: d1a479a0-b822-43a3-8181-9380635fb02a
Hello,
I'm adding recursively nodes, but this leads to exception occasionally:
javax.jcr.ItemNotFoundException: d1a479a0-b822-43a3-8181-9380635fb02a
at
org.apache.jackrabbit.core.ItemManager.createItemInstance(ItemManager.java:464)
at org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:320)
at
org.apache.jackrabbit.core.NodeImpl.internalAddChildNode(NodeImpl.java:794)
at
org.apache.jackrabbit.core.NodeImpl.internalAddNode(NodeImpl.java:738)
at
org.apache.jackrabbit.core.NodeImpl.internalAddNode(NodeImpl.java:685)
at org.apache.jackrabbit.core.NodeImpl.addNode(NodeImpl.java:1772)
at
cz.aura.cms.preferences.impl.PreferencesServiceImpl.addRecursively(PreferencesServiceImpl.java:195)
My code is:
for (int i = 0; i nodeNames.length; i++) {
relPath = nodeNames[i];
if (workNode.hasNode(relPath) == false) {
Node node = workNode.addNode(relPath);
workNode = node;
} else {
workNode = workNode.getNode(relPath);
}
}
Unfortunately this behaviour is not reproducible with test and come on
accidentally.
Thanks,
Martin
[jira] Commented: (JCR-388) add support for RFC 3253 to the simple server
[ http://issues.apache.org/jira/browse/JCR-388?page=comments#action_12416742 ] angela commented on JCR-388: regarding your questions: a) the factory should take care of building the proper resource instances. thus: version, versionhistory specific object if the request points to such a resource. b) instead of 'addHrefProperty' i would create a method that simply builds such an HrefProperty. adding it to the property-set would be left to the caller. c) you have an error in the code while building the href. you only copied the code from the jcr-server without understanding that the simple server works differently. in jcr-server a jcr-node represents a webdav collection, which does not apply to the simple server. d) the factory is an interface that returns 'DavResource' upon a call to the create methods. since its an interface one could replace it by a different implementation. hope that helps. add support for RFC 3253 to the simple server - Key: JCR-388 URL: http://issues.apache.org/jira/browse/JCR-388 Project: Jackrabbit Type: New Feature Components: webdav Versions: 0.9 Reporter: jeremi Joslin Assignee: angela Priority: Minor Attachments: Review.txt, patch_rfc3253.zip, rfc.zip http://www.ietf.org/rfc/rfc3253.txt -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Questions about versioning
hi paco, please note, that versioning has nothing to do with locking. - If the user A performs a Checkout, why can user B modify and checkin? becauses it's not locking - Do the A user have to lock himself the node? yes. - If the user B can modify and perform a checkin, what happends if meanwhile user A modify the node? In my test, the last modification (user A) is versioned, and the user B modification (performed before user A modification) is lost. Is this ok? yes. So, if all these is fine I have to do something like this: - User A lock node - User A performs checkout - User A modify node - User A performs checkin - User A unlock node isn't it? correct. if you don't want to use locking, you can create several workspaces for you users. for example workspace A for user A, and workspace B for user B: - User A logs into workspace A - User B logs into workspace B - A does a checkout of Node N - B does a checkout of Node N - A modifies N and does checkin - version 1.1 - B modifies N and does checkin - version 1.0.1 (new branch, since 1.1 already exists) hope this helps. regards, toby -- - [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 ---
Re: Questions about versioning
El lun, 19-06-2006 a las 13:45 +0200, Tobias Bocanegra escribió: So, if all these is fine I have to do something like this: - User A lock node - User A performs checkout - User A modify node - User A performs checkin - User A unlock node isn't it? correct. if you don't want to use locking, you can create several workspaces for you users. for example workspace A for user A, and workspace B for user B: - User A logs into workspace A - User B logs into workspace B - A does a checkout of Node N - B does a checkout of Node N - A modifies N and does checkin - version 1.1 - B modifies N and does checkin - version 1.0.1 (new branch, since 1.1 already exists) It sounds very interesting, but just locking is fine for now :) Thanks! -- Paco Avila [EMAIL PROTECTED]
Unable to lock node. Node has pending changes: /counter
I get this with the following code;
/* setup, run only once */
Node root = session.getRootNode();
Node counter = null;
try {
counter = (Node) session.getItem(/counter);
} catch (javax.jcr.RepositoryException re) {
log.debug(repository is empty, setting up default nodes);
counter = null;
}
if (counter == null) {
counter = root.addNode(counter);
counter.addMixin(mix:lockable);
counter.setProperty(value, 0);
session.save();
}
/* sequence fetcher */
public int generateNewResourceId()
throws UnsupportedOperationException {
try {
Node counter = (Node) session.getItem(/counter);
long nextValue = ((Long) new Locked() {
protected Object run(Node counter) throws
javax.jcr.RepositoryException {
Property seqProp = counter.getProperty(value);
long value = seqProp.getLong();
seqProp.setValue(++value);
seqProp.save();
return new Long(value);
}
}.with(counter, false)).longValue();
log.debug(sequence value: + nextValue);
} catch (Exception e) {
log.error(unable to get new resource id; , e);
}
return -1;
}
All this is with derby DB, jackrabbit 1.01, and the Locked.java code
from current svn (as of today).
Any clues why I'm getting the following exception?
13:13:19,476 ERROR JackrabbitRepositoryDAO - unable to get new resource
id;
javax.jcr.InvalidItemStateException: Unable to lock node. Node has
pending changes: /counter
at org.apache.jackrabbit.core.NodeImpl.lock(NodeImpl.java:3910)
at org.apache.jackrabbit.util.Locked.tryLock(Locked.java:251)
at org.apache.jackrabbit.util.Locked.with(Locked.java:145)
at org.apache.jackrabbit.util.Locked.with(Locked.java:103)
at
com.netenviron.repository.dao.jackrabbit.JackrabbitRepositoryDAO.generateNewResourceId(JackrabbitRepositoryDAO.java:293)
at
com.netenviron.repository.RepositoryManager.generateNewResourceId(RepositoryManager.java:164)
at com.netenviron.repository.Resource.init(Resource.java:58)
at
com.netenviron.repository.dao.jackrabbit.JackrabbitRepositoryDAO.getResource(JackrabbitRepositoryDAO.java:521)
--
Torgeir Veimo [EMAIL PROTECTED]
Re: Unable to lock node. Node has pending changes: /counter
On Mon, 2006-06-19 at 14:47 +0200, Marcel Reutegger wrote: There are two reason why this can happen (as far as I can see): - the session actually did modify the node /counter before calling generateNewResourceId(), thus it cannot lock the node or - a previous call to generateNewResourceId() failed in the Locked.run() method, leaving unsaved changes. The Locked utility does not automatically revert changes in case of an exception thrown by Locked.run(). That's the responsibility of the caller, because only he knows what is actually done in Locked.run(). The code you provided only shows the Locked.run() method, but does not include a test case that shows how and when generateNewResourceId() is called. Do you have a simple test that reproduces the InvalidItemStateException? Hmm, it's a bit difficult as I'd have to rip it out of the framework.. I'll put something simple together. One other question: does this happen always or only sporadically? It happens all the time. Would it be correct to call refresh(false) on the counter node in case of an exception? I only ever modify the value property when the node is created and in the generateNewResourceId() method. -- Torgeir Veimo [EMAIL PROTECTED]
Jackrabbit Authentication/Authorization
Dear All, Any one of you have implemented Authentication/Authorization mechanism using JAAS for jackrabbit repository ?? Otherwise, any sample for SimpleAccessManager and SimpleLoginModule ?? Please let us know, if there is any documents or samples available.!!! Thanks in advance. Regards, Shan _ NRIs: Still paying for money transfers? Now send Money2India for FREE! http://ads.mediaturf.net/event.ng/Type=clickFlightID=20273AdID=65990TargetID=11172Targets=11172Values=202,414,1093,1264,3122Redirect=http:%2F%2Fwww.icicinri.net%2Fmoney2india%2F%3Fm2i%3DBAC-MSN%26att%3DMSNTLM2I70CHAR%26rfr%3DMSNTLM2I70CHAR
[jira] Commented: (JCR-459) Add JMX support to register a JCR RMI Server into Jboss
[ http://issues.apache.org/jira/browse/JCR-459?page=comments#action_12416795 ] Jukka Zitting commented on JCR-459: --- Thanks, feel free to commit the changes in svn. I was actually thinking of setting the properties of the local JNDI context, i.e. so that you could access some other naming tree than the default one in your container. Something like this: String localAddress = ...; Hashtable localEnvironment = ...; String targetAddress = ...; Hashtable targetEnvironment = ...; InitialContext localContext = new InitialContext(localEnvironment); Repository repository = (Repository) local.lookup(localAddress); RemoteAdapterFactory factory = new ServerAdapterFactory(); RemoteRepository remote = factory.getRemoteRepository(repository); InitialContext targetContext = new InitialContext(targetEnvironment); targetContext.bind(targetAddress, remote); Add JMX support to register a JCR RMI Server into Jboss --- Key: JCR-459 URL: http://issues.apache.org/jira/browse/JCR-459 Project: Jackrabbit Type: Improvement Components: rmi Reporter: Edgar Poce Priority: Minor Attachments: 20060616-jcr-rmi-jmx.diff, jcr-rmi-jmx.diff I added two classes and one descriptor file to the jcr-rmi project. These files provide support to make the generated jar deployable into a Jboss server. The deployment descriptor contains two parameters, the address of the local repository instance, and the target address where the rmi server should be registered. e.g. server mbean code=org.apache.jackrabbit.rmi.server.jmx.JCRServer name=Jackrabbit.services:RMIServer = JCR RMI Server attribute name=Localjava:jcr/local/attribute attribute name=Targetjnp://localhost:1099/jcrServer/attribute dependsjboss.jca:service=ManagedConnectionFactory,name=jcr/local/depends /mbean /server this configuration registers an RMI server at /jcrServer that wraps the local repository at java:jcr/local. br, Edgar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (JCR-459) Add JMX support to register a JCR RMI Server into Jboss
[ http://issues.apache.org/jira/browse/JCR-459?page=all ] Edgar Poce reassigned JCR-459: -- Assign To: Edgar Poce Add JMX support to register a JCR RMI Server into Jboss --- Key: JCR-459 URL: http://issues.apache.org/jira/browse/JCR-459 Project: Jackrabbit Type: Improvement Components: rmi Reporter: Edgar Poce Assignee: Edgar Poce Priority: Minor Attachments: 20060616-jcr-rmi-jmx.diff, jcr-rmi-jmx.diff I added two classes and one descriptor file to the jcr-rmi project. These files provide support to make the generated jar deployable into a Jboss server. The deployment descriptor contains two parameters, the address of the local repository instance, and the target address where the rmi server should be registered. e.g. server mbean code=org.apache.jackrabbit.rmi.server.jmx.JCRServer name=Jackrabbit.services:RMIServer = JCR RMI Server attribute name=Localjava:jcr/local/attribute attribute name=Targetjnp://localhost:1099/jcrServer/attribute dependsjboss.jca:service=ManagedConnectionFactory,name=jcr/local/depends /mbean /server this configuration registers an RMI server at /jcrServer that wraps the local repository at java:jcr/local. br, Edgar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Multivalue or single?
If I have a node, the name of a property and a single value, how can I determine if I need to add the value to an array and use the multivalue setter or not? Using getProperty(propertyName).getDefinition().isMultiple() won't work since the property may not exist (it was set to null...PathNotFoundException). Invoking setProperty(propertyName, value) and catching the ValueFormatException doesn't work since you don't know if the exception came from the property being multivalued or from a conversion error. Iterating over the propertyDefinitions from the nodetype (and mixins) isn't efficient. What's the recommended way to determine whether to use the multivalue or single value setProperty method? David
Re: Multivalue or single?
The only solution to your problem would be to have some metadata info about them, and so you could look if the property was single or multivalued. Obviously the real problem is how to find if a property is single/multiple if such property does not exist so I cannot agree more with Jukka. Having a getPropertyDefinition method would be really nice. Martin On 6/19/06, Jukka Zitting [EMAIL PROTECTED] wrote: Hi, On 6/20/06, David Kennedy [EMAIL PROTECTED] wrote: If I have a node, the name of a property and a single value, how can I determine if I need to add the value to an array and use the multivalue setter or not? Good question. Perhaps we should add something like a getPropertyDefinition(String name) method to a JackrabbitNode extension interface. This might also be a good suggestion to JSR 283 unless someone has a better idea. BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] Software craftsmanship, JCR consulting, and Java development
