Recovering repository (or combining two repositories)

[Harri T.]

Hi

I have a Jackrabbit 1.3.1 repository in Liferay 4.3.4. The repository
was lost (rm -rf by accident) a month ago. Liferay created a new
Jackrabbit directory structure and after that new documents were
successfully added into the repository.

Now I found a snapshot of the original directory structure and files.

Can I some how combine the original and the new repository into one
working repository?

-Harri

[Alexander Klimetschek]

On Tue, Jun 30, 2009 at 10:25 PM, Harri T.<[hidden email]> wrote:

> Hi
>
> I have a Jackrabbit 1.3.1 repository in Liferay 4.3.4. The repository was
> lost (rm -rf by accident) a month ago. Liferay created a new Jackrabbit
> directory structure and after that new documents were successfully added
> into the repository.
>
> Now I found a snapshot of the original directory structure and files.
>
> Can I some how combine the original and the new repository into one working
> repository?

If you use the datastore (not sure if it was available in 1.3
already), you could merge the folder/file structure, since they use
UUIDs and are therefore unqiue. But this doesn't give you the actual
JCR node structure, only the underlying binaries.

Therefore I think the best solution is to write a merging tool on the
JCR level. Setup access to two repositories, the recovered old one and
the new one, and copy over date from the old one into the new one (or
the other way around, whatever suits you best).

Regards,
Alex

--
Alexander Klimetschek
[hidden email]

[Harri T.]

On 01.07.2009 12:26 Alexander Klimetschek wrote:
> On Tue, Jun 30, 2009 at 10:25 PM, Harri T.<[hidden email]> wrote:
>>
>> Can I some how combine the original and the new repository into one
>> working repository?
>
> If you use the datastore (not sure if it was available in 1.3
> already), you could merge the folder/file structure, since they use
> UUIDs and are therefore unqiue.

Hi Alexander and thanks for answering!

I recovered the old Jackrabbit directory structure snapshot and
copied/merged the new snapshot onto same directory structure. They had
some same files:
./repository.xml
./home/workspaces/liferay/workspace.xml
./home/workspaces/liferay/data/cafe/babe/cafebabecafebabecafebabe/.node.xml
./home/workspaces/liferay/data/cafe/babe/cafebabecafebabecafebabe/672388333465d36a71297afb5d46001f.xml
./home/workspaces/liferay/data/dead/beef/cafebabecafebabecafebabe/.node.xml
./home/workspaces/liferay/data/dead/beef/cafebabecafebabecafebabe/672388333465d36a71297afb5d46001f.xml
./home/workspaces/liferay/locks
./home/repository/meta/rootUUID
./home/repository/meta/rep.properties
./home/repository/namespaces/ns_reg.properties
./home/repository/namespaces/ns_idx.properties
./home/version/data/dead/beef/facebabecafebabecafebabe/.node.xml
./home/version/data/dead/beef/facebabecafebabecafebabe/672388333465d36a71297afb5d46001f.xml

So, some files from the old snapshot were overwritten by the files from
the new snapshot. After this operation only the new files were accessible.

What do you mean by "using the datastore"? How can I check the issue?

-Harri

[Alexander Klimetschek]

On Wed, Jul 1, 2009 at 9:50 PM, Harri T.<[hidden email]> wrote:

