change Glassfish to Payara in Admin Guide #6593

doc/sphinx-guides/source/admin/harvestclients.rst

@@ -24,6 +24,6 @@ The process of creating a new, or editing an existing client, is largely self-ex
 What if a Run Fails?
 ~~~~~~~~~~~~~~~~~~~~
 
-Each harvesting client run logs a separate file per run to Glassfish's default logging directory (``/usr/local/glassfish4/glassfish/domains/domain1/logs/`` unless you've changed it). Look for filenames in the format  ``harvest_TARGET_YYYY_MM_DD_timestamp.log`` to get a better idea of what's going wrong.
+Each harvesting client run logs a separate file per run to Payara's default logging directory (``/usr/local/payara5/glassfish/domains/domain1/logs/`` unless you've changed it). Look for filenames in the format  ``harvest_TARGET_YYYY_MM_DD_timestamp.log`` to get a better idea of what's going wrong.
 
 Note that you'll want to run a minimum Dataverse version of 4.6, optimally 4.18, for the best OAI-PMH interoperability.

doc/sphinx-guides/source/admin/make-data-count.rst

@@ -100,7 +100,7 @@ Soon we will be setting up a cron job to run nightly but we start with a single
 
 * If you are running Counter Processor for the first time in the middle of a month, you will need create blank log files for the previous days. e.g.:
 
-  * ``cd /usr/local/glassfish4/glassfish/domains/domain1/logs``
+  * ``cd /usr/local/payara5/glassfish/domains/domain1/logs``
 
   * ``touch counter_2019-02-01.log``
 

doc/sphinx-guides/source/admin/metadatacustomization.rst

@@ -546,7 +546,7 @@ Loading TSV files into Dataverse
 
 A number of TSV files are loaded into Dataverse on every new installation, becoming the metadata blocks you see in the UI. For the list of metadata blocks that are included with Dataverse out of the box, see the :doc:`/user/appendix` section of the User Guide.
 
-Along with TSV file, there are corresponding ResourceBundle property files with key=value pair `here <https://github.com/IQSS/dataverse/tree/develop/src/main/java>`__.  To add other language files, see the :doc:`/installation/config` for dataverse.lang.directory JVM Options section, and add a file, for example: "citation_lang.properties" to the path you specified for the ``dataverse.lang.directory`` JVM option, and then restart Glassfish.
+Along with TSV file, there are corresponding ResourceBundle property files with key=value pair `here <https://github.com/IQSS/dataverse/tree/develop/src/main/java>`__.  To add other language files, see the :doc:`/installation/config` for dataverse.lang.directory JVM Options section, and add a file, for example: "citation_lang.properties" to the path you specified for the ``dataverse.lang.directory`` JVM option, and then restart Payara.
 
 If you are improving an existing metadata block, the Dataverse installation process will load the TSV for you, assuming you edited the TSV file in place. The TSV file for the Citation metadata block, for example, can be found at ``scripts/api/data/metadatablocks/citation.tsv``.
 If any of the below mentioned property values are changed, corresponsing ResourceBundle property file has to be edited and stored under ``dataverse.lang.directory`` location

doc/sphinx-guides/source/admin/metadataexport.rst

@@ -28,7 +28,7 @@ Note, that creating, modifying, or re-exporting an OAI set will also attempt to
 Export Failures
 ---------------
 
-An export batch job, whether started via the API, or by the application timer, will leave a detailed log in your configured logs directory. This is the same location where your main Glassfish server.log is found. The name of the log file is ``export_[timestamp].log`` - for example, *export_2016-08-23T03-35-23.log*. The log will contain the numbers of datasets processed successfully and those for which metadata export failed, with some information on the failures detected. Please attach this log file if you need to contact Dataverse support about metadata export problems.
+An export batch job, whether started via the API, or by the application timer, will leave a detailed log in your configured logs directory. This is the same location where your main Payara server.log is found. The name of the log file is ``export_[timestamp].log`` - for example, *export_2016-08-23T03-35-23.log*. The log will contain the numbers of datasets processed successfully and those for which metadata export failed, with some information on the failures detected. Please attach this log file if you need to contact Dataverse support about metadata export problems.
 
 Downloading Metadata via GUI
 ----------------------------

doc/sphinx-guides/source/admin/monitoring.rst

@@ -36,7 +36,7 @@ Create a username/password (i.e. "admin" for both):
 
 ``htpasswd /etc/munin/munin-htpasswd admin``
 
