Adding DLL directory C:\Users\ADMINI~1\AppData\Local\Temp\1\e4jCDB2.tmp_dir1581944363\user tempFile is C:\Users\ADMINI~1\AppData\Local\Temp\1\e4jCDB2.tmp tempPath is C:\Users\ADMINI~1\AppData\Local\Temp\1\ semaphore name Local\c:_program_files_XXX_XXX_risk_management_etl_etl_executor.exe, code 0, value 00000000000000CC change working directory to C:\Program Files\XXX\XXX Risk Management\ETL rawDataSize: 2560, rawDataOffset: 452608 init file name C:\Program Files\XXX\XXX Risk Management\ETL\etl_executor.exe C:\Program Files\XXX\XXX Risk Management\ETL\etl_executor.exe 73 0 Log: Started executable C:\Program Files\XXX\XXX Risk Management\ETL\etl_executor.exe at Mon Feb 17 14:59:22 2020 Is the fact that ' Registry and standard locations' option available under the ' JRE Search Sequence' could be related?Īttached the screenshot of JRE search sequence and the native log: When observing the temp log, it looks like it tries to find the java.exe under the executor folder and not using the custom env variable. When the Install4j start we are getting an error that the wizard cannot find a java runtime environment. In 'General Settings' -> JRE Search Sequence -> we removed the previous ' Java_Home' enviroment variable and set a new custom one in which we use to link to the external JRE path the customer supplies.In Media -> Windows -> Bundled JRE -> We set it to ' Don't bundle a JRE'.When he do so, we take the supplied path and define a new custom environment variable to it. Look for logging in ~/Downloads/install4jError.Lately, we changed our Install4j installation mechanize in that we won't bundle an inner JRE anymore, but the customer has to supply a link to it. To find logs containing errors we needed to set an environment variable prior to running the "Domino Installer.app". Domino\ Installer.app/Contents/MacOS/JavaApplicationStub -c, this prompted for the laptop's admin name/password and then proceeded with the console-based install. From within the mounted dmg containing the installer. To evade the error in components outside of Domino's code we installed via console-based / commandline, bypassing a GUI. This error was part of a stacktrace involving java.awt and. - both indicators of a graphical user interface (GUI) problem. A problem between Java, Install4j, and the MacOS was occurring with an error:Ĭaused by: : .screens.SystemFormScreen Initially there were no errors, but additional actions (see Notes below) led us to logs. dmg then clicking the Domino Installer.app, the "Install4j Wizard" screen hangs: This applies to installation of the Domino CLI on Mac OSĪttempting to install the CLI, after downloading the.
0 Comments
Leave a Reply. |