On 4/6/06, Angela Schreiber <[EMAIL PROTECTED]> wrote:
>
> a) > access to the content of a version
>
> i assume, that you are getting the 'dirlisting' export
> for the version. probably it would be wise to create
> a separate IOHandler for the versions.
true, I just take a look, I get a
Hi Florent,
JackRabbit's XAResources exposed by
org.apache.jackrabbit.core.XASessionImpl do not enlist themselves,
this is the application server's (or your) responsibility. There is a
dummy UserTransaction implementation used when testing XA
functionality, namely:
org/apache/jackrabbit/core/User
On 4/6/06, Angela Schreiber <[EMAIL PROTECTED]> wrote:
[snip]
>
>
> Proposed solution
> -
>
> The situation described before leads me to the
> following conclusion:
>
> - IOHandler should not only read/write resource data
>and properties durin
Hi.
I think I found a bug with RC3 and XPath queries. Correct me if I'm wrong, I
will try to describe it as good as possible.
On my workspace, the next query does not returns any results:
"/jcr:root//element(*,jlib:jlibrary)[EMAIL PROTECTED]:id]"
That is fine as the workspace should not have any
Brian Moseley wrote:
On 4/6/06, Julian Reschke (JIRA) <[EMAIL PROTECTED]> wrote:
[ http://issues.apache.org/jira/browse/JCR-389?page=all ]
Julian Reschke updated JCR-389:
---
Attachment: diffs
This patch adds DavException to the signature of getRequestDocu
Hi,
On 4/2/06, Jukka Zitting <[EMAIL PROTECTED]> wrote:
> Please vote on releasing these packages as Apache Jackrabbit 1.0. The
> vote is open for the next 72 hours, and only votes from Jackrabbit
> committers are considered binding. The vote passes if at least three
> +1 votes are cast.
>
> [ ]
Hi,
On 4/6/06, thomasg <[EMAIL PROTECTED]> wrote:
> Don't think I'm using transactions. How do you use transactions? (brief
> answer ok)
There's a XASession superinterface that allows you to use JTA
distributed transactions with a JCR repository like Jackrabbit.
> The 1 min for 50MB was for the
Hi,
On 4/6/06, hsp <[EMAIL PROTECTED]> wrote:
> Which would be more appropriate to use? Is it enough to use only jcr-rmi to
> do a
> client to call the methods available in the application looked by JNDI? Must
> I use
> jcr-server together?
JCR-RMI is a mostly transparent network layer for the
Hi,
I'll be using JackRabbit in a small server program to receive connections
from multiple clients. These connections have to be isolated from one
another, so they'll live in separate transactions. I'll be using JOTM as the
transaction manager.
I'm a little unclear about how the JackRabbit
Which would be more appropriate to use? Is it enough to use only jcr-rmi to do
a client to call the methods available in the application looked by JNDI? Must
I use jcr-server together?
Using the jcr-rmi I have to implement the stubs, .? I am new in such
configuration.
Thankx
Helio.
Hi guys,
I've been trying to get multiple threads to add a file to the same
workspace. Each thread gets its own session in its run() method, creates a
nt:folder and adds a nt:file and nt:resource. One thread succeeds but all
others fail with an ItemNotFoundException. The output is as follows:
t
On 4/6/06, Julian Reschke (JIRA) <[EMAIL PROTECTED]> wrote:
> [ http://issues.apache.org/jira/browse/JCR-389?page=all ]
>
> Julian Reschke updated JCR-389:
> ---
>
> Attachment: diffs
>
> This patch adds DavException to the signature of getRequestDocument(), and
[ http://issues.apache.org/jira/browse/JCR-389?page=all ]
Julian Reschke updated JCR-389:
---
Attachment: diffs
This patch adds DavException to the signature of getRequestDocument(), and
attempts to make sure that an exception is thrown when a request body i
WebDAV server should treat non-wellformed XML in request bodies as error
Key: JCR-389
URL: http://issues.apache.org/jira/browse/JCR-389
Project: Jackrabbit
Type: Bug
Components: webdav
On 4/6/06, Angela Schreiber <[EMAIL PROTECTED]> wrote:
> Proposed solution
> -
>
> The situation described before leads me to the
> following conclusion:
>
> - IOHandler should not only read/write resource data
>and properties during GET, PUT
Thanks a lot.
Oliver
On 05.04.2006 12:07 Uhr, "Tobias Bocanegra" <[EMAIL PROTECTED]>
wrote:
> you need to checkin first:
>
> node = session.getRootNode().addNode("entry");
> node.addMixin("mix:versionable");
> node.setProperty("content", "1");
> node.getSession.save();
> node.checkin() <
That's exactly what I tryied to meaning for. All the process of document
retrieval, not only the indexer, because are separated things, thanks by
clarification. But I remains with my doubt if is it possible to store the blob
files in another machine that is not where is running the application
That's fine. I suppose that you have received my patch.
Martin
On 4/6/06, Marcel Reutegger <[EMAIL PROTECTED]> wrote:
>
> Martin Perez wrote:
> > Yes, the problem with the filters is that if I'm not wrong, they are
> called
> > three times each time you make a simple save() operation. There is a
Martin Perez wrote:
Yes, the problem with the filters is that if I'm not wrong, they are called
three times each time you make a simple save() operation. There is a bug
opened about that but it's complex to be solved.
Thomas, don't worry about the textfilters, I really didn't know that after
get
Hi,
I'm using:
Don't think I'm using transactions. How do you use transactions? (brief
answer ok)
I think my figures were wrong:
The 1 min for 50MB was for the whole process of adding, text extraction,
indexing and running a query. I've retimed the call to session.save() as
9937
hi jérémi
thanks for your effort. i'll look at it as soon as
possible and as jira is up again.
kind regards
angela
regarding you questions (i did not manage to download
your attachment yet).
a) > access to the content of a version
i assume, that you are getting the 'dirlisting' export
f
Miro Walker wrote:
I can't see why a blob on the FS would be faster to search - searching
should happen against the lucene index, no? Retrieval and streaming of
large blobs are likely to be faster from the FS, but I don't think
search itself would be.
that's correct. query performance primarily
Carlos Villegas wrote:
Marcel Reutegger wrote:
Jukka Zitting wrote:
Marcel, just out of curiosity, would it be possible to run the indexer
using asynchronous events or would that cause some complications?
yes, there are two issues with this approach:
- there would be no guarantee anymore th
Yes, the problem with the filters is that if I'm not wrong, they are called
three times each time you make a simple save() operation. There is a bug
opened about that but it's complex to be solved.
Thomas, don't worry about the textfilters, I really didn't know that after
getting a stream through
Yep, you're right. I removed the text filters and the deleting error goes
away. Looks like quite a simple fix in the word text filter, I'll change and
test. On the subject of another thread, removing the filters also greatly
reduces the time taken for session.save() to return so this call must be
I can't see why a blob on the FS would be faster to search - searching
should happen against the lucene index, no? Retrieval and streaming of
large blobs are likely to be faster from the FS, but I don't think
search itself would be.
-Original Message-
From: hsp [mailto:[EMAIL PROTECTED]
Marcel Reutegger wrote:
> Jukka Zitting wrote:
>
>> Marcel, just out of curiosity, would it be possible to run the indexer
>> using asynchronous events or would that cause some complications?
>
>
> yes, there are two issues with this approach:
>
> - there would be no guarantee anymore that you
it seems that your repository configuration file is malformed.
please check the repository.xml file that you are using.
regards
marcel
Chan Chin Wei wrote:
I tried to set up the jackrabbit in tomcat 5.0.28, but i get "[Fatal
Error] :1:1: Content is not allowed in prolog." error when i tried t
hi
i'd like to summarize the problem we are currently
having with matching a PROPPATCH request to JSR170
compliant repository (specially the RI) and come up
with a suggested solution.
Description
-
While setting properties on a JSR170 reposito
Cédric Damioli wrote:
Jukka Zitting a écrit :
2) Support for predicates in location steps:
//element(*,nt:file)[EMAIL PROTECTED]:created>'...']/jcr:[EMAIL PROTECTED]:lastModified<'...']
This one already works, don't it ?
I run many queries like this one in my app.
I don't know if it b
hsp wrote:
Extending this thread, while have anyone to opine it.
I know that only the content (properties and binary under nt:resource) are automatically indexed by jackrabbit for searches, and of course these contents must have be in the repository for the method get works...
I would to know if
Jukka Zitting wrote:
Marcel, just out of curiosity, would it be possible to run the indexer
using asynchronous events or would that cause some complications?
yes, there are two issues with this approach:
- there would be no guarantee anymore that you will find nodes with a
query that were jus
32 matches
Mail list logo