You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Jack Kirsten <jk...@hotmail.com> on 2011/07/05 21:34:41 UTC
Strange XPath Issue
Hi, I'm relatively new to Jackrabbit. In our application we never turned on
SearchIndex section within repository.xml (so as workspace.xml) files
because we always go directly to a given document using the JCR UUID
reference. By the way we use *Jackrabbit v2.2.1* and *Oracle* as the
repository. Now our requirements are getting expanded as we would like to
use the document metadata feature to store contextual info about a document
so that we can use the metadata to retrieve a selected set of documents.
As the first step, I added the default SearchIndex section in workspace.xml
file and restarted the JCR.
I saw a bunch of lines like this in my log file - then I saw it created the
*index* folder under workspace area.
*2011-07-05 15:04:01.724 INFO [WebContainer : 0] MultiIndex.java:1204
indexing...
/vfs:metaData/21ee130e-978e-415f-bfd1-7aa03d91608c/vfs:attributes (3500)*
I have the folder structure like this. When I create a document in JCR, I
specify the metadata info as part of the document which is by a complex XSD
type with tags like docType, uploadedBy, contextValue, etc.
/ (root)
/MyApp (sub-folder)
/documents/ (sub-folder)
/document-1.pdf (file)
/document-2.pdf (file)
/accounts/ (sub-folder)
/account.txt (file)
etc...
The following XPath expression works.
*//jcr:root/vfs:metaData//*[vfs:attributes/vfs:docType='TAX_DOCS']*
If I give wrong value, for example instead of 'TAX_DOCS', 'TAX', it returns
no documents as expected which is great. This proves that the metadata is
correctly stored as expected and it is used in the filter process correctly.
The problem with this query is that it starts searching from the root folder
but I want to search from /MyApp/documents sub-folder only. So I tried
this:
*//jcr:root/MyApp/documents//vfs:metaData//*[vfs:attributes/vfs:docType='TAX_DOCS']*
It returns nothing. Then I tried this too but no success.
*//jcr:root/MyApp/documents//*[vfs:metaData/vfs:attributes/vfs:docType='TAX_DOCS']*
So what am I doing wrong? Is anything in workspace.xml configuration that
we need to set or missing?
Any help is appreciated.
Thanks, Jack
--
View this message in context: http://jackrabbit.510166.n4.nabble.com/Strange-XPath-Issue-tp3646893p3646893.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: Strange XPath Issue
Posted by Alexander Klimetschek <ak...@adobe.com>.
As I said, I don't know of any such thing in Jackrabbit. Looking at
http://www.google.de/search?q=vfs:metaData it looks like some kind of
"virtual file system", mapping a file system on top of JCR. But you should
know what runs on your stack on top of the JCR :-)
Maybe the repository.xml uses a custom search index implementation or
custom modules related to that vfs thing (that's why it was created after
enabling the search index)? The standard Jackrabbit SearchIndex is lucene
based and does not alter the repository contents in any way, it stores the
lucene index separately on the file system.
Cheers,
Alex
On 08.07.11 16:14, "Jack Kirsten" <jk...@hotmail.com> wrote:
>Thanks Alex for replying.
>
>Well the vfs:metaData folder was not there before. It was created
>automatically when I enabled SearchIndex section within workspace.xml
>file.
>Before that it wasn't there. As the SearchIndex section was enabled, it
>indexed all nodes in the repository and that's when vfs:metaData folder
>was
>created.
>
>So the document metadata info (vfs:metaData) typically get created in the
>root level? How does it look in your application or your repository?
>Could
>you please check?
>
>Thanks again for replying.
>
>--
>View this message in context:
>http://jackrabbit.510166.n4.nabble.com/Strange-XPath-Issue-tp3646893p36542
>12.html
>Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>
--
Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel
Re: Strange XPath Issue
Posted by Jack Kirsten <jk...@hotmail.com>.
Thanks Alex for replying.
Well the vfs:metaData folder was not there before. It was created
automatically when I enabled SearchIndex section within workspace.xml file.
Before that it wasn't there. As the SearchIndex section was enabled, it
indexed all nodes in the repository and that's when vfs:metaData folder was
created.
So the document metadata info (vfs:metaData) typically get created in the
root level? How does it look in your application or your repository? Could
you please check?
Thanks again for replying.
--
View this message in context: http://jackrabbit.510166.n4.nabble.com/Strange-XPath-Issue-tp3646893p3654212.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: Strange XPath Issue
Posted by Alexander Klimetschek <ak...@adobe.com>.
On 08.07.11 15:03, "Jack Kirsten" <jk...@hotmail.com> wrote:
>As I was browsing the repository, I noticed that vfs:metaData folder is
>actually at the root level of the repository. So it is something like
>this:
>
>/ (root)
> /vfs:metaData/
> /<some JCR uuid>
> /vfs:attributes/
> etc....
>
> /MyApp (sub-folder)
> /documents/ (sub-folder)
> /document-1.pdf (file)
> /document-2.pdf (file)
> /accounts/ (sub-folder)
> /account.txt (file)
>
>So I'm thinking for some reason, Jackrabbit decided to make the metadata
>folder structure under root as opposed to making it as part of the
>document
>node itself. That's why this XPath query works for me because it looks
>from
>the root.
>
>*/jcr:root/vfs:metaData//*[vfs:attributes/vfs:docType='TAX_DOCS']*
>...
>1) Is it possible to configure Jackrabbit to create the metadata folder
>under individual document level itself?
What creates the vfs:metaData in the first place? There is no such node
types or code in Jackrabbit that I know of - this looks like your
application is creating/importing this structure, right?
Regards,
Alex
--
Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel
Re: Strange XPath Issue
Posted by Jack Kirsten <jk...@hotmail.com>.
I want to update everyone with what I found. Though the XPath expression is
valid, for some reasons it is not working for me. Then I installed
Jackrabbit Web-App and followed by JCR Browser (freeware) pointing to the
Jackrabbit WEBDAV URL so that I can browse the contents of the repository
directly. This tool has XPath query option as well.
As I was browsing the repository, I noticed that vfs:metaData folder is
actually at the root level of the repository. So it is something like this:
/ (root)
/vfs:metaData/
/<some JCR uuid>
/vfs:attributes/
etc....
/MyApp (sub-folder)
/documents/ (sub-folder)
/document-1.pdf (file)
/document-2.pdf (file)
/accounts/ (sub-folder)
/account.txt (file)
So I'm thinking for some reason, Jackrabbit decided to make the metadata
folder structure under root as opposed to making it as part of the document
node itself. That's why this XPath query works for me because it looks from
the root.
*/jcr:root/vfs:metaData//*[vfs:attributes/vfs:docType='TAX_DOCS']*
However this query doesn't return anything because vfs:metaData is NOT
inside the sub-folders.
*/jcr:root/MyApp/documents/vfs:metaData//*[vfs:attributes/vfs:docType='TAX_DOCS']*
So at this point I have these questions:
1) Is it possible to configure Jackrabbit to create the metadata folder
under individual document level itself?
OR
2) This is how Jackrabbit maintains the metadata info by default?
Can anyone please shed a light on this?
Thanks, Jack
--
View this message in context: http://jackrabbit.510166.n4.nabble.com/Strange-XPath-Issue-tp3646893p3654038.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: Strange XPath Issue
Posted by Alexander Klimetschek <ak...@adobe.com>.
On 05.07.11 22:31, "Jack Kirsten" <jk...@hotmail.com> wrote:
>Thanks for your reply Jeroen, I just tried this query as you suggested:
>
>*MyApp/documents//*[vfs:metaData/vfs:attributes/vfs:docType='TAX_DOCS']*
If you start with an absolute path (e.g. not //*), it needs to start with
"/jcr:root":
/jcr:root/MyApp/documents//*[vfs:metaData/vfs:attributes/vfs:docType='TAX_D
OCS']
This is because of the implicit mapping onto the xml document view of the
repository, which requires to add an explicit xml element for the root
node called "jcr:root" [0]. See also [1].
[0] http://www.day.com/specs/jcr/1.0/6.4.2.2_Workspace_Root.html
[1] http://www.day.com/specs/jcr/1.0/6.6.3.4_Path_Constraint.html
Regards,
Alex
--
Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel
Re: Strange XPath Issue
Posted by Jack Kirsten <jk...@hotmail.com>.
Thanks for your reply Jeroen, I just tried this query as you suggested:
*MyApp/documents//*[vfs:metaData/vfs:attributes/vfs:docType='TAX_DOCS']*
But still the same effect - no documents found.
--
View this message in context: http://jackrabbit.510166.n4.nabble.com/Strange-XPath-Issue-tp3646893p3647040.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: Strange XPath Issue
Posted by Jeroen Reijn <j....@onehippo.com>.
Hi Jack,
see my comments inline.
On Tue, Jul 5, 2011 at 9:34 PM, Jack Kirsten <jk...@hotmail.com> wrote:
> Hi, I'm relatively new to Jackrabbit. In our application we never turned on
> SearchIndex section within repository.xml (so as workspace.xml) files
> because we always go directly to a given document using the JCR UUID
> reference. By the way we use *Jackrabbit v2.2.1* and *Oracle* as the
> repository. Now our requirements are getting expanded as we would like to
> use the document metadata feature to store contextual info about a document
> so that we can use the metadata to retrieve a selected set of documents.
>
> As the first step, I added the default SearchIndex section in workspace.xml
> file and restarted the JCR.
>
> I saw a bunch of lines like this in my log file - then I saw it created the
> *index* folder under workspace area.
>
> *2011-07-05 15:04:01.724 INFO [WebContainer : 0] MultiIndex.java:1204
> indexing...
> /vfs:metaData/21ee130e-978e-415f-bfd1-7aa03d91608c/vfs:attributes (3500)*
>
> I have the folder structure like this. When I create a document in JCR, I
> specify the metadata info as part of the document which is by a complex XSD
> type with tags like docType, uploadedBy, contextValue, etc.
>
> / (root)
> /MyApp (sub-folder)
> /documents/ (sub-folder)
> /document-1.pdf (file)
> /document-2.pdf (file)
> /accounts/ (sub-folder)
> /account.txt (file)
> etc...
>
> The following XPath expression works.
>
> *//jcr:root/vfs:metaData//*[vfs:attributes/vfs:docType='TAX_DOCS']*
>
> If I give wrong value, for example instead of 'TAX_DOCS', 'TAX', it returns
> no documents as expected which is great. This proves that the metadata is
> correctly stored as expected and it is used in the filter process correctly.
>
> The problem with this query is that it starts searching from the root folder
> but I want to search from /MyApp/documents sub-folder only. So I tried
> this:
>
> *//jcr:root/MyApp/documents//vfs:metaData//*[vfs:attributes/vfs:docType='TAX_DOCS']*
>
> It returns nothing. Then I tried this too but no success.
>
> *//jcr:root/MyApp/documents//*[vfs:metaData/vfs:attributes/vfs:docType='TAX_DOCS']*
Maybe you could try:
MyApp/documents//*[vfs:metaData/vfs:attributes/vfs:docType='TAX_DOCS']*
I don't think you need to use the *//jcr:root . It should be fine that
it's a relative location.
>
> So what am I doing wrong? Is anything in workspace.xml configuration that
> we need to set or missing?
No as far as I know it's not necessary to do that. You should be able
to just use a query.
>
> Any help is appreciated.
>
> Thanks, Jack
>
> --
> View this message in context: http://jackrabbit.510166.n4.nabble.com/Strange-XPath-Issue-tp3646893p3646893.html
> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>