> On 01.07.2009 12:26 Alexander Klimetschek wrote:
>>
>> On Tue, Jun 30, 2009 at 10:25 PM, Harri T.<[hidden email]> wrote:
>>>
>>> Can I some how combine the original and the new repository into one
>>> working repository?
>>
>> If you use the datastore (not sure if it was available in 1.3 already),
>> you could merge the folder/file structure, since they use UUIDs and are
>> therefore unqiue.
>
> Hi Alexander and thanks for answering!
>
> I recovered the old Jackrabbit directory structure snapshot and
> copied/merged the new snapshot onto same directory structure. They had some
> same files:
> ./repository.xml
> ./home/workspaces/liferay/workspace.xml
> ./home/workspaces/liferay/data/cafe/babe/cafebabecafebabecafebabe/.node.xml
> ./home/workspaces/liferay/data/cafe/babe/cafebabecafebabecafebabe/672388333465d36a71297afb5d46001f.xml
> ./home/workspaces/liferay/data/dead/beef/cafebabecafebabecafebabe/.node.xml
> ./home/workspaces/liferay/data/dead/beef/cafebabecafebabecafebabe/672388333465d36a71297afb5d46001f.xml
> ./home/workspaces/liferay/locks
> ./home/repository/meta/rootUUID
> ./home/repository/meta/rep.properties
> ./home/repository/namespaces/ns_reg.properties
> ./home/repository/namespaces/ns_idx.properties
> ./home/version/data/dead/beef/facebabecafebabecafebabe/.node.xml
> ./home/version/data/dead/beef/facebabecafebabecafebabe/672388333465d36a71297afb5d46001f.xml
>
> So, some files from the old snapshot were overwritten by the files from the
> new snapshot. After this operation only the new files were accessible.
>
> What do you mean by "using the datastore"? How can I check the issue?

Depends on your repository.xml configuration. From the above, it looks
like you are using the XML persistence manager, which is not the best
choice. I'd suggest you'd upgrade to the newest Jackrabbit (1.5.x) and
use a bundle database persistence manager + the data store for binary
data (I just noted it was introduced with 1.4, so you couldn't be
using it ;-)). See the following links:

http://jackrabbit.apache.org/jackrabbit-configuration.html
http://wiki.apache.org/jackrabbit/PersistenceManagerFAQ
http://wiki.apache.org/jackrabbit/DataStore

Regards,
Alex

--
Alexander Klimetschek
[hidden email]

[Harri T.]

On 02.07.2009 00:36 Alexander Klimetschek wrote:
>
> I'd suggest you'd upgrade to the newest Jackrabbit (1.5.x) and use a
> bundle database persistence manager + the data store for binary data
> (I just noted it was introduced with 1.4, so you couldn't be using it
> ;-)).

Does this help now, when I already have those too "old fashioned"
repositories? I mean... can I merge them after taking data stores in use?

Jackrabbit Standalone 1.5 seems to be backwards compatible with 1.3.1
repository. Can I merge two repositories by running two different JCRs
and implementing a Java application for merge operation?

|/*
java -jar jackrabbit-standalone-1.5.5.jar -p 8080 -r
snapshots/jackrabbit.current
java -jar jackrabbit-standalone-1.5.5.jar -p 8081 -r
snapshots/jackrabbit.old
*/

public static void main(String[] args) throws Exception {
    Repository dstRepository = new
URLRemoteRepository("http://localhost:8080/rmi");
||    Repository srcRepository = new
URLRemoteRepository("http://localhost:8081/rmi");
||    //TODO: Traverse recursively through the source repository and add
nodes to the destination repository.
}

|?

-Harri

[Harri T.]

On 02.07.2009 00:36 Alexander Klimetschek wrote:
>
> I'd suggest you'd upgrade to the newest Jackrabbit (1.5.x) and use a
> bundle database persistence manager + the data store for binary data
> (I just noted it was introduced with 1.4, so you couldn't be using it
> ;-)).

Does this help now, when I already have those too "old fashioned"
repositories? I mean... can I merge them after taking data stores in use?

Jackrabbit Standalone 1.5 seems to be backwards compatible with 1.3.1
repository. Can I merge two repositories by running two different JCRs
and implementing a Java application for merge operation?

/*
    java -jar jackrabbit-standalone-1.5.5.jar -p 8080 -r
snapshots/jackrabbit.current
    java -jar jackrabbit-standalone-1.5.5.jar -p 8081 -r
snapshots/jackrabbit.old
*/

public static void main(String[] args) throws Exception {
    Repository dstRepository = new
URLRemoteRepository("http://localhost:8080/rmi");
    Repository srcRepository = new
URLRemoteRepository("http://localhost:8081/rmi");
    // TODO: Traverse recursively through the source repository and add
nodes to the destination repository.
}

?

-Harri

[Harri T.]

On 09.07.2009 00:19 Harri T. wrote:
> Can I merge two repositories by running two different JCRs and
> implementing a Java application for merge operation?

