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, . 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 . 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.
RE: query feature extensions
Hi Marcel, > -Original Message- > From: Marcel Reutegger [mailto:[EMAIL PROTECTED] > Sent: Monday, April 03, 2006 3:13 AM > To: dev@jackrabbit.apache.org > Subject: query feature extensions > > Jackrabbit currently supports a limited set of XPath > features, basically the mandatory feature set as specified by > jsr-170 plus some extended capability where predicates can stated. > > I would like to invite everyone (or at least whoever is > interested...) to put together a list of 3 query features > that are missing the most in jsr-170/jackrabbit regarding > XPath support. Of course you may post a longer list but I'm > primarily interested in getting a feeling where the priorities are. > +1 on all the features mentioned (although from a personal standpoint I would value (3) over (2) w.r.t priority). Out of curiosity, would the features need to be delayed until JSR-283 solidifies further or could work begin earlier (assuming available time for you/other contributors of course)? Best Regards, -- Mike NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.
RE: Xpath "or queries"
Hi Alex, Thanks for the reply. Actually, I am not quite sure if the spec quote reads in the way you've described but that actually is a separate issue here (although clarification on the interpretation of the spec quote would also be appreciated). The same result occurs with any expressions in the or clause (e.g. /jcr:root/foo or /jcr:root/bar). Best Regards, -- Mike > -Original Message- > From: Alexandru Popescu [mailto:[EMAIL PROTECTED] > Sent: Friday, March 31, 2006 8:07 PM > To: dev@jackrabbit.apache.org > Subject: Re: Xpath "or queries" > > According to 6.6.3.2 Type constraint: > > [quote] > Implementations are required to support constraints of one > primary type. It is optional to support constraints based on > multiple primary node types (this would, in any case, only be > applicable to implementations that supported multiple > inheritance of node types). It is also optional to support > constraints on (one or more) mixin node types. > [/quote] > > so I would say that only the 1st form is guaranteed to work. > > hth, > > ./alex > -- > .w( the_mindstorm )p. > > > On 4/1/06, Daglian, Michael (IT) > <[EMAIL PROTECTED]> wrote: > > Hi everyone, > > > > I was wondering what the proper syntax is for executing or > statements > > within an xpath query. According to the spec something like the > > following should be possible (although totally contrived in > this case): > > > > //element(*, nt:file) or //element(*, mix:lockable) > > > > However, this throws a ClassCastException in the > XPathQueryBuilder on > > line 322 (it appears that in the invocation of the visit method the > > SimpleNode id indicates a type of JJTROOTDESCENDANTS at a certain > > point but the data is actually an OrQueryNode and hence the > cast to a > > PathQueryNode fails). I am using the 0.9 release currently. > Apologies > > if this question was previously discussed or fixed in a > post 0.9 candidate. > > Thanks! > > > > Best Regards, > > > > -- Mike > > > > > > NOTICE: If received in error, please destroy and notify > sender. Sender does not waive confidentiality or privilege, > and use is prohibited. > > > NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.
Xpath "or queries"
Hi everyone, I was wondering what the proper syntax is for executing or statements within an xpath query. According to the spec something like the following should be possible (although totally contrived in this case): //element(*, nt:file) or //element(*, mix:lockable) However, this throws a ClassCastException in the XPathQueryBuilder on line 322 (it appears that in the invocation of the visit method the SimpleNode id indicates a type of JJTROOTDESCENDANTS at a certain point but the data is actually an OrQueryNode and hence the cast to a PathQueryNode fails). I am using the 0.9 release currently. Apologies if this question was previously discussed or fixed in a post 0.9 candidate. Thanks! Best Regards, -- Mike NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.
