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);
}
Related
I am getting error on debug session start on my dot net core API project; since I updated visual studio to latest version 17.1.1. Following is the exception detail, it is showing on console. I tried by deleting temp, bin, obj folders but nothing worked. Has somebody faced such an issue or know how to fix?
Unhandled exception. System.ObjectDisposedException: Cannot access a disposed object.
Object name: 'ConfigurationManager'.
at Microsoft.Extensions.Configuration.ReferenceCountedProviderManager.AddProvider(IConfigurationProvider provider)
at Microsoft.Extensions.Configuration.ConfigurationManager.AddSource(IConfigurationSource source)
at Microsoft.Extensions.Configuration.ConfigurationManager.Microsoft.Extensions.Configuration.IConfigurationBuilder.Add(IConfigurationSource source)
at Microsoft.AspNetCore.Builder.WebApplicationBuilder.<>c__DisplayClass25_0.b__2(HostBuilderContext context, IServiceCollection services)
at Microsoft.Extensions.Hosting.HostBuilder.CreateServiceProvider()
at Microsoft.Extensions.Hosting.HostBuilder.Build()
at Microsoft.AspNetCore.Builder.WebApplicationBuilder.Build()
at Program.$(String[] args) in Program.cs:line 40
It is because you use the old way of getting the settings from the configuration manager, like:
using (var serviceProvider = services.BuildServiceProvider())
{
...
}
If you remove these lines and just use the configuration as-is with
options = configuration.GetOptions<Object>("xxx");
it will work
we also had this issue since march 8.
is was introduced with the release of 6.0.3, see a github post about the issue : https://github.com/dotnet/aspnetcore/issues/40614
for now what we did is revert to the 6.0.2 version (this is a temporary work around, i will hope to figure out what was wrong asap)
for docker images:
FROM mcr.microsoft.com/dotnet/aspnet:6.0.2 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443
FROM mcr.microsoft.com/dotnet/sdk:6.0.200 AS build
WORKDIR /src
if you are using it in yml also probably
use dotnetversion
DotNetVersion: "6.0.200" instead of "6.0.x"
6.0.200 is the sdk version of 6.0.2 framework https://dotnet.microsoft.com/en-us/download/dotnet/6.0
11/03/2022
see also this https://github.com/dotnet/core/issues/7259 were i have pinpointed the issue in our code and added a sample app to reproduce
if we look into that repo https://github.com/microsoft/ApplicationInsights-Kubernetes/blob/69f44c6ec3fda26d76a01836b851402e3f8a02ad/src/ApplicationInsights.Kubernetes/Extensions/ApplicationInsightsExtensions.cs
we indeed find the same piece of code on the other answers
i faced to this problem when i update my SDK both in docker and my window 11
my sdk is : 6.0.3
but i cant understand why this problem is happend
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>
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!
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.
I use maven plugin for eclipse and tomcat plugin for maven. When I use it to "clean tomcat7:deploy" my hello.war to the Tomcat 8 server on localhost it works fine. I can go to localhost:8080/hello/hello and see "Hello!" page.
But when I deploy to Ubuntu server 15.10 in my local network and go to 192.168.1.2:8080/hello/hello I get Apache Tomcat 404 error. Though tomcat manager shows that deployment went fine and my app is working.
My thoughts were that something wrong with tomcat server on ubuntu, but when I deploy other apps to the same tomcat server on ubuntu, they work as they should. Then I thought the problem is inside my "hello" app. But if it was so, I wouldn't be able to successfully run it on my localhost tomcat server!
When I read logs on Tomcat on Ubuntu server they say:
06-Mar-2016 10:00:00.369 INFO [http-nio-8080-exec-5] org.apache.catalina.core.ApplicationContext.log Manager: deploy: Deploying web application '/hello'
06-Mar-2016 10:00:00.370 INFO [http-nio-8080-exec-5] org.apache.catalina.core.ApplicationContext.log Manager: Uploading WAR file to /var/lib/tomcat8/webapps/hello.war.tmp
06-Mar-2016 10:00:18.022 INFO [localhost-startStop-3] org.apache.catalina.core.ApplicationContext.log No Spring WebApplicationInitializer types detected on classpath
So it seems like it can't find my Bootstrap.class class that implements Spring WebApplicationInitializer interface. Though when I check folder /var/lib/tomcat8/webapps/hello/WEB-INF/classes it contains all classes it should.
I checked logs on localhost, and they do not complain about this.
So at the end it seems that Tomcat 8 on Ubuntu server can not find mentioned WebApplicationInitializer.
I've read answers to similar questions here on stackoverflow and tried, but most of them are dealing with eclipse server settings, my problem here is different I think.
What to do and where to look?
EDIT:
When I manually deploy hello.war via /manager on localhost, everything is ok. Inside localhost.2016-03-06.log I have:
06-Mar-2016 11:34:33.081 INFO [http-nio-8080-exec-51] org.apache.catalina.core.ApplicationContext.log Spring WebApplicationInitializers detected on classpath: [by.hello.configuration.Bootstrap#19087f1e]
06-Mar-2016 11:34:33.544 INFO [http-nio-8080-exec-51] org.apache.catalina.core.ApplicationContext.log Initializing Spring root WebApplicationContext
06-Mar-2016 11:34:34.026 INFO [http-nio-8080-exec-51] org.apache.catalina.core.ApplicationContext.log Initializing Spring FrameworkServlet 'springDispatcher'
I can go to localhost:8080/hello/hello and see "Hello!" greeting.
When I do the same with Ubuntu server's tomcat /manager inside logs I have:
06-Mar-2016 11:36:06.555 INFO [http-nio-8080-exec-14] org.apache.catalina.core.ApplicationContext.log No Spring WebApplicationInitializer types detected on classpath
06-Mar-2016 11:36:06.559 INFO [http-nio-8080-exec-14] org.apache.catalina.core.ApplicationContext.log HTMLManager: list: Listing contexts for virtual host 'localhost'
I used to compile project using JDK1.8 environment.
Now I recompiled project using JDK1.7, my Ubuntu server's Tomcat8 started to recognize Bootstrap.class which implements WebApplicationInitializer interface.
So, the answer for me was:
Check your tomcat's JVM version at the bottom of Tomcat /manager/html page.
Recompile your project using appropriate JDK version.