I'm trying to implement a utility for accessing two different Jackrabbit
repositories for merging nodes from one repository to another. The both
repositories are created by Liferay Portal 4.3.4 and as far as I
understand, the Jackrabbit version is 1.3.1.

I installed the 1.3.1. web app, configured it to used one of the Liferay
Jackrabbit repository snapshots and wrote a short program for utilizing it:

    public static void main(String[] args) throws Exception {
        ClientRepositoryFactory factory = new ClientRepositoryFactory();
        Repository repository = factory.getRepository(
                "rmi://localhost:1099/jackrabbit.repository");
        Session session = repository.login();
        traverseNodes(session.getRootNode());
    }

    private static void traverseNodes(Node node) throws Exception {
        System.out.println(node.getPath());
        NodeIterator children = node.getNodes();
        while (children.hasNext()) {
            traverseNodes(children.nextNode());
        }
    }

However, I can't find no file items from the repository. See the output
below. What is wrong with the program?

-Harri

/
/jcr:system
/jcr:system/jcr:versionStorage
/jcr:system/jcr:nodeTypes
/jcr:system/jcr:nodeTypes/rep:nodeTypes
/jcr:system/jcr:nodeTypes/rep:nodeTypes/jcr:childNodeDefinition
/jcr:system/jcr:nodeTypes/mix:versionable
/jcr:system/jcr:nodeTypes/mix:versionable/jcr:propertyDefinition
/jcr:system/jcr:nodeTypes/mix:versionable/jcr:propertyDefinition[2]
/jcr:system/jcr:nodeTypes/mix:versionable/jcr:propertyDefinition[3]
/jcr:system/jcr:nodeTypes/mix:versionable/jcr:propertyDefinition[4]
/jcr:system/jcr:nodeTypes/mix:versionable/jcr:propertyDefinition[5]
/jcr:system/jcr:nodeTypes/nt:file
/jcr:system/jcr:nodeTypes/nt:file/jcr:childNodeDefinition
/jcr:system/jcr:nodeTypes/nt:hierarchyNode
/jcr:system/jcr:nodeTypes/nt:hierarchyNode/jcr:propertyDefinition
/jcr:system/jcr:nodeTypes/nt:versionedChild
/jcr:system/jcr:nodeTypes/nt:versionedChild/jcr:propertyDefinition
/jcr:system/jcr:nodeTypes/nt:version
/jcr:system/jcr:nodeTypes/nt:version/jcr:propertyDefinition
/jcr:system/jcr:nodeTypes/nt:version/jcr:propertyDefinition[2]
/jcr:system/jcr:nodeTypes/nt:version/jcr:propertyDefinition[3]
/jcr:system/jcr:nodeTypes/nt:version/jcr:childNodeDefinition
/jcr:system/jcr:nodeTypes/nt:versionLabels
/jcr:system/jcr:nodeTypes/nt:versionLabels/jcr:propertyDefinition
/jcr:system/jcr:nodeTypes/nt:folder
/jcr:system/jcr:nodeTypes/nt:folder/jcr:childNodeDefinition
/jcr:system/jcr:nodeTypes/rep:versionStorage
/jcr:system/jcr:nodeTypes/rep:versionStorage/jcr:childNodeDefinition
/jcr:system/jcr:nodeTypes/rep:versionStorage/jcr:childNodeDefinition[2]
/jcr:system/jcr:nodeTypes/nt:propertyDefinition
/jcr:system/jcr:nodeTypes/nt:propertyDefinition/jcr:propertyDefinition
/jcr:system/jcr:nodeTypes/nt:propertyDefinition/jcr:propertyDefinition[2]
/jcr:system/jcr:nodeTypes/nt:propertyDefinition/jcr:propertyDefinition[3]
/jcr:system/jcr:nodeTypes/nt:propertyDefinition/jcr:propertyDefinition[4]
/jcr:system/jcr:nodeTypes/nt:propertyDefinition/jcr:propertyDefinition[5]
/jcr:system/jcr:nodeTypes/nt:propertyDefinition/jcr:propertyDefinition[6]
/jcr:system/jcr:nodeTypes/nt:propertyDefinition/jcr:propertyDefinition[7]
/jcr:system/jcr:nodeTypes/nt:propertyDefinition/jcr:propertyDefinition[8]
/jcr:system/jcr:nodeTypes/nt:propertyDefinition/jcr:propertyDefinition[9]
/jcr:system/jcr:nodeTypes/nt:nodeType
/jcr:system/jcr:nodeTypes/nt:nodeType/jcr:propertyDefinition
/jcr:system/jcr:nodeTypes/nt:nodeType/jcr:propertyDefinition[2]
/jcr:system/jcr:nodeTypes/nt:nodeType/jcr:propertyDefinition[3]
/jcr:system/jcr:nodeTypes/nt:nodeType/jcr:propertyDefinition[4]
/jcr:system/jcr:nodeTypes/nt:nodeType/jcr:propertyDefinition[5]
/jcr:system/jcr:nodeTypes/nt:nodeType/jcr:childNodeDefinition
/jcr:system/jcr:nodeTypes/nt:nodeType/jcr:childNodeDefinition[2]
/jcr:system/jcr:nodeTypes/nt:base
/jcr:system/jcr:nodeTypes/nt:base/jcr:propertyDefinition
/jcr:system/jcr:nodeTypes/nt:base/jcr:propertyDefinition[2]
/jcr:system/jcr:nodeTypes/nt:childNodeDefinition
/jcr:system/jcr:nodeTypes/nt:childNodeDefinition/jcr:propertyDefinition
/jcr:system/jcr:nodeTypes/nt:childNodeDefinition/jcr:propertyDefinition[2]
/jcr:system/jcr:nodeTypes/nt:childNodeDefinition/jcr:propertyDefinition[3]
/jcr:system/jcr:nodeTypes/nt:childNodeDefinition/jcr:propertyDefinition[4]
/jcr:system/jcr:nodeTypes/nt:childNodeDefinition/jcr:propertyDefinition[5]
/jcr:system/jcr:nodeTypes/nt:childNodeDefinition/jcr:propertyDefinition[6]
/jcr:system/jcr:nodeTypes/nt:childNodeDefinition/jcr:propertyDefinition[7]
/jcr:system/jcr:nodeTypes/nt:childNodeDefinition/jcr:propertyDefinition[8]
/jcr:system/jcr:nodeTypes/nt:resource
/jcr:system/jcr:nodeTypes/nt:resource/jcr:propertyDefinition
/jcr:system/jcr:nodeTypes/nt:resource/jcr:propertyDefinition[2]
/jcr:system/jcr:nodeTypes/nt:resource/jcr:propertyDefinition[3]
/jcr:system/jcr:nodeTypes/nt:resource/jcr:propertyDefinition[4]
/jcr:system/jcr:nodeTypes/mix:referenceable
/jcr:system/jcr:nodeTypes/mix:referenceable/jcr:propertyDefinition
/jcr:system/jcr:nodeTypes/nt:versionHistory
/jcr:system/jcr:nodeTypes/nt:versionHistory/jcr:propertyDefinition
/jcr:system/jcr:nodeTypes/nt:versionHistory/jcr:childNodeDefinition
/jcr:system/jcr:nodeTypes/nt:versionHistory/jcr:childNodeDefinition[2]
/jcr:system/jcr:nodeTypes/nt:versionHistory/jcr:childNodeDefinition[3]
/jcr:system/jcr:nodeTypes/nt:unstructured
/jcr:system/jcr:nodeTypes/nt:unstructured/jcr:propertyDefinition
/jcr:system/jcr:nodeTypes/nt:unstructured/jcr:propertyDefinition[2]
/jcr:system/jcr:nodeTypes/nt:unstructured/jcr:childNodeDefinition
/jcr:system/jcr:nodeTypes/mix:lockable
/jcr:system/jcr:nodeTypes/mix:lockable/jcr:propertyDefinition
/jcr:system/jcr:nodeTypes/mix:lockable/jcr:propertyDefinition[2]
/jcr:system/jcr:nodeTypes/nt:frozenNode
/jcr:system/jcr:nodeTypes/nt:frozenNode/jcr:propertyDefinition
/jcr:system/jcr:nodeTypes/nt:frozenNode/jcr:propertyDefinition[2]
/jcr:system/jcr:nodeTypes/nt:frozenNode/jcr:propertyDefinition[3]
/jcr:system/jcr:nodeTypes/nt:frozenNode/jcr:propertyDefinition[4]
/jcr:system/jcr:nodeTypes/nt:frozenNode/jcr:propertyDefinition[5]
/jcr:system/jcr:nodeTypes/nt:frozenNode/jcr:childNodeDefinition
/jcr:system/jcr:nodeTypes/rep:system
/jcr:system/jcr:nodeTypes/rep:system/jcr:childNodeDefinition
/jcr:system/jcr:nodeTypes/rep:system/jcr:childNodeDefinition[2]
/jcr:system/jcr:nodeTypes/rep:system/jcr:childNodeDefinition[3]
/jcr:system/jcr:nodeTypes/rep:root
/jcr:system/jcr:nodeTypes/rep:root/jcr:childNodeDefinition
/jcr:system/jcr:nodeTypes/nt:query
/jcr:system/jcr:nodeTypes/nt:query/jcr:propertyDefinition
/jcr:system/jcr:nodeTypes/nt:query/jcr:propertyDefinition[2]
/jcr:system/jcr:nodeTypes/nt:linkedFile
/jcr:system/jcr:nodeTypes/nt:linkedFile/jcr:propertyDefinition