-Assuming you are fronting Glassfish with Apache, prevent Apache from proxying "/munin" traffic to Glassfish by adding the following line to your Apache config:
+Assuming you are fronting Payara with Apache, prevent Apache from proxying "/munin" traffic to Payara by adding the following line to your Apache config:
 
 ``ProxyPassMatch ^/munin !``
 
@@ -90,12 +90,12 @@ Process the logs:
 
 Please note that load balancers (such as Amazon's ELB) might interfer with the ``LogFormat`` mentioned above.  To start troubleshooting errors such as ``AWStats did not find any valid log lines that match your LogFormat parameter``, you might need to bump up the value of ``NbOfLinesForCorruptedLog`` in the config files above and re-try while you interate on your Apache and AWStats config.
 
-Please note that the Dataverse team has attempted to parse Glassfish logs using AWStats but it didn't seem to just work and posts have been made at https://stackoverflow.com/questions/49134154/what-logformat-definition-does-awstats-require-to-parse-glassfish-http-access-logs and https://sourceforge.net/p/awstats/discussion/43428/thread/9b1befda/ that can be followed up on some day.
+Please note that the Dataverse team has attempted to parse Payara logs using AWStats but it didn't seem to just work and posts have been made at https://stackoverflow.com/questions/49134154/what-logformat-definition-does-awstats-require-to-parse-glassfish-http-access-logs and https://sourceforge.net/p/awstats/discussion/43428/thread/9b1befda/ that can be followed up on some day.
 
-Database Connection Pool used by Glassfish
-------------------------------------------
+Database Connection Pool used by Payara
+---------------------------------------
 
-https://github.com/IQSS/dataverse/issues/2595 contains some information on enabling monitoring of Glassfish, which is disabled by default. It's a TODO to document what to do here if there is sufficient interest.
+https://github.com/IQSS/dataverse/issues/2595 contains some information on enabling monitoring of Payara, which is disabled by default. It's a TODO to document what to do here if there is sufficient interest.
 
 
 actionlogrecord

doc/sphinx-guides/source/admin/troubleshooting.rst

@@ -32,49 +32,49 @@ A User Needs Their Account to Be Converted From Institutional (Shibboleth), ORCI
 
 See :ref:`converting-shibboleth-users-to-local` and :ref:`converting-oauth-users-to-local`.
 
-.. _troubleshooting-glassfish:
+.. _troubleshooting-payara:
 
-Glassfish
----------
+Payara
+------
 
-.. _glassfish-log:
+.. _payara-log:
 
-Finding the Glassfish Log File
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Finding the Payara Log File
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-``/usr/local/glassfish4/glassfish/domains/domain1/logs/server.log`` is the main place to look when you encounter problems (assuming you installed Glassfish in the default directory). Hopefully an error message has been logged. If there's a stack trace, it may be of interest to developers, especially they can trace line numbers back to a tagged version or commit. Send more of the stack trace (the entire file if possible) to developers who can help (see "Getting Help", below) and be sure to say which version of Dataverse you are running.
+``/usr/local/payara5/glassfish/domains/domain1/logs/server.log`` is the main place to look when you encounter problems (assuming you installed Payara in the default directory). Hopefully an error message has been logged. If there's a stack trace, it may be of interest to developers, especially they can trace line numbers back to a tagged version or commit. Send more of the stack trace (the entire file if possible) to developers who can help (see "Getting Help", below) and be sure to say which version of Dataverse you are running.
 
-.. _increase-glassfish-logging:
+.. _increase-payara-logging:
 
-Increasing Glassfish Logging
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Increasing Payara Logging
+~~~~~~~~~~~~~~~~~~~~~~~~~
 
 For debugging purposes, you may find it helpful to temporarily increase logging levels. Here's an example of increasing logging for the Java class behind the "datasets" API endpoints:
 
 ``./asadmin set-log-levels edu.harvard.iq.dataverse.api.Datasets=FINE``
 
 For more on setting log levels, see the :doc:`/developers/debugging` section of the Developer Guide.
 
-Our guides focus on using the command line to manage Glassfish but you might be interested in an admin GUI at http://localhost:4848
+Our guides focus on using the command line to manage Payara but you might be interested in an admin GUI at http://localhost:4848
 
 
 Deployment fails, "EJB Timer Service not available"
 ---------------------------------------------------
 
-Sometimes the Dataverse application fails to deploy, or Glassfish fails to restart once the application is deployed, with the following error message: :fixedwidthplain:`"remote failure: Error occurred during deployment: Exception while loading the app : EJB Timer Service is not available. Please see server.log for more details."`
+Sometimes the Dataverse application fails to deploy, or Payara fails to restart once the application is deployed, with the following error message: :fixedwidthplain:`"remote failure: Error occurred during deployment: Exception while loading the app : EJB Timer Service is not available. Please see server.log for more details."`
 
 We don't know what's causing this issue, but here's a known workaround: 
 
-- Stop Glassfish; 
+- Stop Payara; 
 
 - Remove the ``generated`` and ``osgi-cache`` directories; 
 
 - Delete all the rows from the ``EJB__TIMER__TBL`` table in the database;
 
-- Start Glassfish
+- Start Payara
 
 The shell script below performs the steps above. 
-Note that it may or may not work on your system, so it is provided as an example only, downloadable :download:`here </_static/util/clear_timer.sh>`. Aside from the configuration values that need to be changed to reflect your environment (the Glassfish directory, name of the database, etc.) the script relies on the database being configured in a certain way for access. (See the comments in the script for more information)
+Note that it may or may not work on your system, so it is provided as an example only, downloadable :download:`here </_static/util/clear_timer.sh>`. Aside from the configuration values that need to be changed to reflect your environment (the Payara directory, name of the database, etc.) the script relies on the database being configured in a certain way for access. (See the comments in the script for more information)
 
 .. literalinclude:: ../_static/util/clear_timer.sh
 
@@ -83,7 +83,7 @@ Note that it may or may not work on your system, so it is provided as an example
 Timer Not Working
 -----------------
 
-Dataverse relies on EJB timers to perform scheduled tasks: harvesting from remote servers, updating the local OAI sets and running metadata exports. (See :doc:`timers` for details.) If these scheduled jobs are not running on your server, this may be the result of the incompatibility between the version of PostgreSQL database you are using, and PostgreSQL JDBC driver in use by your instance of Glassfish. The symptoms:
+Dataverse relies on EJB timers to perform scheduled tasks: harvesting from remote servers, updating the local OAI sets and running metadata exports. (See :doc:`timers` for details.) If these scheduled jobs are not running on your server, this may be the result of the incompatibility between the version of PostgreSQL database you are using, and PostgreSQL JDBC driver in use by your instance of Payara. The symptoms:
 
 If you are seeing the following in your server.log...
 
@@ -97,14 +97,14 @@ followed by an Exception stack trace with these lines in it:
 
 
 ... it most likely means that it is the JDBC driver incompatibility that's preventing the timer from working correctly. 
-Make sure you install the correct version of the driver. For example, if you are running the version 9.3 of PostgreSQL, make sure you have the driver postgresql-9.3-1104.jdbc4.jar in your :fixedwidthplain:`<GLASSFISH FOLDER>/glassfish/lib` directory. Go `here <https://jdbc.postgresql.org/download.html>`_
-to download the correct version of the driver. If you have an older driver in glassfish/lib, make sure to remove it, replace it with the new version and restart Glassfish. (You may need to remove the entire contents of :fixedwidthplain:`<GLASSFISH FOLDER>/glassfish/domains/domain1/generated` before you start Glassfish). 
+Make sure you install the correct version of the driver. For example, if you are running the version 9.3 of PostgreSQL, make sure you have the driver postgresql-9.3-1104.jdbc4.jar in your :fixedwidthplain:`<PAYARA FOLDER>/glassfish/lib` directory. Go `here <https://jdbc.postgresql.org/download.html>`_
+to download the correct version of the driver. If you have an older driver in glassfish/lib, make sure to remove it, replace it with the new version and restart Payara. (You may need to remove the entire contents of :fixedwidthplain:`<PAYARA FOLDER>/glassfish/domains/domain1/generated` before you start Payara). 
 
 
 Constraint Violations Issues
 ----------------------------
 
-In real life production use, it may be possible to end up in a situation where some values associated with the datasets in your database are no longer valid under the constraints enforced by the latest version of Dataverse. This is not very likely to happen, but if it does, the symptomps will be as follows: Some datasets can no longer be edited, long exception stack traces logged in the Glassfish server log, caused by::
+In real life production use, it may be possible to end up in a situation where some values associated with the datasets in your database are no longer valid under the constraints enforced by the latest version of Dataverse. This is not very likely to happen, but if it does, the symptomps will be as follows: Some datasets can no longer be edited, long exception stack traces logged in the Payara server log, caused by::
 
    javax.validation.ConstraintViolationException: 
    Bean Validation constraint(s) violated while executing Automatic Bean Validation on callback event:'preUpdate'.