Unable to build nt-ns-util

When I try to build the package I get this error.

C:\apache\jackrabbit-contrib\nt-ns-util>maven
 __  __
|  \/  |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
|_|  |_\__,_|\_/\___|_||_|  v. 1.0.2

Attempting to download jackrabbit-1.0-SNAPSHOT.jar.
Artifact /org.apache.jackrabbit/jars/jackrabbit-1.0-SNAPSHOT.jar doesn't exists in remote
repository, but it exists locally
Attempting to download jackrabbit-commons-1.0-SNAPSHOT.jar.
Artifact /org.apache.jackrabbit/jars/jackrabbit-commons-1.0-SNAPSHOT.jar doesn't exists in
remote repository, but it exists locally
build:start:

java:prepare-filesystem:

java:compile:
    [echo] Compiling to C:\apache\jackrabbit-contrib\nt-ns-util/target/classes
    [javac] Compiling 1 source file to
C:\apache\jackrabbit-contrib\nt-ns-util\target\classes
C:\apache\jackrabbit-contrib\nt-ns-util\src\main\java\org\apache\jackrabbit\util\nodetype\SchemaConverter.java:71:
cannot resolve symbol
symbol  : method loadURI (java.lang.String)
location: class org.apache.xerces.impl.xs.XMLSchemaLoader
        XSModel xsModel = loader.loadURI(uri);
                                ^
1 error

corrupted root node state

i'm having an interesting production experience in which jackrabbit
has become unable to load the root node's state. it seems to have
entered this state after the machine it's running on was abruptly
power cycled. specifically, jackrabbit is receiving an EOFException
when deserializing the root node state read from derby (stack trace
below).

the exception is thrown at the same stage of deserialization every
time i try to start up the repository, which implies that corrupted
data somehow got stored into derby at some previous time. no errors
were logged by either jackrabbit or derby prior to the first
deserialization error.

i'm interested to hear any thoughts on how jackrabbit+derby could have
gotten into this state and what we might do to prevent this from
happening again.

thanks!

java.io.EOFException
        at java.io.DataInputStream.readFully(DataInputStream.java:178)
        at java.io.DataInputStream.readUTF(DataInputStream.java:565)
        at java.io.DataInputStream.readUTF(DataInputStream.java:522)
        at org.apache.jackrabbit.core.state.util.Serializer.deserialize(Serializ
er.java:153)
        at org.apache.jackrabbit.core.state.db.SimpleDbPersistenceManager.load(S
impleDbPersistenceManager.java:455)
        ... 59 more
org.apache.jackrabbit.core.state.ItemStateException: failed to read node state:
cafebabe-cafe-babe-cafe-babecafebabe: null

HEADS UP: JCR-RMI remote interfaces changed

Hi,

I just committed (revision 365458) a change to JCR-RMI that changes a
number of the remote interfaces to use network-optimized iterators
instead of simple arrays to pass potentially large sequences of
objects (e.g. QueryResult.getNodes). Please note this if you are
building JCR-RMI to be used with a client or server application that
uses a previously built JCR-RMI jar.

I'll be making other similar changes to JCR-RMI for the next week or
two in order to streamline and optimize the interfaces. After that I
hope freeze the JCR-RMI interfaces for a stable 1.0 version that could
hopefully be bundled with the Jackrabbit 1.0 release.

If you have any wishes for improvements or other feature requests that
you'd like to see included in 1.0, please let me know. Please also
note that JCR-RMI may be a bit unstable during this period so you may
want to avoid upgrading your existing jars unless you want to help in
testing and development. 

BR,

Jukka Zitting

--
Yukatan - http://yukatan.fi/ - info <at> yukatan.fi
Software craftmanship, JCR consulting, and Java development

Re: HEADS UP: JCR-RMI remote interfaces changed

Hi Jukka,

Happy new year and a big chear ! Thanks.
> If you have any wishes for improvements or other feature requests that
> you'd like to see included in 1.0, please let me know.
Currently JCR-RMI has its own implementations of the Value and 
ValueFactory interfaces. How about reusing the implementations of the 
"jackrabbit-commons". This might prevent needless server-side value 
copying and would also solve the current issue we have with the Date 
value, which does not really support ISO806 in its full breadth.

Regards
Felix

Fwd: Strange search behaviour

Hi people, I hope you all a good new year.

Today I have been testing my repository and I found a strange search
behaviour that make me thought that it could be some bug on the search
algorithm.

Let's see. First of all, I'm using XMLPersistenceManager. I had one big
repository with 500..1000 documents. All those documents had the content
indexed using the available text filters. Next I created a smaller
repository with only two nodes, also with their content indexed with
available text filters.

Then I performed a xpath query over the smaller repository. Something like
this://*[ <at> jcr:primaryType='nt:file' and
jcr:contains( <at> jlib:keywords,'test')]. As you see, is very simple, it
searches for a term under a keywords property. That query went fine and
returned very fast.

