Migration from 4.1 to 5.0 and repository location

[haroldtheb]

The utilities.jar migration utility is passed a location of the repository old home and a repository new home. I have about 13GB in the repository. Does it need to be moved to a new location for the upgrade, or can the -roc and -rnc be the same argument (the current repository location)? In other words, can I do the migration without moving the repository location?

[jllort]

The repository by default is relative to your jboss.

You can migrate from openkm4 folder to openkm5 folder and after migration you can rename folder4 to openkm_old and openkm5 to you desired jboss folder name. You can move jboss folder to any computer server and then start jboss, that must run without major problems.

[haroldtheb]

My OKM 4.1 repository is in /home/repository. For purposes of backup, placing the repository under /home is preferable. I ran the upgrade command in the Migration Guide and used /home/repository-5 as the new location of the repository. When I log in to OKM 5, no documents show up under okm:root. I still have issues with the user database not working right (no other logins work), but before I give up, I want to give this one last try. How do I get my documents into the new repository location. A straight copy from /home/repository to /home/repository-5 messes things up, so that's obviously not the answer. What do I need to copy from the old to the new repository location? The Guide is not clear. I'm only a sys-admin, not a programmer, and I work with a small business that cannot afford to pay for help....

Please if anyone can post a quick howto with better detail on moving the repository and getting the user database (OKMAuth) converted from 4.1 to 5.0, I would be very appreciative.

[jllort]

In wiki is well explained http://wiki.openkm.com/index.php/Migrat ... 4.1_to_5.0, simply first make a backup ( for secutiry purpose ) and then try migration.

Code: Select all

could be something like this:
java -Xmx512m -Djava.security.auth.login.config=jaas.conf -cp utilities.jar com.openkm.util.RepositoryUpgrade
-roc /jbosshome/repository.xml
-roh /home/repository
-rnc /newjboss/repository.xml
-rnh /home/repository-5

Remember:
must create jaas.conf file as is explained in migration guide
after migration must change OpenKM.cfg ( new jboss ) to point to new /home/respository-5 ( you can rename repository-5 folder to repository folder name after migration, but not after first OpenKM starting !!! )

And there's nothing else.

[akorn]

The process described in the wiki didn't work for me.

I just got variations on the following:

Code: Select all

25/Dec/2010 16:37:46 - INFO  - ==============================
25/Dec/2010 16:37:46 - INFO  - - Old config: /etc/openkm4/repository.xml
25/Dec/2010 16:37:46 - INFO  - - Old home: /var/lib/openkm4/repository
25/Dec/2010 16:37:46 - INFO  - - New config: /etc/openkm/repository.xml
25/Dec/2010 16:37:46 - INFO  - - New home: /var/lib/openkm/repository
25/Dec/2010 16:37:46 - INFO  - ==============================
25/Dec/2010 16:38:15 - ERROR - okm: is not a registered namespace prefix.
javax.jcr.NamespaceException: okm: is not a registered namespace prefix.
        at org.apache.jackrabbit.core.NamespaceRegistryImpl.getURI(NamespaceRegistryImpl.java:429)
        at org.apache.jackrabbit.commons.AbstractSession.getNamespaceURI(AbstractSession.java:133)
        at org.apache.jackrabbit.core.SessionImpl.getURI(SessionImpl.java:741)
        at org.apache.jackrabbit.spi.commons.conversion.NameParser.parse(NameParser.java:182)
        at org.apache.jackrabbit.spi.commons.conversion.ParsingNameResolver.getQName(ParsingNameResolver.java:63)
        at org.apache.jackrabbit.spi.commons.conversion.PathParser.parse(PathParser.java:144)
        at org.apache.jackrabbit.spi.commons.conversion.PathParser.parse(PathParser.java:57)
        at org.apache.jackrabbit.spi.commons.conversion.ParsingPathResolver.getQPath(ParsingPathResolver.java:60)
        at org.apache.jackrabbit.spi.commons.conversion.CachingPathResolver.getQPath(CachingPathResolver.java:77)
        at org.apache.jackrabbit.spi.commons.conversion.DefaultNamePathResolver.getQPath(DefaultNamePathResolver.java:78)
        at org.apache.jackrabbit.core.SessionImpl.getQPath(SessionImpl.java:766)
        at org.apache.jackrabbit.core.NodeImpl.resolveRelativeNodePath(NodeImpl.java:217)
        at org.apache.jackrabbit.core.NodeImpl.hasNode(NodeImpl.java:2848)
        at com.openkm.util.RepositoryUpgrade.repositoryUpgrade(RepositoryUpgrade.java:176)
        at com.openkm.util.RepositoryUpgrade.main(RepositoryUpgrade.java:133)

as well as

Code: Select all

org.apache.jackrabbit.spi.commons.conversion.IllegalNameException: Internal error.: Unknown namespace URI: http://www.openkm.org/1.0: Namespace not registered: http://www.openkm.org/1.0: Unknown namespace URI: http://www.openkm.org/1.0: Namespace not registered: http://www.openkm.org/1.0: Namespace not registered: http://www.openkm.org/1.0

(This error gets logged on OpenKM startup too.)

What sort of worked was to export the repository from the old version using the administrator panel of the web gui, and then import it into the new version the same way. I don't know if this has any drawbacks.

[haroldtheb]

I see my problem. I failed to create the jaas.conf file. The command executed, but did not move the repository. Now that I created the jaas.conf file everything worked. Thanks for working with me.

[akorn]

I see my problem. I failed to create the jaas.conf file. The command executed, but did not move the repository. Now that I created the jaas.conf file everything worked. Thanks for working with me.

Oh yeah, that bit me once too, when I used a relative path for the jaas.conf file and tried the same command line from a different directory. The error message wasn'1 exactly helpful; I had to resort to stracing (always painful with Java) to find out what was wrong.

This may sound like trolling, but I believe no Java application is finished until all exceptions are caught and handled properly (possibly resulting in meaningful error messages). Stack traces are for developers, not users. If a situation results in a stack trace being printed instead of a useful (concise and meaningful) error message, that's a bug in my view. ("Patches welcome", I suppose.)

[pavila]

The first time you run OpenKM, this (ugly error and stacktrace) is thrown because there is no created repository and will try to create a new one. This stacktrace can't be catched, or at least I can't do it, because the message is printed inside the jackrabbit library. As you say, any patch will be welcomed

[akorn]

The first time you run OpenKM, this (ugly error and stacktrace) is thrown because there is no created repository and will try to create a new one. This stacktrace can't be catched, or at least I can't do it, because the message is printed inside the jackrabbit library. As you say, any patch will be welcomed :)

The problem was that on encountering this exception, the migration utility gave up without copying anything from the old repository to the new one. And the migration utility won't run if the target repository already exists. Thus the snake bites its own tail. :)

[pavila]

The migration process stops if the target directory exists for security reasons. This utility is not perfect and may fail in some circunstances, of course. In our test and real-world migration is working ok, buy may be your repository has any special case that the tool can't handle. Would be nice to access your repository and make some test to see why it fails, but we ony offer this service to our costumers.

The other option is to generate a sample OpenKM 4.1 repository where the migration fails and attach it to a issue report at http://issues.openkm.com. I would take a look and try to fix it soon.