[Alexander Klimetschek]

On Thu, Jul 9, 2009 at 9:45 AM, Harri T.<[hidden email]> wrote:
>       Session session = repository.login();

I guess access control is not present? 1.3.1 only has the simple
access model that only differentiates between normal user and admin
user (if user id is "admin"), but it could be that there is a custom
access manager present, so you might need to login with different
credentials.

Regards,
Alex

--
Alexander Klimetschek
[hidden email]

[Harri T.]

On 09.07.2009 11:50 Alexander Klimetschek wrote:
> On Thu, Jul 9, 2009 at 9:45 AM, Harri T.<[hidden email]> wrote:
>>       Session session = repository.login();
>
> I guess access control is not present? 1.3.1 only has the simple
> access model that only differentiates between normal user and admin
> user (if user id is "admin"), but it could be that there is a custom
> access manager present, so you might need to login with different
> credentials.

repository.xml seems to have a security element:

        <Security appName="Jackrabbit">
                <AccessManager
class="org.apache.jackrabbit.core.security.SimpleAccessManager" />
                <LoginModule
class="org.apache.jackrabbit.core.security.SimpleLoginModule">
                        <param name="anonymousId" value="anonymous" />
                </LoginModule>
        </Security>

Now I tried both of these login methods:

        Session session = repository.login(new
SimpleCredentials("admin", new char[]{}));
        Session session = repository.login(new
SimpleCredentials("anonymous", new char[]{}));

