headers
Premkumar Stephen | 1 Mar 2010 04:42
Picon

Re: Storing a jackrabbit repository as versioned files in git

Hi Janne,

Thanks for letting me know about priha.
It would be great if I could use git or any other VCS to store this data
just like any other source files ( In Drools Guvnor, "code" is stored in the
repository).

I do not plan to do any file modifications using git.
Primarily, I am looking at storing and maintaining versions using git ( or
maybe another VCS).
I would like to do a diff, and it would help if one asset is in one file (
atleast those assets that are versioned).

Regards,
Prem

On Sun, Feb 28, 2010 at 4:40 AM, Janne Jalkanen <Janne.Jalkanen <at> ecyrd.com>wrote:

>
> The version control as such shouldn't really be a problem, as long as you
> don't actually modify the files (essentially using git as a backup system).
> But modifying the files needs rather deep understanding of what is going on,
> so I wouldn't recommend it.
>
> I'm not sure whether anyone has written a Jackrabbit PM which stores the
> files as-is.  I know that Priha (www.priha.org) has one.  But if you just
> do backup, then the actual physical structure shouldn't matter anyway.
>
> /Janne
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Illarion Kovalchuk | 1 Mar 2010 11:21
Picon
Gravatar

Re: How to store randomly accessed data in jackrabbit?

Alexander Klimetschek wrote:
> On Fri, Feb 26, 2010 at 15:40, Illarion Kovalchuk
> <illarion.kovalchuk <at> gmail.com> wrote:
>   
>> My task is to determine the proper JCR repository structure for storing of
>> binary data, so that I'll be able to:
>>
>> 1) Read data starting from any offset
>> 2) Write/Modify data starting from any offset
>>
>> It seems that binary properties can't be used in such way, so I need to
>> implement some logic on top of jcr... Could you help?
>>     
>
> Yes, binary properties can only be read as a whole (InputStream
> returned is read-only) and stored back as a whole (new input stream).
>
> I think the way to go is to copy the existing binary value (note: pseudo-code)
>
> node.getProperty("jcr:data").getBinary().getInputStream()
>
> into either a local file or an in-memory input stream, do your work
> there and then finally store the whole stream again
>
> node.setProperty("jcr:data", valueFactory.createBinary(stream))
>
> Regards,
> Alex
>
>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Thomas Müller | 1 Mar 2010 11:54
Favicon

Re: How to store randomly accessed data in jackrabbit?

Hi,

> we have to deal with big contents, from hundreds of megabytes
> to gigabytes, and clients will work remotely
> via internet, so they just can't get binary content as a whole, modify it
> and upload again.
>
> Is there some other way?

You could split the file into multiple objects.

Regards,
Thomas
Permalink | Reply | 2 comments |
headers
Illarion Kovalchuk | 1 Mar 2010 12:08
Picon
Gravatar

Re: How to store randomly accessed data in jackrabbit?

Thomas Müller wrote:
> Hi,
>
>   
>> we have to deal with big contents, from hundreds of megabytes
>> to gigabytes, and clients will work remotely
>> via internet, so they just can't get binary content as a whole, modify it
>> and upload again.
>>
>> Is there some other way?
>>     
>
> You could split the file into multiple objects.
>
> Regards,
> Thomas
>
>   
We will have to do so, if there is no other way. So, the question now 
transforms to following: does JCR and Jackrabbit support calculated 
Properties? I mean such properties, that could be:

1) while reading: calculated on the fly from other properties
2) while writing: not stored, but perform some code on other properties.

--

-- 
With best regards

Illarion Kovalchuk, COMODO Online Backup.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alexander Klimetschek | 1 Mar 2010 12:20
Favicon

Re: getRootNode() takes 27 seconds...

2010/2/27 François Cassistat <f <at> maya-systems.com>:
> Stefan,
>
> it seems that you are right.
>
> When using TransientRepository instead of jcr2spi, getRootNode() or getNode("/") is returned in 13ms.
>
> Somehow, it's weird that I have this problem only with the root node. I was having this problem without
doing anything between getSession and getRootNode.

Depends on the tree. If you fetch the root node and spi fetches more
than one level, you might potentially include a lot of nodes, more
compared to a more deeper subtree.

If you are using spi2davex for the remote connection, you can change
the BatchReadConfig to not fetch deeper levels. See also
http://markmail.org/message/nzcbrf27b2edkbzr for some links.

Regards,
Alex

--

-- 
Alexander Klimetschek
alexander.klimetschek <at> day.com
Permalink | Reply | 2 comments |
headers
Alexander Klimetschek | 1 Mar 2010 12:31
Favicon

Re: Storing a jackrabbit repository as versioned files in git

On Fri, Feb 26, 2010 at 19:18, Premkumar Stephen <prem18 <at> gmail.com> wrote:
> Can there be a persistence manager that generally does not need to be
> optimized but could persist just the tree structure as shown on the API
> side?

