On Wed, 2006-11-22 at 02:22 +0200, Jukka Zitting wrote:
Yes. A JCR Session is not necessarily thread-safe even for read-only
access. So unless we want to introduce a session pool, we need to
block all simultaneous requests within a HTTP session. Note however
that we can (and should) map the
hi,
On 11/22/06, Torgeir Veimo [EMAIL PROTECTED] wrote:
On Wed, 2006-11-22 at 02:22 +0200, Jukka Zitting wrote:
Note however that we can (and should) map the login/synchronization
filter to just the JSP pages and servlets that need access to the JCR
session - there's no need to synchronize
Hi.
During my regression tests with JCR2SPI and my custom SPI implementation
I found a difference that may indicate a missing feature in SPI. Or not.
What happens is that I have a custom node type which internally holds a
potentially huge amount of property definitions, and for that reason,
hi
sorry. i reread you mail multiple times, and i don't get
your point.
here is what jsr170 defines:
- that PropertyDefinition.getRequiredType() may be one of
STRING, BINARY, DATE, LONG, DOUBLE, NAME, PATH, REFERENCE,
BOOLEAN or UNDEFINED.
- If PropertyDefinition.getRequiredType() is
Angela Schreiber schrieb:
hi
sorry. i reread you mail multiple times, and i don't get
your point.
Sorry, I'll try to do better this time.
here is what jsr170 defines:
- that PropertyDefinition.getRequiredType() may be one of
STRING, BINARY, DATE, LONG, DOUBLE, NAME, PATH, REFERENCE,
Jukka Zitting schrieb:
Hi,
On 11/22/06, Julian Reschke [EMAIL PROTECTED] wrote:
No, the point is that in JSR-170 it is possible that for a given node
type N, the NodeType interface will only return residual property
definitions (because the set of property definitions on this node type
may be
No, the point is that in JSR-170 it is possible that for a given node
type N, the NodeType interface will only return residual property
definitions (because the set of property definitions on this node type
may be very large), while Property.getPropertyDefinition() will return a
non-residual
We have a repository with some hundred of megas and we want to re-index
all the documents.
--
Paco Avila [EMAIL PROTECTED]
Tobias Bocanegra a écrit :
yes,
- stop the repository
- delete the search indexes in the workspace directories
- start the repository
the search handler will then traverse the repository and reindex all
items.
regards, toby
One could imagine a programatical way of doing this. This is
[
http://issues.apache.org/jira/browse/JCR-546?page=comments#action_12452086 ]
Jukka Zitting commented on JCR-546:
---
Did you already have time to look at this? It seems correct to me, passes all
unit tests, and worked fine with an ad-hoc test
10 matches
Mail list logo