However, I get always the previously described output.

-Harri

[Alexander Klimetschek]

On Thu, Jul 9, 2009 at 11:16 AM, Harri T.<[hidden email]> wrote:

> repository.xml seems to have a security element:
>
>       <Security appName="Jackrabbit">
>               <AccessManager
> class="org.apache.jackrabbit.core.security.SimpleAccessManager" />
>               <LoginModule
> class="org.apache.jackrabbit.core.security.SimpleLoginModule">
>                       <param name="anonymousId" value="anonymous" />
>               </LoginModule>
>       </Security>

Yes, this is the standard config for pre-1.5 Jackrabbit and works as I
described before. So this shouldn't be your problem.

> Now I tried both of these login methods:
>
>       Session session = repository.login(new SimpleCredentials("admin", new
> char[]{}));
>       Session session = repository.login(new SimpleCredentials("anonymous",
> new char[]{}));
>
> However, I get always the previously described output.

Ok, access control ruled out. Can you see the repository content in a
different way (eg. through Liferay)? Are you sure you connect to the
same repository? Maybe Liferay uses a different workspace?

Regards,
Alex

--
Alexander Klimetschek
[hidden email]

[Harri T.]

On 09.07.2009 12:34 Alexander Klimetschek wrote:
>
> Ok, access control ruled out. Can you see the repository content in a
> different way (eg. through Liferay)?

Yes, I can.

