Initializing VersionHistories inside transactions
Hi all, Not too bring up an issue that's been discussed on the lists before but I had a question about the ability to performed versioned operations inside of a transaction. Apologies if the existing JIRA items cover this but the Apache JIRA site seems to be down right now. It mainly concerns resource ordering inside the transaction w.r.t. the XAVersionManager (in release 1.1). Let me briefly describe our scenario: we have a simple JTA-like transaction module that treats each session on a different workspace accessed by a user as a single XA resource (i.e. as they modify nodes in multiple workspaces, each XASession is enlisted into a transaction that is managed as a single unit). Since the sessions each have their own XAVersionManager then, upon prepare, a StateItemStateException on the jcr:versionStorage root is thrown when versionable nodes from different workspaces have their version histories initialized. More specifically, this occurs during prepare of the second session as the modCount of the ItemState has increased to 1 (as expected) during the prepare of the first. We tried a workaround with a custom XAVersionManager that only performed transactional operations once (i.e. all sessions in the transaction shared a single XAVersionManager instance). This worked around the stale state problem but introduced a new issue on some removes (and here my knowledge of the versioning system proved a limitation). Basically, my question is it possible to achieve what the above describes (version operations on different workspaces for the same user in a single transaction)? JCA isn't an option for us (though I am not sure if it would help with this problem). Thanks! Best Regards, -- Mike NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.
Query on node name
Hi everyone, I know that this question has been asked before and that the very reasonable answer is that the JCR 1.0 spec does not prescribe support for querying based upon the node name in a path. However, a message from February by Marcel (http://www.mail-archive.com/jackrabbit-dev@incubator.apache.org/msg0472 4.html) seems to imply a Jackrabbit-specific extension that added support for this feature. Unfortunately I was unable to reproduce successful matching following the example contained in the message. So I have a couple of other questions: 1. Does search on node name still exist as a Jackrabbit extension? (it very well might and my test case is wrong!) 2. If not, would the following be a reasonable method for adding this support (at least partially) specifically to a local build (which is able to constrain usage): a) Modify org.apache.jackrabbit.core.query.lucene.NodeIndexer#createDoc to add the following line: doc.add(new Field(FieldNames.FULLTEXT, name, false, true, true)); where name is the name calculated for all child nodes. Our usage would allow us to subsequently filter out those nodes that do not actually match based upon node name but rather another property value. A preferred alternative for us would be to have a property created that only exists in a non-public namespace to allow us to not have to post-process the results but I could not figure out how to make this work (advice would be most appreciated :) ). The solution above certainly represents a quick-fix and I have not had the opportunity to assess the potential ramifications. However, there is definitely a need on our end for this feature before JSR-283 adds jcr:local-name() support. Thanks in advance! -- Mike NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.
RE: can't Import a system view using ImportXML
Hello Nicolas,
This is expected behavior and has come up previously. Please see
http://issues.apache.org/jira/browse/JCR-323?page=all for Stefan's
explanation and suggested workaround (which I am not sure applies to the
use case of the backup tool of course). Hope that helps!
Best Regards,
-- Mike
-Original Message-
From: Nicolas [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 08, 2006 9:32 AM
To: dev@jackrabbit.apache.org
Subject: can't Import a system view using ImportXML
Hi,
When I try to import a whole workspace, here is the exception thrown:
/jcr:root: mandatory child node
{http://www.jcp.org/jcr/1.0}system does not exist. I don't
understand why it happens and how to correct it: the root
node has children...
Do you have any idea?
Thanks a lot,
Nico
my blog! http://www.deviant-abstraction.net !!
NOTICE: If received in error, please destroy and notify sender. Sender does not
intend to waive confidentiality or privilege. Use of this email is prohibited
when received in error.
RE: Simple queries failing
Hi David, If you check out the JCR spec in section 6.6.4.3 (Context Node) it says that every Xpath query must start with the pseudo-root context node named jcr:root. To quote: The context node of an XPath query is the XML node relative to which the query expression is evaluated. A relative XPath statement (one that does not have a leading /) will be interpreted relative to the root node of the workspace, which, in the XML document view is the top-most XML element, jcr:root. This means that one should not include jcr:root as the first segment in a relative XPath statement, since that element is already the default context node. An absolute XPath (one with a leading /), in contrast, will be interpreted relative to a position one level above jcr:root. This means that an absolute XPath must either begin with // or with /jcr:root in order to match anything at all. Hope that helps, -- Mike -Original Message- From: David Kennedy [mailto:[EMAIL PROTECTED] Sent: Thursday, April 27, 2006 3:11 PM To: dev@jackrabbit.apache.org Subject: Simple queries failing I am trying to execute very simple queries using the default repository setup and the queries are failing: Here is how I'm getting the QueryManager and executing the query String statement = /Perf; QueryManager queryManager = (QueryManager)workspace.getQueryManager(); Query query = queryManager.createQuery(statement, Query.XPATH); QueryResult qResult = query.execute(); NodeIterator iter = qResult.getNodes(); System.out.println(Query = + statement + #hits = + iter.getSize()); The iterator size is always 0. My hierarchy starts with /Perf and there are many nodes below Perf. I have a repository explorer that displays the hierarchy and confirms the nodes are there. Is there something I'm missing? Where would you begin to debug this? I've traced it to the LuceneQueryBuilder, but haven't gone much further. How can I determine what's in the indices? David NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.
