Problem with deploying v6.7.1
Kirill Batyuk
Hello,
I’m trying to upgrade my dev server from v6.6 to v. v6.7.1
I followed the steps for the upgrade outlined in here: https://github.com/IQSS/dataverse/releases/tag/v6.7
At the end, after SOLR reindex is complete, and I try to navigate to the root repository, I get the following error:
[2025-09-23T13:48:28.675-0400] [Payara 6.2025.3] [WARNING] [AS-EJB-00056] [jakarta.enterprise.ejb.container] [tid: _ThreadID=70 _ThreadName=http-thread-pool::http-listener-1(2)] [timeMillis: 1758649708675] [levelValue: 900] [[
A system exception occurred during an invocation on EJB SolrSearchServiceBean, method: public edu.harvard.iq.dataverse.search.SolrQueryResponse edu.harvard.iq.dataverse.search.SolrSearchServiceBean.search(edu.harvard.iq.dataverse.engine.command.DataverseRequest,java.util.List,java.lang.String,java.util.List,java.lang.String,java.lang.String,int,boolean,int,boolean,java.lang.String,java.lang.String,boolean,boolean) throws edu.harvard.iq.dataverse.search.SearchException]]
[2025-09-23T13:48:28.675-0400] [Payara 6.2025.3] [WARNING] [] [jakarta.enterprise.ejb.container] [tid: _ThreadID=70 _ThreadName=http-thread-pool::http-listener-1(2)] [timeMillis: 1758649708675] [levelValue: 900] [[
jakarta.ejb.EJBException: Can't find resource for bundle java.util.PropertyResourceBundle, key staticSearchFields.curationStatus
Any help would be appreciated.
Thank you,
Kirill Batyuk
Systems Librarian
MBLWHOI Library
Data Library and Archives
Woods Hole Oceanographic Institution
mblwhoilibrary.org -- whoi.edu
James Myers
I’m not sure from the short log trace. The bundle entry you’re missing was added in #11268 and is in the 6.7.1 war file. Are you sure you’re running that version? (There was a similar update to the solr schema.xml – another thing to check isthat you have the latest schema – step 13 in the install instructions for https://github.com/IQSS/dataverse/releases/tag/v6.7 .)
-- Jim
--
You received this message because you are subscribed to the Google Groups "Dataverse Users Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
dataverse-commu...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/dataverse-community/SJ2PR16MB5796E48060515F25913A146BC21DA%40SJ2PR16MB5796.namprd16.prod.outlook.com.
Kirill Batyuk
Hi Jim,
When I navigate to the Dataverse, it shows v. 6.7.1 build 1955-8e18f64, but the page is blank, with the following banner: “Internal Server Error - An unexpected error was encountered, no more information is available. “
I’ve deployed the new schema as per instructions.
I’m attaching server.log output for the error, with everything that it’s showing.
-Kirill.
From: dataverse...@googlegroups.com <dataverse...@googlegroups.com>
On Behalf Of James Myers
Sent: Tuesday, September 23, 2025 2:22 PM
To: dataverse...@googlegroups.com
Subject: [EXTERNAL] [Dataverse-Users] RE: Problem with deploying v6.7.1
This email originated outside of WHOI. Please use caution if clicking on links or opening attachments.
James Myers
I can’t think of anything other than something cached/in need of a restart. The field you’re missing is in the staticSearchFields.properties file for 6.7.1: https://github.com/IQSS/dataverse/blob/f92b3877472e702d8f64d5d159818e49cc8029cb/src/main/java/propertyFiles/staticSearchFields.properties#L14 ,
that build number you see is correct for the distributed war, and the failing line number matches up : https://github.com/IQSS/dataverse/blob/f92b3877472e702d8f64d5d159818e49cc8029cb/src/main/java/edu/harvard/iq/dataverse/search/SolrSearchServiceBean.java#L820.
Somehow though, that entry isn’t being found. Making some guesses:
- Payara will cache entries until restarted, so a restart might help.
- Although the instructions to try deleting some payara directories are usually for when there’s a problem in the .xhtml pages rather than Java, you may want to try:
sudo rm -rf $PAYARA/glassfish/domains/domain1/generated
sudo rm -rf $PAYARA/glassfish/domains/domain1/osgi-cache
sudo rm -rf $PAYARA/glassfish/domains/domain1/lib/databases
before restarting payara.
- You might also want to make sure that the file in your /usr/local/payara6/glassfish/domains/domain1/applications/dataverse-6.7.1/WEB-INF/classes/propertiesFiles/staticSearchFields.properties file actually has that curationStatus line.
- And that payara /the unix user it’s running as has permission to read that file, etc.
Hope something here helps,
Kirill Batyuk
This is extremely odd, but none of the staticSearchFields.properties files contained the last line: staticSearchFields.curationStatus=Curation Status
I’ve manually edited the files in the following locations and appended the property in the end:
/home/dataverse/langBundles/staticSearchFields.properties
/home/dataverse/langBundles/dataverse-language-packs/en_US/staticSearchFields.properties
/srv/localdata/dataverse/src/main/java/propertyFiles/staticSearchFields.properties
/usr/local/payara6/glassfish/domains/domain1/applications/dataverse-6.7.1/WEB-INF/classes/propertyFiles/staticSearchFields.properties
After the restart, everything is working as it should.
I wonder if I was doing something incorrectly with the deployment, so that it was not updating that particular file.
Thank you,
Kirill Batyuk
Systems Librarian
MBLWHOI Library
Data Library and Archives
Woods Hole Oceanographic Institution
mblwhoilibrary.org -- whoi.edu
From: dataverse...@googlegroups.com <dataverse...@googlegroups.com>
On Behalf Of James Myers
Sent: Tuesday, September 23, 2025 3:19 PM
To: dataverse...@googlegroups.com
Subject: RE: [EXTERNAL] [Dataverse-Users] RE: Problem with deploying v6.7.1
This email originated outside of WHOI. Please use caution if clicking on links or opening attachments.
James Myers
Glad you got it working.
I’m not completely sure what could have happened. The /usr/local/payara6/glassfish/domains/domain1/applications… copy should come from the war and should be up to date.
The one in /home/dataverse/langBundles/staticSearchFields.properties could have been preferred (in terms of which one Java reads) over that one though, so if it wasn’t updated (manually), things might fail.
In general, I didn’t think there was supposed to be a copy of any <name>.properties file in the langBundles directory, just the <name>_<langCode>.properties ones - that way if the language specific ones are out of date, they still get the English string from the up-to-date file distributed with the war.