> Are you sure you connect to the same repository?

Yes, I think. There's a row in a Tomcat log telling the repository location.

I use the default repository.xml, which can be seen here:
http://svn.liferay.com/repos/public/portal/tags/4.3.4/portal-impl/src/com/liferay/portal/jcr/jackrabbit/dependencies/repository.xml

> Maybe Liferay uses a different workspace?

There's only one workspace called "liferay". The directory
jackrabbit/workspaces contains a single directory called "liferay".

Logging in like this

        Session session = repository.login(new SimpleCredentials("admin"
/* or "anonymous" */,
                new char[]{}), "liferay");

gives out the previously described content.

-Harri

[Alexander Klimetschek]

On Thu, Jul 9, 2009 at 12:59 PM, Harri T.<[hidden email]> wrote:

> There's only one workspace called "liferay". The directory
> jackrabbit/workspaces contains a single directory called "liferay".
>
> Logging in like this
>
>       Session session = repository.login(new SimpleCredentials("admin" /* or
> "anonymous" */,
>               new char[]{}), "liferay");
>
> gives out the previously described content.

Hmm. And you don't get any exception in your node listing application?
It could be that there are problems in the jcr:system tree (I remember
that I had that before, when going through that one). Try and exclude
the "jcr:system" tree in your output.

Regards,
Alex


--
Alexander Klimetschek
[hidden email]

[Harri T.]

On 09.07.2009 14:03 Alexander Klimetschek wrote:

> On Thu, Jul 9, 2009 at 12:59 PM, Harri T.<[hidden email]> wrote:
>> There's only one workspace called "liferay". The directory
>> jackrabbit/workspaces contains a single directory called "liferay".
>>
>> Logging in like this
>>
>>       Session session = repository.login(new
>> SimpleCredentials("admin" /* or
>> "anonymous" */,
>>               new char[]{}), "liferay");
>>
>> gives out the previously described content.
>
> Hmm. And you don't get any exception in your node listing application?

There's no exception in server.log or at the client end.

> It could be that there are problems in the jcr:system tree (I remember
> that I had that before, when going through that one). Try and exclude
> the "jcr:system" tree in your output.

Do you mean like this?

    private static void traverseNodes(Node node) throws Exception {
        if ("jcr:system".equals(node.getName())) {
            return;
        }
        System.out.println(node.getPath());
        NodeIterator children = node.getNodes();
        while (children.hasNext()) {
            traverseNodes(children.nextNode());
        }
    }

Now the output is just a single line:

/

-Harri

[Alexander Klimetschek]

On Thu, Jul 9, 2009 at 1:52 PM, Harri T.<[hidden email]> wrote:

> Do you mean like this?
>
>   private static void traverseNodes(Node node) throws Exception {
>       if ("jcr:system".equals(node.getName())) {
>           return;
>       }
>       System.out.println(node.getPath());
>       NodeIterator children = node.getNodes();
>       while (children.hasNext()) {
>           traverseNodes(children.nextNode());
>       }
>   }
>
> Now the output is just a single line:
>
> /

Well, then I guess the problem must be that you connect to the wrong
repository. Is "rmi://localhost:1099/jackrabbit.repository" really the
liferay repo?

Regards,
Alex

--
Alexander Klimetschek
[hidden email]

[Harri T.]

On 09.07.2009 15:08 Alexander Klimetschek wrote:
> Is "rmi://localhost:1099/jackrabbit.repository" really the liferay repo?
>  

This is, what I've done this far:

   1. Copied Liferay jackrabbit directory to a fresh location: cp -ar
      liferay/jackrabbit /fresh/location/
   2. Installed Jackrabbit 1.3.1 web app.
   3. Used Jackrabbit configuration tool
      http://localhost:8080/jackrabbit-webapp-1.3.1/bootstrap/missing.html
      to set the repository location to: /fresh/location/jackrabbit
   4. Checked the server log (see the attachment) and among others,
      there's these two lines:
      repositoryConfig: /fresh/location/jackrabbit/repository.xml
      (AbstractConfig.java, line 106)
      AbstractConfig:   rmiUri: //localhost:1099/jackrabbit.repository
      (AbstractConfig.java, line 106)
   5. The repository.xml is identical to this one:
      http://svn.liferay.com/repos/public/portal/tags/4.3.4/portal-impl/src/com/liferay/portal/jcr/jackrabbit/dependencies/repository.xml

So, I think that "rmi://localhost:1099/jackrabbit.repository" is the
right context name.

-Harri

Deploying web application archive jackrabbit-webapp-1.3.1.war
RepositoryStartupServlet: RepositoryStartupServlet initializing... (RepositoryStartupServlet.java, line 233)
AbstractConfig: Configuration of BootstrapConfig (AbstractConfig.java, line 101)
AbstractConfig: ---------------------------------------------- (AbstractConfig.java, line 102)
AbstractConfig:   valid: true (AbstractConfig.java, line 106)
AbstractConfig:   rmiConfig: org.apache.jackrabbit.j2ee.RMIConfig@4aeaf40c (AbstractConfig.java, line 106)
AbstractConfig:   repositoryConfig: /fresh/location/jackrabbit/repository.xml (AbstractConfig.java, line 106)
AbstractConfig:   class: class org.apache.jackrabbit.j2ee.BootstrapConfig (AbstractConfig.java, line 106)
AbstractConfig:   repositoryHome: /fresh/location/jackrabbit (AbstractConfig.java, line 106)
AbstractConfig:   repositoryName: jackrabbit.repository (AbstractConfig.java, line 106)
AbstractConfig:   jndiConfig: org.apache.jackrabbit.j2ee.JNDIConfig@73c6641 (AbstractConfig.java, line 106)
AbstractConfig: ---------------------------------------------- (AbstractConfig.java, line 108)
AbstractConfig: Configuration of JNDIConfig (AbstractConfig.java, line 101)
AbstractConfig: ---------------------------------------------- (AbstractConfig.java, line 102)
AbstractConfig:   valid: true (AbstractConfig.java, line 106)
AbstractConfig:   jndiName: jackrabbit.repository (AbstractConfig.java, line 106)
AbstractConfig:   jndiEnabled: true (AbstractConfig.java, line 106)
AbstractConfig:   class: class org.apache.jackrabbit.j2ee.JNDIConfig (AbstractConfig.java, line 106)
AbstractConfig:   jndiEnv: {java.naming.provider.url=http://www.apache.org/jackrabbit, java.naming.factory.initial=org.apache.jackrabbit.core.jndi.provider.DummyInitialContextFactory} (AbstractConfig.java, line 106)
AbstractConfig: ---------------------------------------------- (AbstractConfig.java, line 108)
AbstractConfig: Configuration of RMIConfig (AbstractConfig.java, line 101)
AbstractConfig: ---------------------------------------------- (AbstractConfig.java, line 102)
AbstractConfig:   valid: true (AbstractConfig.java, line 106)
AbstractConfig:   rmiName: jackrabbit.repository (AbstractConfig.java, line 106)
AbstractConfig:   class: class org.apache.jackrabbit.j2ee.RMIConfig (AbstractConfig.java, line 106)
AbstractConfig:   rmiUri: //localhost:1099/jackrabbit.repository (AbstractConfig.java, line 106)
AbstractConfig:   rmiPort: 1099 (AbstractConfig.java, line 106)
AbstractConfig:   rmiEnabled: true (AbstractConfig.java, line 106)
AbstractConfig:   rmiHost: localhost (AbstractConfig.java, line 106)
AbstractConfig: ---------------------------------------------- (AbstractConfig.java, line 108)
RepositoryImpl: Starting repository... (RepositoryImpl.java, line 223)
LocalFileSystem: LocalFileSystem initialized at path /fresh/location/jackrabbit/repository (LocalFileSystem.java, line 166)
NodeTypeRegistry: no custom node type definitions found (NodeTypeRegistry.java, line 839)
LocalFileSystem: LocalFileSystem initialized at path /fresh/location/jackrabbit/version (LocalFileSystem.java, line 166)
LocalFileSystem: LocalFileSystem initialized at path /fresh/location/jackrabbit/version/blobs (LocalFileSystem.java, line 166)
RepositoryImpl: initializing workspace 'liferay'... (RepositoryImpl.java, line 1690)
LocalFileSystem: LocalFileSystem initialized at path /fresh/location/jackrabbit/workspaces/liferay (LocalFileSystem.java, line 166)
LocalFileSystem: LocalFileSystem initialized at path /fresh/location/jackrabbit/workspaces/liferay/blobs (LocalFileSystem.java, line 166)
RepositoryImpl: workspace 'liferay' initialized (RepositoryImpl.java, line 1731)
RepositoryImpl: Repository started (RepositoryImpl.java, line 322)
RepositoryStartupServlet: Repository bound via RMI with name: //localhost:1099/jackrabbit.repository (RepositoryStartupServlet.java, line 539)
RepositoryStartupServlet: Repository bound to JNDI with name: jackrabbit.repository (RepositoryStartupServlet.java, line 431)
RepositoryStartupServlet: RepositoryStartupServlet initialized. (RepositoryStartupServlet.java, line 239)
RepositoryAccessServlet: RepositoryAccessServlet initialized. (RepositoryAccessServlet.java, line 90)
SimpleWebdavServlet: resource-path-prefix = '/repository' (SimpleWebdavServlet.java, line 151)
SimpleWebdavServlet: WWW-Authenticate header = 'Basic realm="Jackrabbit Webdav Server"' (SimpleWebdavServlet.java, line 157)

[Alexander Klimetschek]

On Thu, Jul 9, 2009 at 3:18 PM, Harri T.<[hidden email]> wrote:
>  1. Copied Liferay jackrabbit directory to a fresh location: cp -ar
>     liferay/jackrabbit /fresh/location/

Are the workspaces copied as well? The XMLPersistenceManager is used,
so all data should be in folders inside
/fresh/location/jackrabbit/workspaces/liferay (after copying, before
starting the repository). If they are empty, they will be created upon
startup, and the workspace will be empty.

Regards,
Alex

--
Alexander Klimetschek
[hidden email]

[Harri T.]

On 09.07.2009 17:00 Alexander Klimetschek wrote:
>
> The XMLPersistenceManager is used, so all data should be in folders
> inside /fresh/location/jackrabbit/workspaces/liferay (after copying,
> before
> starting the repository). If they are empty, they will be created upon
> startup, and the workspace will be empty.

The workspaces are copied as well.

Liferay seems to use TransientRepository with a separate repository home
parameter:
http://svn.liferay.com/repos/public/portal/tags/4.3.4/portal-impl/src/com/liferay/portal/jcr/jackrabbit/JCRFactoryImpl.java

The value for the home parameter seems to be
"/fresh/location/jackrabbit/home" and this directory exists.

Maybe I should use also TransientRepository...

-Harri

[Alexander Klimetschek]

On Thu, Jul 9, 2009 at 4:11 PM, Harri T.<[hidden email]> wrote:

> On 09.07.2009 17:00 Alexander Klimetschek wrote:
>>
>> The XMLPersistenceManager is used, so all data should be in folders inside
>> /fresh/location/jackrabbit/workspaces/liferay (after copying, before
>> starting the repository). If they are empty, they will be created upon
>> startup, and the workspace will be empty.
>
> The workspaces are copied as well.
>
> Liferay seems to use TransientRepository with a separate repository home
> parameter:
> http://svn.liferay.com/repos/public/portal/tags/4.3.4/portal-impl/src/com/liferay/portal/jcr/jackrabbit/JCRFactoryImpl.java
>
> The value for the home parameter seems to be
> "/fresh/location/jackrabbit/home" and this directory exists.

Well, a repository home of /fresh/location/jackrabbit/home !=
/fresh/location/jackrabbit ;-)

The repository home in the jackrabbit-webapp case is defined in the
web.xml or in the bootstrap.properties, so you should change it.

Regards,
Alex

--
Alexander Klimetschek
[hidden email]

[Harri T.]

On 09.07.2009 17:41 Alexander Klimetschek wrote:
>
> Well, a repository home of /fresh/location/jackrabbit/home !=
> /fresh/location/jackrabbit ;-)

Yes, that was the problem. Now can I traverse through the real content.
Thanks a lot Alexander for helping!

-Harri