I'm looking for a way to provide upload/download mechanism for blob files.
These files should be stored in a jackrabbit datasource repository. I already discovered apache Sling framework for this task but it seems that this is not applicable for lare files (BLOBs) since it has it's own jackrabbit implementation and can not be used with my jackrabbit datasource repository. Do you have any ideas on how to solve this?
See http://markmail.org/message/rcmsahf4n3olostm where your on-list question was answered.
Related
I am planning the backup strategy for my sling application. In my application users are able to register themselves and create their own content.
To be able to recover from a crash I tried to create a content package by using the composum package manager. This kind of backup works fine for the content but not for the users.
Any ideas how to backup my user-created users?
BR
Tim
From the Question, I comprehend that you have a JCR Repository as your content Repository and you have an apache sling middle ware which talks to JCR Repository.
Since Apache sling is a middleware which does not have any storage or users on its own I believe you are mentioning about Users in JCR.
Then you may try to follow this article in order to export or backup any data in XML. Content in JCR repository can be exported to xml.
https://jackrabbit.apache.org/archive/wiki/JCR/BackupAndMigration_115513344.html
I'm sorry if this sounds stupid, but what's the difference between Jackrabbit and Oak? I'm looking into JCR170, specifically how to migrate content between two jackrabbit installations, and I've come across both JackRabbit and Oak.
The Apache Jackrabbit™ content repository is a fully conforming
implementation of the Content Repository for Java Technology API (JCR,
specified in JSR 170 and JSR 283).
A content repository is a hierarchical content store with support for
structured and unstructured content, full text search, versioning,
transactions, observation, and more.
Jackrabbit Oak is a complementary implementation of the JCR
specification. It is an effort to implement a scalable and performant
hierarchical content repository for use as the foundation of modern
world-class web sites and other demanding content applications. See
the Jackrabbit Oak website for more information.
Apache Jackrabbit is a project of the Apache Software Foundation
http://jackrabbit.apache.org/jcr/index.html
Their own home page says that Jackrabbit is a content repository implementing JCR and that Oak is a complementary implementation of JCR. Why is there two implementations of JCR by the same project?
As awd mentioned in the comment, Oak is just the latest version of Jackrabbit. It is not just an update, but rather a new implementation of the same JSR170. So the API does not change, but the underlying inner workings are a bit different. You can find a lot in the documentation as Julian mentions. Some of the major changes are:
Session handling: each session gets a snapshot of the repository when it was created to prevent concurrent changes on the repo: http://jackrabbit.apache.org/oak/docs/architecture/transactional-model.html
MicroKernels: with which you can define how the repository is stored. Currently as before with tar files called tarMK or the NoSQL DB MongoDB with the mongoMK.
Here is an overview of the changes: http://jackrabbit.apache.org/oak/docs/differences.html
And a short slideshow:
https://www.slideshare.net/jukka/oak-the-architecture-of-apache-jackrabbit-3
Currently also looking at the differences between them.
Apache OAK current does not support locking (https://jira.apache.org/jira/browse/OAK-6421) and merging therefore we might use jackrabbit instead.
Is there any way of POSTing a new schema to Solr (eg. is there a handler for managing schema updates) instead of manually placing the new schema.xml in Solr home directory?
Unfortunately that's an open issue as of this writing, and there doesn't seem to be much interest to implement it.
As suggested in the comments you can work around this by setting up some external connection like WebDAV, FTP, SFTP, SCP.
The nexus book: http://www.sonatype.com/books/nexus-book/reference/. Does not seem to spend any time on how one should go about backing up a nexus repository. If I am installing my snapshot and releases into this local repository, it seems that it would behoove me to back it up. However, I'm not really interested in backing up anything that can easily be downloaded from a remote repository.
Some google searches do not seem to reveal the canonical answer either, so perhaps for posterity it can be recorded here.
Thanks,
Nathan
When you install Nexus, you'll end up with two directories:
nexus-webapp-1.3.1.1/
sonatype-work/
We've separated the application from the data and configuration. The Nexus application is in nexus-webapp-1.3.1.1/ and the data and configuration is in sonatype-work/nexus. This was mainly done to facilitate easier upgrades, but it also has the side-effect of making it very easy to backup a Nexus installation.
The Simple Answer
Nexus doesn't store repositories in a database or do anything that would preclude a simple backup of the file system under sonatype-work/nexus. If you need to create a complete backup, just archive the contents of the sonatype-work/nexus.
Better Answer
If you want a more intelligent approach to backing up a Nexus installation, you will certainly want to backup everything under sonatype-work/nexus/conf, sonatype-work/nexus/storage, sonatype-work/nexus/template-store. If you want to backup the metadata and file attributes that Nexus keeps for proxy repository, backup sonatype-work/nexus/proxy, although this isn't required as the information about the proxy repository will be generated on-demand as attributes are requested.
You don't need to backup sonatype-work/nexus/logs and you don't need to backup the Lucene indexes in sonatype-work/nexus/indexer.
Nexus Pro Answer
There is a Nexus Professional plugin which can automate the process of creating a backup of the Nexus configuration data. This plugin is going to address the contents of the sonatype-work/nexus/conf directory. If you need to backup the sonatype-work/nexus/storage directory, you will need to configure some backup system to backup the contents of that filesystem. Once again, as with Nexus Open Source, there is currently no real benefit in backing up the contents of sonatype-work/nexus/indexer or sonatype-work/nexus/logs.
Excluding Storage for Remote Repositories
In your question you mention that you want to exclude the storage devoted to the local cache of a remote repository. If you are interested in doing this, you'll have to take a further level of granularity and just exclude the directories under sonatype-work/nexus/storage that correspond to the remote repositories.
Do you need to shut Nexus down for a backup?
Brian Fox told me no, the only real chance for file contention is going to be the files in the indexer/ directory. You shouldn't have a problem backing up the sonatype-work filesystem with a running instance of Nexus.
BTW, thanks for the question, this answer will likely be incorporated into the next version of the Nexus book.
afaik nexus (free version) does not have any backup features, but it should be as simple, as knowing your companies groupId and grabbing it from the storage directories in nexus
but i would schedule a complete repository backup too, you never know when the remote repositories are down, when you need them the most
When running Apache Jackrabbit JCR as an embedded service in your app, is there a quick way to get a sound and consistent backup of the contents of the Jackrabbit repository without shutting Jackrabbit down? If so how?
See BackupAndMigration on the Jackrabbit Wiki for a list of options.
I would recommend to use XML export (system view), as it is the simplest solution. Also, because it is part of the JCR standard, so it should work on other JCR implementations as well.
Note that this approach has one drawback: it is currently not possible to re-import a full export, ie. from the root node and including the jcr:system subnode that contains the version storage, since the jcr:system part and especially the version storage are not writeable (this is mainly because JCR does not specify how to import versions). Here is some explanation on the Jackrabbit mailing list.