But the problem, is when I performed another query. Something like this:
//*[ <at> jcr:primaryType='nt:resource' and jcr:contains(.,'test')] This query
tries to search the same term on the node binary contents. The query was
very very very slooooooow. So I decided to debug that query, and I saw that
the NodeIterator returned had over 270 nodes !!! How it can have 270 nodes
if the repository won't have more than 10? I suppose that is because the
query was done also over the first repository, but then, is the XPath query
wrong?

Thanks for your help!

Martin

Re: corrupted root node state

On 1/2/06, Brian Moseley <bcm <at> osafoundation.org> wrote:
> i'm having an interesting production experience in which jackrabbit
> has become unable to load the root node's state. it seems to have
> entered this state after the machine it's running on was abruptly
> power cycled. specifically, jackrabbit is receiving an EOFException
> when deserializing the root node state read from derby (stack trace
> below).
>
> the exception is thrown at the same stage of deserialization every
> time i try to start up the repository, which implies that corrupted
> data somehow got stored into derby at some previous time. no errors
> were logged by either jackrabbit or derby prior to the first
> deserialization error.
>
> i'm interested to hear any thoughts on how jackrabbit+derby could have
> gotten into this state and what we might do to prevent this from
> happening again.

currently i can only think of two possible explanations:
1. you're trying to read data which what was written with an older jackrabbit
    version. the serialization format has changed a while ago (svn r329841).
2. the power cycle must have happened during the jdbc commit call
    (SimpleDbPersistenceManager line 419) which in turn caused a corrupted
    node state. although this seems rather unlikely...

if you can provide me the data (derby database) i'll investigate further.

cheers
stefan

JCR-RMI Iterator support

Hi Jukka,

To provide for extensibility of the JCR-RMI implementation I suggest to 
make the MAX_BUFFER_SIZE field and optimizeIterator method protected in 
the ServerAdapterFactory class.

What do you think ?

Find attached a patch file with the suggested modification.

Regards
Felix

Index: S:/src/jackrabbit/jackrabbit/contrib/jcr-rmi/src/java/org/apache/jackrabbit/rmi/server/ServerAdapterFactory.java
===================================================================
---
S:/src/jackrabbit/jackrabbit/contrib/jcr-rmi/src/java/org/apache/jackrabbit/rmi/server/ServerAdapterFactory.java	(revision 365588)
+++
S:/src/jackrabbit/jackrabbit/contrib/jcr-rmi/src/java/org/apache/jackrabbit/rmi/server/ServerAdapterFactory.java	(working copy)
 <at>  <at>  -94,7 +94,7  <at>  <at> 
     /**
      * The default maximum buffer size used for local iterator buffers.
      */
-    private static final int MAX_BUFFER_SIZE = 100;
+    protected static final int MAX_BUFFER_SIZE = 100;

     /**
      * Creates a { <at> link ServerRepository ServerRepository} instance.
 <at>  <at>  -318,7 +318,7  <at>  <at> 

Re: JCR-RMI Iterator support

Hi Felix,

Thanks for the comment. Now that I think of it I'd actually go a bit
further and make the buffer size an optional parameter for the
ServerAdapterFactory constructor. I'll commit the change in a minute.

BR,

Jukka Zitting

--
Yukatan - http://yukatan.fi/ - info <at> yukatan.fi
Software craftmanship, JCR consulting, and Java development

Re: HEADS UP: JCR-RMI remote interfaces changed

Hi,

On 1/3/06, Felix Meschberger <Felix.Meschberger <at> day.com> wrote:
> Currently JCR-RMI has its own implementations of the Value and
> ValueFactory interfaces. How about reusing the implementations of the
> "jackrabbit-commons". This might prevent needless server-side value
> copying and would also solve the current issue we have with the Date
> value, which does not really support ISO806 in its full breadth.

Good point. I'm not sure if the standard Jackrabbit ValueFactory
produces network-safe Values. In any case we should probably better
align the codebases. I'll take a look at this.

BR,

Jukka Zitting

--
Yukatan - http://yukatan.fi/ - info <at> yukatan.fi
Software craftmanship, JCR consulting, and Java development

Re: Strange search behaviour

I assume that the returned nodes are from the jcr:system tree which
contains versions of your nodes and node representations of your
nodetypes.

Regarding performance, per default the query handler is configured to
return nodes in document order. This means that the query handler will
read all result nodes and order them how they appear in the workspace.
In your case using a XMLPersistenceManager this  might not the the
most efficient setup ;)

You can disable document order on result nodes with the following
parameter in the SearchIndex tag:
name="respectDocumentOrder" value="false"

If you still have performance problems or think that the query returns
wrong results please post a jira issue with instructions how to
reproduce.

regards
 marcel

On 1/3/06, Martin Perez <mpermar <at> gmail.com> wrote:
> Hi people, I hope you all a good new year.
>
> Today I have been testing my repository and I found a strange search
> behaviour that make me thought that it could be some bug on the search
> algorithm.
>
> Let's see. First of all, I'm using XMLPersistenceManager. I had one big
> repository with 500..1000 documents. All those documents had the content