You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Rod Mackenzie (JIRA)" <ji...@apache.org> on 2005/02/16 11:50:46 UTC
[jira] Created: (JCR-48) XMLPersistenceManager trims string property values
XMLPersistenceManager trims string property values
--------------------------------------------------
Key: JCR-48
URL: http://issues.apache.org/jira/browse/JCR-48
Project: Jackrabbit
Type: Bug
Environment: Jackrabbit 154013
Reporter: Rod Mackenzie
Priority: Minor
The XMLPersistenceManager trims the text of property values read in, so what's returned doesn't match the value set if it included whitespace at the start or end.
--
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
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
Re: Query language issues
Posted by Ben Pickering <be...@gmail.com>.
I think it would be nice to have the path expressions as first-class
constructs in the syntax, even if this does involve moving away from
the SQL syntax...
After all, it is a tree rather than a database being queried.
--
Cheers,
Ben
On Fri, 18 Feb 2005 09:39:18 +0100, Marcel Reutegger
<ma...@gmx.net> wrote:
> Hi Timur,
>
> Timur Evdokimov wrote:
> > Before, I've been able to write something like
> > SELECT * FROM my:article LOCATION /texts//* WHERE
> > my:includeInMainStream='true' ORDER BY my:publishingDate DESCENDING
> > and select 20 latest nodes from NodeIterator
> >
> > Now, in 0.16, it seems like it's more like standard SQL without LOCATION
> > clause
> > So I can't say LOCATION /texts//* anymore, and forced to do something like
> > jcr:path LIKE '/texts/%' which yields only direct children of /texts, but
> > not their descendants! And (jcr:path LIKE '/texts/%') OR (jcr:path LIKE
> > '/texts/%/%') OR (jcr:path LIKE '/texts/%/%/%') could possibly work (though
> > it looks somewhat stupid) but it doesn't work at all (bug in RI?)
>
> Yes, that's definitively a bug in jackrabbit. jcr:path LIKE '/texts/%'
> should select descendants of /text and not just its children.
> I've created a JIRA issue: http://issues.apache.org/jira/browse/JCR-49
>
> > Another option seem to be XPath query with
> > /texts//*[@my:includeInMainStream='true']... but then I'd lose my rather
> > important ORDER BY my:publishingDate!
> > Pardon my ignorance, maybe there's better way to write this query?
>
> The XPath variant JSR-170 uses, allows you to specify an order by
> clause. So, you can write:
> /texts//*[@my:includeInMainStream='true'] order by @my:publishingDate
> descending
>
> > And I don't feel quite like that jcr:path LIKE xxxxxx thing is something
> > that deserves to be there.
> > Maybe it should be at least allowed to be something like jcr:path LIKE
> > jcrf:xpath('/texts//*'), or I don't know what...
>
> yes, that would be another way. The goal was not to introduce too many
> new constructs, but use what standard SQL provides. Either way has its
> pros and cons...
>
> regards
> marcel
>
RE: Query language issues
Posted by Timur Evdokimov <ti...@jacum.com>.
Thank you for these clarifications about /jcr:root, it was not quite obvious
(and apparently was recent addition)
Now everything works as it should, even with ordering.
Regards,
Timur
-----Original Message-----
From: Marcel Reutegger [mailto:marcel.reutegger@gmx.net]
Sent: Monday, February 21, 2005 10:20 AM
To: jackrabbit-dev@incubator.apache.org
Subject: Re: Query language issues
Hi Timur,
> In //*[@my:includeInMainStream='true'] order by @my:publishingDate
> descending It complains about @ in @my:publishingDate clause So that
> only order by publishingDate is accepted, but doesn't work anyway
hmm, works fine for me. Could you please create a jira bug with instructions
how to reproduce it? Thanks
> Also any expression apart from //* returns nothing, i.e. just /text//*
> gives 0 hits, whereas SELECT * FROM my:article WHERE jcr:path LIKE
> '/text/%' gives what it supposed to give.
XPath uses a virtual XML document refered to as document view mapping in the
jsr 170 spec. Because the root element in that document is the root node of
the workspace any absolute XPath must start with /jcr:root. In your case
that would be something like:
/jcr:root/text//*[@my:includeInMainStream='true']
You may also use a relative XPath. In that case the context for the query is
the root node of the workspace:
text//*[@my:includeInMainStream='true']
Relevant section in the spec is: 6.6.3.3
regards
Marcel
Re: Query language issues
Posted by Marcel Reutegger <ma...@gmx.net>.
Hi Timur,
> In //*[@my:includeInMainStream='true'] order by @my:publishingDate
> descending
> It complains about @ in @my:publishingDate clause
> So that only order by publishingDate is accepted, but doesn't work anyway
hmm, works fine for me. Could you please create a jira bug with
instructions how to reproduce it? Thanks
> Also any expression apart from //* returns nothing, i.e. just /text//* gives
> 0 hits, whereas
> SELECT * FROM my:article WHERE jcr:path LIKE '/text/%' gives what it
> supposed to give.
XPath uses a virtual XML document refered to as document view mapping in
the jsr 170 spec. Because the root element in that document is the root
node of the workspace any absolute XPath must start with /jcr:root. In
your case that would be something like:
/jcr:root/text//*[@my:includeInMainStream='true']
You may also use a relative XPath. In that case the context for the
query is the root node of the workspace:
text//*[@my:includeInMainStream='true']
Relevant section in the spec is: 6.6.3.3
regards
Marcel
RE: Query language issues
Posted by Timur Evdokimov <ti...@jacum.com>.
Hi Marcel,
With latest SVN update of today, everything seem to work with SQL.
But Xpath still doesn't work as it should
In //*[@my:includeInMainStream='true'] order by @my:publishingDate
descending
It complains about @ in @my:publishingDate clause
So that only order by publishingDate is accepted, but doesn't work anyway
Also any expression apart from //* returns nothing, i.e. just /text//* gives
0 hits, whereas
SELECT * FROM my:article WHERE jcr:path LIKE '/text/%' gives what it
supposed to give.
Am I doing something wrong or Xpath is just not polished enough there?
Regards,
Timur
-----Original Message-----
From: Marcel Reutegger [mailto:marcel.reutegger@gmx.net]
Sent: Friday, February 18, 2005 9:39 AM
To: jackrabbit-dev@incubator.apache.org
Subject: Re: Query language issues
Hi Timur,
Timur Evdokimov wrote:
> Before, I've been able to write something like SELECT * FROM
> my:article LOCATION /texts//* WHERE my:includeInMainStream='true'
> ORDER BY my:publishingDate DESCENDING and select 20 latest nodes from
> NodeIterator
>
> Now, in 0.16, it seems like it's more like standard SQL without
> LOCATION clause So I can't say LOCATION /texts//* anymore, and forced
> to do something like jcr:path LIKE '/texts/%' which yields only direct
> children of /texts, but not their descendants! And (jcr:path LIKE
> '/texts/%') OR (jcr:path LIKE
> '/texts/%/%') OR (jcr:path LIKE '/texts/%/%/%') could possibly work
> (though it looks somewhat stupid) but it doesn't work at all (bug in
> RI?)
Yes, that's definitively a bug in jackrabbit. jcr:path LIKE '/texts/%'
should select descendants of /text and not just its children.
I've created a JIRA issue: http://issues.apache.org/jira/browse/JCR-49
> Another option seem to be XPath query with
> /texts//*[@my:includeInMainStream='true']... but then I'd lose my
> rather important ORDER BY my:publishingDate!
> Pardon my ignorance, maybe there's better way to write this query?
The XPath variant JSR-170 uses, allows you to specify an order by clause.
So, you can write:
/texts//*[@my:includeInMainStream='true'] order by @my:publishingDate
descending
> And I don't feel quite like that jcr:path LIKE xxxxxx thing is
> something that deserves to be there.
> Maybe it should be at least allowed to be something like jcr:path LIKE
> jcrf:xpath('/texts//*'), or I don't know what...
yes, that would be another way. The goal was not to introduce too many new
constructs, but use what standard SQL provides. Either way has its pros and
cons...
regards
marcel
Re: Query language issues
Posted by Marcel Reutegger <ma...@gmx.net>.
Hi Timur,
Timur Evdokimov wrote:
> Before, I've been able to write something like
> SELECT * FROM my:article LOCATION /texts//* WHERE
> my:includeInMainStream='true' ORDER BY my:publishingDate DESCENDING
> and select 20 latest nodes from NodeIterator
>
> Now, in 0.16, it seems like it's more like standard SQL without LOCATION
> clause
> So I can't say LOCATION /texts//* anymore, and forced to do something like
> jcr:path LIKE '/texts/%' which yields only direct children of /texts, but
> not their descendants! And (jcr:path LIKE '/texts/%') OR (jcr:path LIKE
> '/texts/%/%') OR (jcr:path LIKE '/texts/%/%/%') could possibly work (though
> it looks somewhat stupid) but it doesn't work at all (bug in RI?)
Yes, that's definitively a bug in jackrabbit. jcr:path LIKE '/texts/%'
should select descendants of /text and not just its children.
I've created a JIRA issue: http://issues.apache.org/jira/browse/JCR-49
> Another option seem to be XPath query with
> /texts//*[@my:includeInMainStream='true']... but then I'd lose my rather
> important ORDER BY my:publishingDate!
> Pardon my ignorance, maybe there's better way to write this query?
The XPath variant JSR-170 uses, allows you to specify an order by
clause. So, you can write:
/texts//*[@my:includeInMainStream='true'] order by @my:publishingDate
descending
> And I don't feel quite like that jcr:path LIKE xxxxxx thing is something
> that deserves to be there.
> Maybe it should be at least allowed to be something like jcr:path LIKE
> jcrf:xpath('/texts//*'), or I don't know what...
yes, that would be another way. The goal was not to introduce too many
new constructs, but use what standard SQL provides. Either way has its
pros and cons...
regards
marcel
RE: Lock obsession
Posted by Timur Evdokimov <ti...@jacum.com>.
Hi
I've updated to latest SVN code and that problem mysteriously disappeared.
Thanks.
T.
-----Original Message-----
From: David Nuescheler [mailto:david.nuescheler@gmail.com]
Sent: Friday, February 18, 2005 9:12 AM
To: jackrabbit-dev@incubator.apache.org
Subject: Re: Lock obsession
hi timur,
i think this may be same problem as discussed in another thread.
http://article.gmane.org/gmane.comp.apache.jackrabbit.devel/762
and i think marcel has already changed the behaviour
http://article.gmane.org/gmane.comp.apache.jackrabbit.devel/775
so all you may need to do is to update the sources...
or am i confusing something?
regards,
david
On Thu, 17 Feb 2005 22:45:14 +0100, Timur Evdokimov <ti...@jacum.com> wrote:
>
> Hello everyone again,
>
> Yet another problem with Jackrabbit that bothers me are regular
> stacktraces thrown by Lucene indexer on Session.save() method.
>
> 2005-02-17 22:34:01,296 ERROR [ : : ] -
> SearchManager - error indexing node.
> java.io.IOException: Lock obtain timed out: Lock@write.lock
> at org.apache.lucene.store.Lock.obtain(Lock.java:58)
> at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:223)
> at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:213)
> at
> org.apache.jackrabbit.core.search.lucene.AbstractIndex.getIndexWriter(
> Abstra
> ctIndex.java:108)
> at
> org.apache.jackrabbit.core.search.lucene.AbstractIndex.addDocument(Abs
> tractI
> ndex.java:82)
> at
> org.apache.jackrabbit.core.search.lucene.SearchIndex.addNode(SearchInd
> ex.jav
> a:124)
> at
> org.apache.jackrabbit.core.SearchManager.addNode(SearchManager.java:158)
> at
> org.apache.jackrabbit.core.SearchManager.onEvent(SearchManager.java:300)
> at
> org.apache.jackrabbit.core.observation.EventConsumer.consumeEvents(Eve
> ntCons
> umer.java:196)
> at
> org.apache.jackrabbit.core.observation.ObservationManagerFactory.dispa
> tchEve
> nts(ObservationManagerFactory.java:216)
> at
> org.apache.jackrabbit.core.observation.EventStateCollection.dispatch(E
> ventSt
> ateCollection.java:218)
> at
> org.apache.jackrabbit.core.SessionImpl.dispatch(SessionImpl.java:332)
> at
> org.apache.jackrabbit.core.XASessionImpl.dispatch(XASessionImpl.java:308)
> at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1281)
> at
> org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:674)
>
> I haven't found exact patterns - how exactly it happens - but it seems
> that if there were changes during the session: like adding/deleting
> nodes and/or updating properties, I get something like this:
>
> 2005-02-17 22:39:48,968 ERROR [ : : ] -
> SearchManager - error indexing node.
> java.io.IOException: Lock obtain timed out: Lock@write.lock
> at org.apache.lucene.store.Lock.obtain(Lock.java:58)
> at
> org.apache.lucene.index.IndexReader.aquireWriteLock(IndexReader.java:408)
> at org.apache.lucene.index.IndexReader.delete(IndexReader.java:432)
> at org.apache.lucene.index.IndexReader.delete(IndexReader.java:454)
> at
> org.apache.jackrabbit.core.search.lucene.AbstractIndex.removeDocument(
> Abstra
> ctIndex.java:86)
> at
>
org.apache.jackrabbit.core.search.lucene.SearchIndex.deleteNode(SearchIndex.
> java:155)
> at
>
org.apache.jackrabbit.core.SearchManager.deleteNode(SearchManager.java:172)
> at
> org.apache.jackrabbit.core.SearchManager.onEvent(SearchManager.java:259)
> at
> org.apache.jackrabbit.core.observation.EventConsumer.consumeEvents(Eve
> ntCons
> umer.java:196)
> at
> org.apache.jackrabbit.core.observation.ObservationManagerFactory.dispa
> tchEve
> nts(ObservationManagerFactory.java:216)
> at
> org.apache.jackrabbit.core.observation.EventStateCollection.dispatch(E
> ventSt
> ateCollection.java:218)
> at
> org.apache.jackrabbit.core.SessionImpl.dispatch(SessionImpl.java:332)
> at
> org.apache.jackrabbit.core.XASessionImpl.dispatch(XASessionImpl.java:308)
> at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1281)
> at
> org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:674)
>
> What is quite surprising is that despite these exceptions, repository
> does function properly - everything is saved and retrieved like a
clockwork!
>
> My repository.xml looks like this:
>
> <?xml version="1.0" encoding="ISO-8859-1"?>
>
> <Repository>
> <FileSystem
class="org.apache.jackrabbit.core.fs.local.LocalFileSystem">
> <param name="path" value="${rep.home}"/>
> </FileSystem>
>
> <Workspaces rootPath="${rep.home}/workspaces"
> defaultWorkspace="default"/>
>
> <Workspace name="${wsp.name}">
> <FileSystem
> class="org.apache.jackrabbit.core.fs.local.LocalFileSystem">
> <param name="path" value="${wsp.home}/ws"/>
> </FileSystem>
>
> <PersistenceManager
> class="org.apache.jackrabbit.core.state.obj.ObjectPersistenceManager"/
> >
>
> <SearchIndex>
> <FileSystem
> class="org.apache.jackrabbit.core.fs.local.LocalFileSystem">
> <param name="path" value="${wsp.home}/index"/>
> </FileSystem>
> </SearchIndex>
> </Workspace>
>
> <Versioning rootPath="${rep.home}/version">
>
> <FileSystem
> class="org.apache.jackrabbit.core.fs.local.LocalFileSystem">
> <param name="path" value="${rep.home}/version"/>
> </FileSystem>
> <PersistenceManager
> class="org.apache.jackrabbit.core.state.obj.ObjectPersistenceManager"/
> >
>
> </Versioning>
>
> </Repository>
>
> I'm not sure whether this is inherent Jackrabbit problem, or Lucene
> problem, or org.apache.jackrabbit.core.fs.local.LocalFileSystem
> problem... Anyway, does it ring a bell?
>
> Best regards,
> Timur
>
>
--
----------------------------------------------------------------------
standardize your content-repository !
http://www.jcp.org/en/jsr/detail?id=170
---------------------------------------< david.nuescheler@day.com >---
This message is a private communication. If you are not the intended
recipient, please do not read, copy, or use it, and do not disclose it to
others. Please notify the sender of the delivery error by replying to this
message, and then delete it from your system. Thank you.
The sender does not assume any liability for timely, trouble free, complete,
virus free, secure, error free or uninterrupted arrival of this e-mail. For
verification please request a hard copy version.
mailto:david.nuescheler@day.com
http://www.day.com
David Nuescheler
Chief Technology Officer
Day Software AG
Barfuesserplatz 6 / Postfach
4001 Basel
Switzerland
T 41 61 226 98 98
F 41 61 226 98 97
Re: Lock obsession
Posted by David Nuescheler <da...@gmail.com>.
hi timur,
i think this may be same problem as discussed in another thread.
http://article.gmane.org/gmane.comp.apache.jackrabbit.devel/762
and i think marcel has already changed the behaviour
http://article.gmane.org/gmane.comp.apache.jackrabbit.devel/775
so all you may need to do is to update the sources...
or am i confusing something?
regards,
david
On Thu, 17 Feb 2005 22:45:14 +0100, Timur Evdokimov <ti...@jacum.com> wrote:
>
> Hello everyone again,
>
> Yet another problem with Jackrabbit that bothers me are regular stacktraces
> thrown by Lucene indexer on Session.save() method.
>
> 2005-02-17 22:34:01,296 ERROR [ : : ] -
> SearchManager - error indexing node.
> java.io.IOException: Lock obtain timed out: Lock@write.lock
> at org.apache.lucene.store.Lock.obtain(Lock.java:58)
> at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:223)
> at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:213)
> at
> org.apache.jackrabbit.core.search.lucene.AbstractIndex.getIndexWriter(Abstra
> ctIndex.java:108)
> at
> org.apache.jackrabbit.core.search.lucene.AbstractIndex.addDocument(AbstractI
> ndex.java:82)
> at
> org.apache.jackrabbit.core.search.lucene.SearchIndex.addNode(SearchIndex.jav
> a:124)
> at
> org.apache.jackrabbit.core.SearchManager.addNode(SearchManager.java:158)
> at
> org.apache.jackrabbit.core.SearchManager.onEvent(SearchManager.java:300)
> at
> org.apache.jackrabbit.core.observation.EventConsumer.consumeEvents(EventCons
> umer.java:196)
> at
> org.apache.jackrabbit.core.observation.ObservationManagerFactory.dispatchEve
> nts(ObservationManagerFactory.java:216)
> at
> org.apache.jackrabbit.core.observation.EventStateCollection.dispatch(EventSt
> ateCollection.java:218)
> at
> org.apache.jackrabbit.core.SessionImpl.dispatch(SessionImpl.java:332)
> at
> org.apache.jackrabbit.core.XASessionImpl.dispatch(XASessionImpl.java:308)
> at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1281)
> at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:674)
>
> I haven't found exact patterns - how exactly it happens - but it seems that
> if there were changes during the session: like adding/deleting nodes and/or
> updating properties, I get something like this:
>
> 2005-02-17 22:39:48,968 ERROR [ : : ] -
> SearchManager - error indexing node.
> java.io.IOException: Lock obtain timed out: Lock@write.lock
> at org.apache.lucene.store.Lock.obtain(Lock.java:58)
> at
> org.apache.lucene.index.IndexReader.aquireWriteLock(IndexReader.java:408)
> at org.apache.lucene.index.IndexReader.delete(IndexReader.java:432)
> at org.apache.lucene.index.IndexReader.delete(IndexReader.java:454)
> at
> org.apache.jackrabbit.core.search.lucene.AbstractIndex.removeDocument(Abstra
> ctIndex.java:86)
> at
> org.apache.jackrabbit.core.search.lucene.SearchIndex.deleteNode(SearchIndex.
> java:155)
> at
> org.apache.jackrabbit.core.SearchManager.deleteNode(SearchManager.java:172)
> at
> org.apache.jackrabbit.core.SearchManager.onEvent(SearchManager.java:259)
> at
> org.apache.jackrabbit.core.observation.EventConsumer.consumeEvents(EventCons
> umer.java:196)
> at
> org.apache.jackrabbit.core.observation.ObservationManagerFactory.dispatchEve
> nts(ObservationManagerFactory.java:216)
> at
> org.apache.jackrabbit.core.observation.EventStateCollection.dispatch(EventSt
> ateCollection.java:218)
> at
> org.apache.jackrabbit.core.SessionImpl.dispatch(SessionImpl.java:332)
> at
> org.apache.jackrabbit.core.XASessionImpl.dispatch(XASessionImpl.java:308)
> at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1281)
> at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:674)
>
> What is quite surprising is that despite these exceptions, repository does
> function properly - everything is saved and retrieved like a clockwork!
>
> My repository.xml looks like this:
>
> <?xml version="1.0" encoding="ISO-8859-1"?>
>
> <Repository>
> <FileSystem class="org.apache.jackrabbit.core.fs.local.LocalFileSystem">
> <param name="path" value="${rep.home}"/>
> </FileSystem>
>
> <Workspaces rootPath="${rep.home}/workspaces"
> defaultWorkspace="default"/>
>
> <Workspace name="${wsp.name}">
> <FileSystem
> class="org.apache.jackrabbit.core.fs.local.LocalFileSystem">
> <param name="path" value="${wsp.home}/ws"/>
> </FileSystem>
>
> <PersistenceManager
> class="org.apache.jackrabbit.core.state.obj.ObjectPersistenceManager"/>
>
> <SearchIndex>
> <FileSystem
> class="org.apache.jackrabbit.core.fs.local.LocalFileSystem">
> <param name="path" value="${wsp.home}/index"/>
> </FileSystem>
> </SearchIndex>
> </Workspace>
>
> <Versioning rootPath="${rep.home}/version">
>
> <FileSystem
> class="org.apache.jackrabbit.core.fs.local.LocalFileSystem">
> <param name="path" value="${rep.home}/version"/>
> </FileSystem>
> <PersistenceManager
> class="org.apache.jackrabbit.core.state.obj.ObjectPersistenceManager"/>
>
> </Versioning>
>
> </Repository>
>
> I'm not sure whether this is inherent Jackrabbit problem, or Lucene problem,
> or org.apache.jackrabbit.core.fs.local.LocalFileSystem problem... Anyway,
> does it ring a bell?
>
> Best regards,
> Timur
>
>
--
----------------------------------------------------------------------
standardize your content-repository !
http://www.jcp.org/en/jsr/detail?id=170
---------------------------------------< david.nuescheler@day.com >---
This message is a private communication. If you are not the intended
recipient, please do not read, copy, or use it, and do not disclose it
to others. Please notify the sender of the delivery error by replying
to this message, and then delete it from your system. Thank you.
The sender does not assume any liability for timely, trouble free,
complete, virus free, secure, error free or uninterrupted arrival of
this e-mail. For verification please request a hard copy version.
mailto:david.nuescheler@day.com
http://www.day.com
David Nuescheler
Chief Technology Officer
Day Software AG
Barfuesserplatz 6 / Postfach
4001 Basel
Switzerland
T 41 61 226 98 98
F 41 61 226 98 97
Lock obsession
Posted by Timur Evdokimov <ti...@jacum.com>.
Hello everyone again,
Yet another problem with Jackrabbit that bothers me are regular stacktraces
thrown by Lucene indexer on Session.save() method.
2005-02-17 22:34:01,296 ERROR [ : : ] -
SearchManager - error indexing node.
java.io.IOException: Lock obtain timed out: Lock@write.lock
at org.apache.lucene.store.Lock.obtain(Lock.java:58)
at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:223)
at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:213)
at
org.apache.jackrabbit.core.search.lucene.AbstractIndex.getIndexWriter(Abstra
ctIndex.java:108)
at
org.apache.jackrabbit.core.search.lucene.AbstractIndex.addDocument(AbstractI
ndex.java:82)
at
org.apache.jackrabbit.core.search.lucene.SearchIndex.addNode(SearchIndex.jav
a:124)
at
org.apache.jackrabbit.core.SearchManager.addNode(SearchManager.java:158)
at
org.apache.jackrabbit.core.SearchManager.onEvent(SearchManager.java:300)
at
org.apache.jackrabbit.core.observation.EventConsumer.consumeEvents(EventCons
umer.java:196)
at
org.apache.jackrabbit.core.observation.ObservationManagerFactory.dispatchEve
nts(ObservationManagerFactory.java:216)
at
org.apache.jackrabbit.core.observation.EventStateCollection.dispatch(EventSt
ateCollection.java:218)
at
org.apache.jackrabbit.core.SessionImpl.dispatch(SessionImpl.java:332)
at
org.apache.jackrabbit.core.XASessionImpl.dispatch(XASessionImpl.java:308)
at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1281)
at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:674)
I haven't found exact patterns - how exactly it happens - but it seems that
if there were changes during the session: like adding/deleting nodes and/or
updating properties, I get something like this:
2005-02-17 22:39:48,968 ERROR [ : : ] -
SearchManager - error indexing node.
java.io.IOException: Lock obtain timed out: Lock@write.lock
at org.apache.lucene.store.Lock.obtain(Lock.java:58)
at
org.apache.lucene.index.IndexReader.aquireWriteLock(IndexReader.java:408)
at org.apache.lucene.index.IndexReader.delete(IndexReader.java:432)
at org.apache.lucene.index.IndexReader.delete(IndexReader.java:454)
at
org.apache.jackrabbit.core.search.lucene.AbstractIndex.removeDocument(Abstra
ctIndex.java:86)
at
org.apache.jackrabbit.core.search.lucene.SearchIndex.deleteNode(SearchIndex.
java:155)
at
org.apache.jackrabbit.core.SearchManager.deleteNode(SearchManager.java:172)
at
org.apache.jackrabbit.core.SearchManager.onEvent(SearchManager.java:259)
at
org.apache.jackrabbit.core.observation.EventConsumer.consumeEvents(EventCons
umer.java:196)
at
org.apache.jackrabbit.core.observation.ObservationManagerFactory.dispatchEve
nts(ObservationManagerFactory.java:216)
at
org.apache.jackrabbit.core.observation.EventStateCollection.dispatch(EventSt
ateCollection.java:218)
at
org.apache.jackrabbit.core.SessionImpl.dispatch(SessionImpl.java:332)
at
org.apache.jackrabbit.core.XASessionImpl.dispatch(XASessionImpl.java:308)
at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1281)
at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:674)
What is quite surprising is that despite these exceptions, repository does
function properly - everything is saved and retrieved like a clockwork!
My repository.xml looks like this:
<?xml version="1.0" encoding="ISO-8859-1"?>
<Repository>
<FileSystem class="org.apache.jackrabbit.core.fs.local.LocalFileSystem">
<param name="path" value="${rep.home}"/>
</FileSystem>
<Workspaces rootPath="${rep.home}/workspaces"
defaultWorkspace="default"/>
<Workspace name="${wsp.name}">
<FileSystem
class="org.apache.jackrabbit.core.fs.local.LocalFileSystem">
<param name="path" value="${wsp.home}/ws"/>
</FileSystem>
<PersistenceManager
class="org.apache.jackrabbit.core.state.obj.ObjectPersistenceManager"/>
<SearchIndex>
<FileSystem
class="org.apache.jackrabbit.core.fs.local.LocalFileSystem">
<param name="path" value="${wsp.home}/index"/>
</FileSystem>
</SearchIndex>
</Workspace>
<Versioning rootPath="${rep.home}/version">
<FileSystem
class="org.apache.jackrabbit.core.fs.local.LocalFileSystem">
<param name="path" value="${rep.home}/version"/>
</FileSystem>
<PersistenceManager
class="org.apache.jackrabbit.core.state.obj.ObjectPersistenceManager"/>
</Versioning>
</Repository>
I'm not sure whether this is inherent Jackrabbit problem, or Lucene problem,
or org.apache.jackrabbit.core.fs.local.LocalFileSystem problem... Anyway,
does it ring a bell?
Best regards,
Timur
Query language issues
Posted by Timur Evdokimov <ti...@jacum.com>.
Hello everyone,
I've noticed drastical changes in JCR query language(s), compared to what
used to be in JCR 0.15
I feel somewhat uneasy about it.
First of all, my use case. There's a JCR-driven web site, filled with
various content. One part of it lives under /texts node, with rather complex
structure of sub-sections beneath. This part is regularly with new articles
being posted. On a home page, there must be a list of 20 recent articles
from _all sub-sections_ under /texts, in reverse chronological order, with
latest article on the top.
Before, I've been able to write something like
SELECT * FROM my:article LOCATION /texts//* WHERE
my:includeInMainStream='true' ORDER BY my:publishingDate DESCENDING
and select 20 latest nodes from NodeIterator
Now, in 0.16, it seems like it's more like standard SQL without LOCATION
clause
So I can't say LOCATION /texts//* anymore, and forced to do something like
jcr:path LIKE '/texts/%' which yields only direct children of /texts, but
not their descendants! And (jcr:path LIKE '/texts/%') OR (jcr:path LIKE
'/texts/%/%') OR (jcr:path LIKE '/texts/%/%/%') could possibly work (though
it looks somewhat stupid) but it doesn't work at all (bug in RI?)
Another option seem to be XPath query with
/texts//*[@my:includeInMainStream='true']... but then I'd lose my rather
important ORDER BY my:publishingDate!
Pardon my ignorance, maybe there's better way to write this query?
And I don't feel quite like that jcr:path LIKE xxxxxx thing is something
that deserves to be there.
Maybe it should be at least allowed to be something like jcr:path LIKE
jcrf:xpath('/texts//*'), or I don't know what...
Any suggestions are greatly appreciated.
Best regards,
Timur
[jira] Closed: (JCR-48) XMLPersistenceManager trims string property values
Posted by "Stefan Guggisberg (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-48?page=history ]
Stefan Guggisberg closed JCR-48:
--------------------------------
Resolution: Fixed
fixed in r154159
thanks for reporting this bug!
> XMLPersistenceManager trims string property values
> --------------------------------------------------
>
> Key: JCR-48
> URL: http://issues.apache.org/jira/browse/JCR-48
> Project: Jackrabbit
> Type: Bug
> Environment: Jackrabbit 154013
> Reporter: Rod Mackenzie
> Assignee: Stefan Guggisberg
> Priority: Minor
>
> The XMLPersistenceManager trims the text of property values read in, so what's returned doesn't match the value set if it included whitespace at the start or end.
--
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
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Assigned: (JCR-48) XMLPersistenceManager trims string property values
Posted by "Stefan Guggisberg (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-48?page=history ]
Stefan Guggisberg reassigned JCR-48:
------------------------------------
Assign To: Stefan Guggisberg
> XMLPersistenceManager trims string property values
> --------------------------------------------------
>
> Key: JCR-48
> URL: http://issues.apache.org/jira/browse/JCR-48
> Project: Jackrabbit
> Type: Bug
> Environment: Jackrabbit 154013
> Reporter: Rod Mackenzie
> Assignee: Stefan Guggisberg
> Priority: Minor
>
> The XMLPersistenceManager trims the text of property values read in, so what's returned doesn't match the value set if it included whitespace at the start or end.
--
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
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira