Using Gluon maven-client-plugin, How do you add Graalvm flags such as --initialize-at-run-time, when running mvn client:compile - javafx

Development environment:
Apache Maven 3.6.3
Maven home: /usr/share/maven
Java version: 11.0.6, vendor: Oracle Corporation, runtime: /home/linuxlp/opt/graalvm/graalvm-svm-linux-20.1.0-ea+28
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.4.0-31-generic", arch: "amd64", family: "unix"
My application uses Reactor Netty for client http rest services. The io.netty libraries are generating INFO errors since some of these classes are getting initialized at build time, but they need to be initialized at runtime. There is a Graalvm flag --initialize-at-run-time that I would like to try, but I don't see how to implement it. I tried to implement it in a config file "initruntime" and put that file in the resources/META-INF/substrate/config directory, but this didn't work. Part of client-debug0.log file is included below showing one of the exceptions:
[Sun May 24 18:38:16 EDT 2020][INFO] [SUB] Error: Class initialization of io.netty.handler.ssl.JettyNpnSslEngine failed. Use the option --initialize-at-run-time=io.netty.handler.ssl.JettyNpnSslEngine to explicitly request delayed initialization of this class.

You can add this command to the list of native-image commands like this:
<nativeImageArgs>
<nativeImageArg>--initialize-at-build-time=com.mycompany.main.internal.NativeImageStaticInitializer</nativeImageArg>
</nativeImageArgs>

Related

Jpackage MSI upgrade does not complete if application is open

I'm working on a MSI installer for our java app using Jpackage.
Versions:
openjdk version "17.0.1" 2021-10-19
OpenJDK Runtime Environment Temurin-17.0.1+12 (build 17.0.1+12)
OpenJDK 64-Bit Server VM Temurin-17.0.1+12 (build 17.0.1+12, mixed mode, sharing
jpackage 17.0.1
OS Name: Microsoft Windows Server 2019 Datacenter
OS Version: 10.0.17763 N/A Build 17763
OS Manufacturer: Microsoft Corporation
OS Configuration: Standalone Server
OS Build Type: Multiprocessor Free
Jpackage Usage:
jpackage --input ./home ^
--name "Acme Application" ^
--main-jar app.jar ^
--main-class org.springframework.boot.loader.JarLauncher ^
--java-options "-splash:$APPDIR/splash.png" ^
--java-options -Xmx2g ^
--icon resources/package.ico ^
--win-shortcut ^
--win-menu ^
--type msi ^
--app-version %1
Upgrade Process
The installation works fine and everything runs well. The upgrade process also works fine under normal circumstances. When the user tries to run the new MSI package while the application is still running, the MSI installer prompts the user to close the application before continuing:
Selecting to close the application and continue causes the application to close on the users desktop but the installer then prompts the user again with the same dialog. Selecting the same option (close and continue), allows the installer to complete but the user is then warned that they need to restart.
Upon restarting, it appears that application version 1.0.0 is still running. Checking the jar file signature before and after shows that installer failed to overwrite the original.
Event Viewer
Checking the event viewer, I'm only seeing a few things of interest:
Windows Installer requires a system restart. Product Name: *******. Product Version: 1.0.1. Product Language: 1033. Manufacturer: Unknown. Type of System Restart: 1. Reason for Restart: 0.
and
The Windows Installer initiated a system restart to complete or continue the configuration of '*******'.
Failing to Stop the Application
I also noticed that the application is not completely stopping. Looking at the task manager, it shows the application running under the user and then moves to background processes. This leads me to believe that it's still locking the jar file. The application stops normally under other circumstances so I'm not sure what's different here.
I'm assuming that I need to solve this mystery but I have no idea why the application wouldn't respond to the installer's close signal while working with everything else.
Alright, I've done some digging and this is related to JavaFX's lifecycle. Simply overriding the Application.stop method is not enough to properly shutdown on these types of close requests.
Two changes to my application fixed the issue:
Register a EventHandler on the primary stage onCloseRequest
Here I initialize my spring application as well as register the event handler to stop the application:
#Override
public void start(Stage stage) {
applicationContext.publishEvent(new StageReadyEvent(stage));
stage.setOnCloseRequest(event -> stop());
}
Ensure you have a call to System.exit in your EventHandler
Platform.exit is not enough to close the application under these circumstances:
#Override
public void stop() {
log.info("Shutting down application...");
applicationContext.close();
Platform.exit();
log.info("Shutdown complete");
// System.exit is required or the app will move to a background process on uninstall/upgrade
// events from Windows MSI installer
System.exit(0);
}

Trying to push a nuget package to our private feed. Getting ' load failed: error:02001003:system library:fopen:No such process'

We have an on premise instance of DevOps Server 2020. I have a dotnet standard 2.0 library that I am trying to push to our internal nuget feed.
I am getting the error unable to get local issuer certificate. I followed the instructions here:Azure DevOps Server pipeline build fails when using self-signed SSL certificate with "unable to get local issuer certificate" during NuGet restore
But now I am getting the error (node:6056) Warning: Ignoring extra certs from C:\Certs\root.crt, load failed: error:02001003:system library:fopen:No such process
Here is the YAML where I am setting the path to the root cert:
variables:
solution: '**/*.sln'
buildPlatform: 'Any CPU'
buildConfiguration: 'Release'
NODE.EXTRA.CA.CERTS: 'C:\Certs\root.crt'
And here is the YAML where I am packing and pushing the Nuget package:
- task: DotNetCoreCLI#2
inputs:
command: 'pack'
packagesToPack: '**/*.csproj'
versioningScheme: 'off'
- task: DotNetCoreCLI#2
inputs:
command: 'push'
packagesToPush: '$(Build.ArtifactStagingDirectory)/*.nupkg'
nuGetFeedType: 'internal'
publishVstsFeed: 'b4b089f9-ff2f-4b74-9690-ec6082a4872b'
unable to get local issuer certificate
To resolve this issue, you could try to manually acquire the version of NuGet.exe you wish to use (like nuget.exe v5.9.1) and put it on the private agent in a folder that's on the PATH.
Download NuGet.exe tool to that agent machine manually(e.g.
d:\tool\nuget.exe).
Open System Properties window > Advance > Environment variables.
In System variables section, click New button > Variable name: nuget;
Variable value: d:\tool > Click Ok.
Select Path variable > Edit > add/append %nuget% item (the result
will be xxxx;%nuget%) Restart your machine.
After that you can remove NuGet Tool Installer task from build definition.
If it not work for you, try to running ".\externals\nuget\nuget.exe update -self" for the private agent install folder on the agent machine and getting an update version, it works again with the local certificate store:
You could check this thread for some more details.

CEF / CEFSharp Compiling Issue

Environment: Windows 10, WinForm (.Net 4.7.2) x64 only, CefSharp 71.0.2.0
We need support for playing MP4 in our product (we have a license) and we are attempting to recompile CEF with proprietary codecs enabled.
We're using the instructions from:
https://bitbucket.org/chromiumembedded/cef/wiki/MasterBuildQuickStart.md#markdown-header-windows-setup
Our create.bat file looks like:
set CEF_USE_GN=1
set GN_DEFINES=is_win_fastlink=true proprietary_codecs=true ffmpeg_branding=Chrome
set GN_ARGUMENTS=--ide=vs2015 --sln=cef --filters=//cef/*
call cef_create_projects.bat
Our update.bat file looks like
set CEF_USE_GN=1
set GN_DEFINES=is_official_build=true proprietary_codecs=true ffmpeg_branding=Chrome
set GN_ARGUMENTS=--ide=vs2015 --sln=cef --filters=//cef/*
python ..\automate\automate-git.py --download-dir=C:\code\chromium_git --depot-tools-dir=C:\code\depot_tools --no-distrib --no-build --branch=3578
We are trying to specifically target build 3578 to match the build that comes with CEFSharp. We also enabled proprietary codec using the flag: proprietary_codecs=true
After about 2 hours and no errors the build completes successfully. When we run our page using cefclient.exe from the output build everything works as expected, the video plays correctly.
We copy the following files from the output build folder to our .Net application replacing the files packaged with CEFSharp:
cef.pak
cef_100_percent.pak
cef_200_percent.pak
cef_extensions.pak
chrome_elf.dll
d3dcompiler_47.dll
devtools_resources.pak
icudtl.dat
libcef.dll
libEGL.dll
libGLESv2.dll
natives_blob.bin
snapshot_blob.bin
v8_context_snapshot.bin
\locales\*.*
\swiftshader\libEGL.dll
\swiftshader\libGLESv2.dll
When running our app, the app terminates immediately and this is written to the debug.log file:
[0326/094610.429:FATAL:cookie_manager_impl.cc(620)] Check failed: false. context not valid
Backtrace:
cef_string_utf16_to_upper [0x00007FFD2B53E1E5+1713061]
cef_string_utf16_to_upper [0x00007FFD2B53D44D+1709581]
cef_string_utf16_to_upper [0x00007FFD2B5765D5+1943445]
cef_zip_reader_create [0x00007FFD2B3107B8+159661640]
cef_cookie_manager_get_global_manager [0x00007FFD219B0436+54]
CefCookieManager::GetGlobalManager [0x00007FFD7322879E+94]
(No symbol) [0x00007FFD4E1C07DE]
[0326/094721.035:FATAL:cookie_manager_impl.cc(620)] Check failed: false. context not valid
I was able to see that 71.0.2.0 uses CEF 3.3578.1870.gc974488 / Chromium 71.0.3578.98 from:
https://github.com/cefsharp/CefSharp/commit/7d24861e7af79fc4721eb498bb8417b5aa6cad97
When we run cefclient.exe from our build and navigate to chrome://about it displays:
CEF 3.3578.1870.gc974488
Chromium 71.0.3578.98
Which matches the CEFSharp release notes page.
Any suggestions would be greatly appreciated!

Getting assert at fx_muxer.cpp:316 upon startup of .NET Core App 1.0 on Ubuntu

I'm seeing the following output from my .NET Core App 1.0 on Ubuntu after adding a dependency for my PCL that targets netstandard1.3:
foo: /opt/code/src/corehost/cli/fxr/fx_muxer.cpp:316: static pal::string_t fx_muxer_t::resolve_fx_dir(host_mode_t, const pal::string_t &, const runtime_config_t &, const pal::string_t &): Assertion `mode != host_mode_t::standalone' failed.
Aborted (core dumped)
That line of code is:
// No FX resolution for standalone apps.
assert(mode != host_mode_t::standalone);
This didn't happen to me before, so I'm unsure where to start looking. How is this host_mode_t resolved on startup?
It seems to me the problem is that some dependency resolution is happening that doesn't need to, because of a mistake in a configuration file?
Thanks in advance.
EDIT:
This is the full output of the app upon startup once I set COREHOST_TRACE=1:
Tracing enabled
--- Invoked dotnet [version: 1.1.0, commit hash: 0bc55b1fcc0bd58987bf96683c15596918db2b13] main = { ./foo --staging }
Resolved fxr [/var/www/html/foo/staging/libhostfxr.so]...
Tracing enabled
--- Invoked hostfxr [commit hash: 928f77c4bc3f49d892459992fb6e1d5542cb5e86] main Own DLL
ath=[/var/www/html/foo/staging/foo.dll]
Checking if CoreCLR path exists=[/var/www/html/foo/staging/libcoreclr.so]
Detecting mode...
CoreCLR present in own dir [/var/www/html/foo/staging] and checking if [foo.deps.json] file present=[1]
--- Executing in standalone mode...
Treating application '/var/www/html/foo/staging/foo.dll' as a managed executable.
App runtimeconfig.json from [/var/www/html/foo/staging/foo.dll]
Runtime config is cfg=/var/www/html/foo/staging/foo.runtimeconfig.json
dev=/var/www/html/foo/staging/foo.runtimeconfig.dev.json
Attempting to ead runtime config: /var/www/html/foo/staging/foo.runtimeconfig.json
Attempting to read dev runtime config: /var/www/html/foo/staging/foo.runtimeconfig.dev.json
Runtime config[/var/www/html/foo/staging/foo.runtimeconfig.json] is valid=[1]
foo: /opt/code/src/corehost/cli/fxr/fx_muxer.cpp:316: static pal::string_t fx_muxer_t::resolve_fx_dir(host_mode_t, const pal::string_t &, const runtime_config_t &, const pal::string_t &): Assertion `mode != host_mode_t::standalone' failed. Aborted (core dumped)
This issue was twofold:
I was using rsync to publish the app to my server, but I wasn't deleting files no longer in use, so the dependency configuration files were still present;
I had, at some point, added "platform" as the "type" for "Microsoft.NETCore.App" in my dependencies for the "netcoreapp1.0" target. This was causing a DLL to be generated instead of a standalone executable.

Springfuse - Failed to execute goal: generate

I try to generate an Eclipse Project with Springfuse code generator, based on a MySql database. I have filled up the form at http://www.springfuse.com/, and it generated following Maven command:
mvn -U archetype:generate -DarchetypeGroupId=com.springfuse.archetypes -DarchetypeArtifactId=quickstart -DarchetypeVersion=3.0.108 -DgroupId=com.company.demo -Dpackage=com.company.demo -DartifactId=myproject -Dversion=1.0.0 -DfrontEnd=jsf2Spring -Demail=peter.varga.sp#gmail.com -Dpassword=none -DjdbcGroupId=mysql -DjdbcArtifactId=mysql-connector-java -DjdbcVersion=5.1.25 -DjdbcDriver=com.mysql.jdbc.Driver -DjdbcUser=root -DjdbcPassword=qwe123 -DjdbcUrl=jdbc:mysql://localhost/test -DinteractiveMode=false -DarchetypeRepository=http://maven2.springfuse.com/
I opened a command window, copied the command as it is, and run it, but got following error:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-archetype-plugin:2.2:generate (default-cli) on project standalone-pom: The desired archetype does not exist (com.springfuse.archetypes:quickstart:3.0.108) -> [Help 1]
My environment details:
Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9; 2014-02-14T18:37:52+01:00)
Maven home: c:\Prog\Maven\Maven.3.2.1
Java version: 1.7.0_51, vendor: Oracle Corporation
Java home: c:\Program Files\Java\jdk1.7.0_51\jre
Default locale: en_US, platform encoding: Cp1250
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
Does anybody has an idea, what the problem is?
Thanks.
Please check the settings of proxy / firewall springfuse. Also check the Apache Maven, because it needs to download the dependencies on the Internet. And if it fails, then its usually you need to tell him about the http proxy you need to use.

Resources