Handle server problem

[Stanislav Orlov]

Greetings!

I set up 7.4 on Ubuntu on a development server and then replaced the old 4.x by the new one.  The 7.4 works fine and frontend is fully usable.  However, I haven't set up Handle on the new machine yet and now, after migration, I have problems. For starters, my Permament URIs are still starting with http://localhost:4000/handle/. Also, if I try to run /dspace/bin/dspace start-handle-server, I get:

Command not found: start-handle-server.

What am I doing wrong?  Any advice?

[Tomas Cohen Arazi]

You are calling the 'dspace' command, but you should be calling 'start-handle-server'.

Best regards

--
All messages to this mailing list should adhere to the Code of Conduct: https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx
---
You received this message because you are subscribed to the Google Groups "DSpace Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dspace-communi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-community/09cf7dff-411e-4897-b39c-c76796c7629fn%40googlegroups.com.

[stan]

Thank you, you were right. 

I used to run it on Windows and it was done slightly differently.  So, I ran 'start-handle-server' and it brings me back to the command line, with the handle-server log showing:

 

"2022-11-03 21:05:04.054-0300" 25 Started new run.

"2022-11-03 21:05:04.055-0300" 25 Handle.net Server Software version 9.3.0

Exception in thread "main" java.lang.NoClassDefFoundError: com/sleepycat/je/DatabaseException

      at net.handle.server.HandleServer.initTxnQueue(HandleServer.java:732)

      at net.handle.server.HandleServer.<init>(HandleServer.java:382)

      at net.handle.server.AbstractServer.getInstance(AbstractServer.java:120)

      at net.handle.server.Main.initialize(Main.java:255)

      at net.handle.server.Main.main(Main.java:122)

Caused by: java.lang.ClassNotFoundException: com.sleepycat.je.DatabaseException

      at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)

      at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)

      at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)

      ... 5 more

I read the "start-handle-server script no error but service not up" conversation from Oct 14:

https://groups.google.com/g/dspace-tech/c/7WHZ9gkMxSo/m/NXyr7akrAgAJ

which had the exact same error about sleepycat, but the suggestion there was to upgrade to 7.4 (which I already have) and to look at another conversation from August "Handle-server cannot start":

https://groups.google.com/g/dspace-tech/c/lr7kfeLLEjg/m/bbU7PkMyBgAJ

which was dealing with missing Jetty jars.  My /dspace/lib has 21 jetty jars, including all 6 mentioned in that second conversation.  Is there something else I could try?

[night librarian]

Two more things, probably related to thisd:

1.  My communities' URLs in the browser now look like this:

https://<mySite>/communities/a5d536e4-ec2c-4826-b58f-5124a6e131eb

while on the old 4.x server they looked like this:

http://<mySite>/xmlui/handle/12345/1234

2. As I mentioned in the beginning, the "Permanent URI" for a community now looks like this:

http://localhost:4000/handle/12345/1234

I checked config.dct, everything binds to the correct IP; dspace.cfg has this:

handle.canonical.prefix = ${dspace.ui.url}/handle/

dspace.ui.url = https://<mySite>

I cannot figure out where it takes the http://localhost:400/ from?

[night librarian]

I wonder whether someone with more experience might have an advice for me. :(

[Tim Donohue]

Hi,

If you are seeing this NoClassDefFoundError, then that implies you have older JAR files hanging around in your DSpace 7.4 installation.  As you noted, this specific issue was fixed in DSpace 7.4.

My best guess is that you may have an older "dspace-api-*.jar" or "handle-*.jar" in your [dspace]/lib/ directory that is causing problems.  Maybe you forgot to run "ant update" during the upgrade (as that's the script that should ensure your "lib" directory is fully updated). 

You may want to rebuild the backend (mvn -U clean package) and rerun the "ant update" to see if that has any impact.  If that doesn't work, then we'd need more info on your setup... you may want to check your dependencies are correct, etc.

As for your other questions...

1.  That's the new URL structure and is expected behavior.  The old XMLUI url structure is no longer supported in DSpace 7, but older /handle/*/* URLs will automatically redirect​ to the new URLs.
2. It sounds like when you ran the database upgrade (./dspace database migrate), you must have had the "dspace.ui.url" temporarily set to "http://localhost:4000".  Essentially, those URLs are coming from the "dc.identifier.uri" metadata field of the Collection/Community, which is set during the database upgrade, based on the value of "handle.canonical.prefix" at that point in time.  So, it sounds like you have Collections where the "dc.identifier.uri" metadata field uses an older version of "handle.canonical.path".  You could either re-do your database migration (starting from your old database, which I know is not ideal), or you could manually update the "dc.identifier.uri" metadata values in your "metadatavalue" table in the database...unfortunately though I don't have a SQL script handy for that at this moment.

Hopefully that gives you some quick hints here to start with.   If you have more questions though, let us know on this list...as maybe others can help if they've seen a specific issue before.

Tim

---

From: dspace-c...@googlegroups.com <dspace-c...@googlegroups.com> on behalf of stan <stani...@gmail.com>
Sent: Thursday, November 3, 2022 8:47 PM
To: DSpace Community <dspace-c...@googlegroups.com>
Subject: Re: [dspace-community] Handle server problem

 

To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-community/c7fdcbdd-04c2-4d14-90ca-cd130a680a63n%40googlegroups.com.

[night librarian]

Thank you very much for your advice.

In terms of other questions, I understand that the new URL structure has changed and I can see it at a few 7.x sites that I could locate in this group's postings.

I ran REPLACE in pgAdmin and replaced the http://localhost:4000/handle/ by https://hdl.handle.net/.   This URL now reflects correctly.  However, after running mvn -U clean package and ant update, I am still not able to start-handle-server and have the same errors in Handle server logs as before.  Here are the commands I ran today:

cd /temp/DSpace-dspace-7.4/
sudo mvn -U clean package
sudo cp /dspace/config/local.cfg /temp/DSpace-dspace-7.4/dspace/config/
cd /temp/DSpace-dspace-7.4/dspace/target/dspace-installer/
sudo ant update
sudo cp -r /dspace/webapps/server/ /var/lib/tomcat9/webapps/
sudo systemctl start tomcat9.service
sudo /dspace/bin/start-handle-server

I will be happy to provide any info that could help troubleshoot it.

On a side note, I haven't seen yet any 7.x site that has a working link to https://hdl.handle.net. They either only point to https://<repositoryIP>/handle/xxxx or to https://handle.net, but it's not resolving.

[night librarian]

Since it looks like I may have an older "dspace-api-*.jar" or "handle-*.jar" (or some other jars) in my [dspace]/lib/ directory even after running "mvn -U clean package" and "sudo ant update" again, maybe I could copy/paste the latest ones from some repository? 

Or is there something else to check somewhere?  Handle server worked well on 4.x, and it is sad that after finally upgrading all the way up to 7.4 I cannot make it run.

[night librarian]

Maybe I will have a better chance if ask this question on dspace-tech?  I hope that will be OK?

[night librarian]

Many thanks for everyone's help.  I had the questions about communities' URLs and wrong "Permanent URI" for Handle server answered in this thread and then got Handle server re-installed and re-setup using advice from this other thread I opened: https://groups.google.com/g/dspace-tech/c/wiI45y7xSRs