Error during OAI import

85 views
Skip to first unread message

euler

unread,
Oct 9, 2019, 5:52:04 AM10/9/19
to DSpace Technical Support
Dear All,

When I run oai import, I encountered the following error:

$ ./dspace oai import -c -o
OAI 2.0 manager action started
Clearing index
Index cleared
Using full import.
Full import
java.lang.NoSuchMethodError: org.dspace.content.service.ItemService.findInArchiveOrWithdrawnNonDiscoverableModifiedSince(Lorg/dspace/core/Context;Ljava/util/Date;)Ljava/util/Iterator;
        at org.dspace.xoai.app.XOAI.indexAll(XOAI.java:226)
        at org.dspace.xoai.app.XOAI.index(XOAI.java:134)
        at org.dspace.xoai.app.XOAI.main(XOAI.java:560)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
        at java.lang.reflect.Method.invoke(Unknown Source)
        at org.dspace.app.launcher.ScriptLauncher.runOneCommand(ScriptLauncher.java:229)
        at org.dspace.app.launcher.ScriptLauncher.main(ScriptLauncher.java:81)

What could be the reason for this error? I have also a different repository with an almost identical configurations but I'm not having this issue. I am running DSpace version 6.1 XMLUI Mirage2 on Windows Server 2012. Any help would be greatly appreciated.

Thanks in advance,
euler

Tim Donohue

unread,
Oct 9, 2019, 2:54:22 PM10/9/19
to euler, DSpace Technical Support
Hi euler,

That "ItemService
.findInArchiveOrWithdrawnNonDiscoverableModifiedSince()" method did not created until version 6.3.  So, it sounds to me like you have somehow got some 6.3 related code or JARs running in your 6.1 installation?  You should either upgrade to 6.3, or rebuild/reinstall 6.1 by running "mvn -U clean package" (which should clear out any old JARs before rebuilding).

Good luck,

Tim

From: dspac...@googlegroups.com <dspac...@googlegroups.com> on behalf of euler <esn...@seafdec.org.ph>
Sent: Wednesday, October 9, 2019 4:52 AM
To: DSpace Technical Support <dspac...@googlegroups.com>
Subject: [dspace-tech] Error during OAI import
 
--
All messages to this mailing list should adhere to the DuraSpace Code of Conduct: https://duraspace.org/about/policies/code-of-conduct/
---
You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-tech/9de395e4-0882-4b4c-84ed-d12428ac7719%40googlegroups.com.

euler

unread,
Oct 11, 2019, 6:06:49 AM10/11/19
to DSpace Technical Support
Hi Tim,

I installed this DSpace instance using Git checkout when the latest stable release was still version 6.1. I tried many ways to upgrade to 6.3 as you suggested but by using Git and Intellij. After I committed all my local changes in my local branch, I then rebased it to version 6.3. I Did an mvn clean -U package, but after the webapps were deployed, I'm still having the same issue. If I run ./dspace version, it is showing that the version is still 6.1, although, in the web admin control panel, it says 6.3. I also tried deleting all my local and remote tags and then rebasing my local branch onto dspace-6.3 from upstream which points directly to https://github.com/DSpace/DSpace. I also tried merging instead of rebasing but still, my issue persists. I did my rebasing based on these resources: https://blog.jessitron.com/2012/10/13/git-rebase-inside-intellij-idea/. So my additional question now is, what is the best practice in DSpace when rebasing to the latest stable version? Is there a special way on how to rebase my local branch to the latest stable tag release? If I compare my local branch to the tag where I rebased it from, it says that my local branch is fully merged. I'm wondering why my version remained 6.1 despite I rebased it to 6.3? Although looking at the pom files, it is 6.3 but since you state that the error I receive when running oai import was due to the fact that the method was not created until version 6.3. I also don't know why mvn clean -U package has no effect because it obviously did not clear old JARs.

Thanks in advance!
euler
To unsubscribe from this group and stop receiving emails from it, send an email to dspac...@googlegroups.com.

Tim Donohue

unread,
Oct 11, 2019, 1:12:06 PM10/11/19
to euler, DSpace Technical Support
Hi Euler,

Unfortunately, Git questions are extremely difficult to give accurate answers on, as how you are using Git can differ (there are many different strategies that different institutions use based on their one preference/needs).

Just *one* strategy (that I've seen used) is to create your own custom branch for your site and merge in new versions of the DSpace code when doing an upgrade.  In this strategy, you'd do something like:

1) Start your custom branch (named "mysite" in this example) from the DSpace v6.1 tag on a custom fork of the DSpace/DSpace repository, e.g.

git checkout -b mysite dspace-6.1

2) Then make any changes to the "mysite" branch that you need.  Doing a "git commit" for each.

3) When it's time to upgrade, merge in the new release of DSpace (in this case the DSpace v6.3 tag), e.g.

git checkout mysite
git merge dspace-6.3

The merge here might create merge conflicts (if you've changed files also changed in the new release).  So, you may need to work through merge conflicts file by file before you can commit the changes back to your "mysite" branch.  It's also possible to use "git diff" commands to see the differences before doing a merge, e.g.

git diff dspace-6.1..mysite  (see changes between mysite and v6.1, to see what you've customized)
git diff dspace-6.1..dspace-6.3 (see the changes in DSpace between v6.1 and 6.3)

I don't have any advice on doing this in IntelliJ, as I'm a novice with IntelliJ.  Maybe others can respond to that though, if they use IntelliJ to help with managing their code in Git.

As for why your site is still installing 6.1 instead of 6.3, that's really hard to say.  My best guess is maybe one (or more) of your POM files (pom.xml) still reference 6.1  (so that the JARs that end up in [dspace]/lib/ and in webapps are still v6.1 JARs instead of v6.3).  I'm not sure how that would have occurred though, but you should check whether the "dspace" JAR files have a version of 6.1....if so, then something went wrong in your last Git merge when you tried to upgrade to 6.3.

Tim


Sent: Friday, October 11, 2019 5:06 AM

To: DSpace Technical Support <dspac...@googlegroups.com>
Subject: Re: [dspace-tech] Error during OAI import
 
To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-tech/ab486e29-c6d1-41a9-b51e-03e7a348c14c%40googlegroups.com.

euler

unread,
Oct 12, 2019, 5:13:58 PM10/12/19
to DSpace Technical Support
Hi Tim,

Thank you so much for the pointers on using Git. When I use git diff command, it states that my local branch is fully merged to version DSpace-6.3. I also did a search on the occurrences of  dspace-6.1 if there are pom files that are referencing it but there is none. So I deleted all the JARs in the [dspace and dspace-source]/lib and webapps directory and rerun mvn -U clean package. Now when I run oai import, I did not encounter the java.lang.NoSuchMethodError anymore although I encountered a new error which might be a bug. Anyways, I already filed a JIRA issue about the error (DS-4363). In case others encountered the same error, I resolved it by clearing first the 'READ' action of the item policies for the group Anonymous in the owning collection and then adding the 'READ' action again. I used the wildcard policy admin tool for this. Fortunately for me, if you add verbose during OAI import, it is indexing sequentially based on the handle number. In my case, I just visit the next handle to check what collection that item belongs.

NPE-harvest.png
Based on the screenshot above, I just visited the next handle which is 2332 to check which collection it belonged to and then using the wildcard admin policy tool, I reset its policies using the steps I mentioned. It might not be ideal if you have tens of thousands of items. Anyways, after resetting the item policies of every problematic items, I successfully imported all my items in the OAI index.

Many thanks again Tim and hope this would help others who might encounter this issue.

euler
Reply all
Reply to author
Forward
0 new messages