This is difficult because of:
- you need to find a way to map properties to the file system (needs
special "hidden" files or resource forks)
- current persistence interface is a simple key-value store, with the
key being the UUID of the node and the value all data of a node
(properties, child node pointers, parent pointer, metadata); the PM
does not know about the JCR level hierarchy
- ensuring consistency/transactionality is difficult w/o a log, index
and thus often a custom file format (*)

(*) the XmlPersistenceManager is probably the simplest, storing nodes
as XML files, but not based on the original hierachy, but splitting up
the UUID to generate the file system structure. And it's not safe
whatsoever, hence not recommended at all.

Note that Jackrabbit is much more than just a document (file-oriented)
storage and allows for much finer granularity (good for eg. CMS) with
many small properties. A normal file system is not very much suited
for that.

Regards,
Alex

--

-- 
Alexander Klimetschek
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thomas Müller | 1 Mar 2010 12:35
Favicon

Re: How to store randomly accessed data in jackrabbit?

Hi,

> does JCR and Jackrabbit support calculated
> Properties?

No. There is one feature that goes in this direction: observation.

See also http://www.day.com/specs/jcr/2.0/

Regards,
Thomas
Permalink | Reply | 0 comments |
headers
Robert Eichinger | 1 Mar 2010 15:52

Program blocks on setProperty() in Jackrabbit-webapp-2.0.0

Hi,

I recently started developing an application that has to keep track of
a large amount of images. I started using Jackrabbit 2.0.0 (webapp)
and I am using PostgreSQL as Database backend. The repository is being
accessed via jackrabbit-rmi. For small images (<50 kb) the whole
system works fine, but when I want to put bigger images into the
repository, the call to Node.setProperty() does not return and the
whole application hangs. A small extract of my source code:

Node imageNode = aidNode.addNode(id,"nt:file");
Node addInfoNode = imageNode.addNode("jcr:content","nt:resource");
addInfoNode.setProperty("jcr:mimeType", mimeType);
lastModified.setTimeInMillis(file.lastModified());
addInfoNode.setProperty("jcr:lastModified", lastModified);
Binary binImage = vf.createBinary(fis);
addInfoNode.setProperty("jcr:data",binaryImage);
session.save();

I  tried different ways of solving the problem with jackrabbit 2.0.0
but none of them succeeded (MySQL as backend, FS as backend, using
deprecated method Node.setProperty(String name, InputStream)). Then I
tried jackrabbit 1.6 and it works perfectly for small and large
images.

My questions now are:
Did I configure something wrong?
Did I forget to add a mixin that is required by jackrabbit 2.0.0 or JCR 2.0?
Is my way the correct way to store binary data in jackrabbit?
(Continue reading)

Permalink | Reply | 7 comments |
headers
Thomas Müller | 1 Mar 2010 15:56
Favicon

Re: Program blocks on setProperty() in Jackrabbit-webapp-2.0.0

Hi,

Could you create a full thread dump and post it? To create one, press
Ctrl+Pause (Windows) or use jsp -l / jstack <pid> / kill -QUIT <pid>

Regards,
Thomas

On Mon, Mar 1, 2010 at 3:52 PM, Robert Eichinger
<robert.eichinger.re <at> googlemail.com> wrote:
> Hi,
>
> I recently started developing an application that has to keep track of
> a large amount of images. I started using Jackrabbit 2.0.0 (webapp)
> and I am using PostgreSQL as Database backend. The repository is being
> accessed via jackrabbit-rmi. For small images (<50 kb) the whole
> system works fine, but when I want to put bigger images into the
> repository, the call to Node.setProperty() does not return and the
> whole application hangs. A small extract of my source code:
>
> Node imageNode = aidNode.addNode(id,"nt:file");
> Node addInfoNode = imageNode.addNode("jcr:content","nt:resource");
> addInfoNode.setProperty("jcr:mimeType", mimeType);
> lastModified.setTimeInMillis(file.lastModified());
> addInfoNode.setProperty("jcr:lastModified", lastModified);
> Binary binImage = vf.createBinary(fis);
> addInfoNode.setProperty("jcr:data",binaryImage);
> session.save();
>
> I  tried different ways of solving the problem with jackrabbit 2.0.0
(Continue reading)

Permalink | Reply | 6 comments |
headers
Gadbury | 1 Mar 2010 16:08

ooxml-schemas-1.0.jar; error in opening zip file


Hi all,

I decided to try upgrading from Jackrabbit 1.6.0 to 2.0.0.

Unfortunately, I am experiencing an issue relating to the
ooxml-schemas-1.0.jar.

In the error log:  "Error.  Invalid ZIP archive:
C:\maven\repo\org\apache\poi\ooxml-schemas\1.0\ooxml-schemas-1.0.jar".

I have tried removing and manually downloading and replacing this jar file
(rather than letting Maven do it's stuff), but it still fails.  Has anyone
else had any issue with this dependency?  Is there a way to substitute this
13.6MB jar for the 'lite' version instead?

Thanks for reading.  Kind regards,

James
--

-- 
View this message in context: http://n4.nabble.com/ooxml-schemas-1-0-jar-error-in-opening-zip-file-tp1573652p1573652.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Permalink | Reply | 2 comments |

Gmane