Today I have a strange problem on MacOs. I hope I can explain the precondition exactly for understanding. We are using the install4j version 6.0.1.
Our application is implemented with an install4j silent update check application as the main "launcher" to check for updates during the startup process of our application. This application is totally configured by the install4j IDE. It checks whether an update exists and for that downloads the new installer and executes it. That's working fine. If the application is up-to-date the "main" application launcher will be executed by the Execute Launcher-action. Therefore the "extraCommandLineArguments" will be passed to the launcher and the application will be started. That's working also fine and the parameters will be passed correctly to our main class.
Now the strange behavior: when I start the application twice with several parameters during the first instance is always running the parameters will not be passed to the first instance neither a second instance will be created. The launcher is configured by install4j to allow multiple instances of the application and the single-instance option is implemented by our application itself. Therefore the main-class checks whether an instance is always running and will pass the parameters to the first instance. Now it seems that the second instance will never be created because I can't attach to the vm-process by IDE at debug mode. Therefore I set the debug vm parameters to the vmoption file. I tried several options to start the second instance:
execute our application normally with the "updater"-application and set commandline parameters
execute our application directly by the launcher-executable and set commandline parameters
execute our application by calling the JavaApplicationStub of the launcher and passing the commandline parameters to it
For all options the running instance will get the focus but do not receive any parameter and I can not attach the second process by the IDE to debug the behavior. It seems our application (main-class) will not be executed a second time. At the Info.plist file there is the MacLauncher class recognized as the main-class. Is tere any logic implemented to search for a running instance and ignore a second one?
The strange thing is: at windows everything works fine. The second process passes the parameter to the running instance. What could be different on mac? How can I check whether install4j is calling our main application class configured at the launcher? Are there any debug-options?
Thanks in advance for any help.
On Mac OS X, GUI applications are in single instance mode by default. This is a property of the Mac OS X desktop environment. The only way to open a second instance, is to call
open -n my.app
Related
I'm using install4j to create an installer for my java application.
I'm using executable level "As invoker" and in the first start after installation, the application works fine calls all my loggers from the main class and all other classes. On the second start, an application doesn't call my main class. If I use the executable level "Administrator" application works fine.
Can somebody explain to me how to fix this?
I'm in the process of trying to write a VSCode extension to support basic SNES application development. I already have a basic grammar definition and build task, so I have syntax highlighting, and am able to build my project with Ctrl+Shift+B using the bass v14 assembler, but now I'm trying to figure out how to launch the project using launch.json. I've already worked through the official docs and played around with the mock debugger project, but I can't seem to figure out how to adapt it for my extension. To start, I'm using the bsnes-plus emulator as my debugger. There isn't really any command-line or IPC interface that will actually allow me to implement a proper debug adapter, so all I really want to do is to run the program and pass it my output file to launch. For the time being, I'm assuming that bsnes-plus.exe is located in my $PATH, but eventually I'll try and figure out the best practices for external executable dependencies for an extension.
So here are my current questions:
Is the "program" field of launch.json my compiled application, or is it bsnes-plus.exe?
If "program" is my application, where do I specify bsnes-plus.exe? Or vice versa.
Is there a way to specify my own project-level variables, e.g. $OUTPUT so that I don't have to hard-code the output filename into both the build task and the launch task?
At one point, I was able to get the launch command to open bsnes-plus, but not load the game, and when I closed it, VSCode complained that the debugger terminated unexpectedly and immediately re-opened bsnes-plus. How do I avoid this? Do I need to write a debug adapter even though it's not going to actually do anything other than launch the application, just so I can tell VSCode that it exited cleanly?
Is the "program" field of launch.json my compiled application, or is it bsnes-plus.exe?
This is entirely up to the debug extension. It's just passed through to the debug adapter. It usually corresponds to the specific app/script being debugged though, not the runtime that's running it, so I would suggest it should be your compiled application.
If "program" is my application, where do I specify bsnes-plus.exe? Or vice versa.
You can put it any other field. In Dart, we have a dartPath field that can be passed through to the debug adapter. It's usually populated silently by the DebugConfigurationProvider.resolveDebugConfig though (we detect the SDK by searching PATH) so the user never needs to add it.
Is there a way to specify my own project-level variables, e.g. $OUTPUT so that I don't have to hard-code the output filename into both the build task and the launch task?
You can't make your own variables, but using resolveDebugConfig you can manipulate the launch config yourself before it's passed to the debug adapter, which probably allows you to do what you need here (eg. you could do a string replace on program - or you could even just add it if it's not set, allowing a launch.json-less launch too).
Do I need to write a debug adapter even though it's not going to actually do anything other than launch the application, just so I can tell VSCode that it exited cleanly?
I'm not sure what happened here without more details, but having a debug adapter probably makes the most sense - for example if you want to make the Stop/Restart buttons work on the toolbar, you'd probably want a debug adapter that can terminate and/or restart the process.
I have a .Net 4.0 test assemby and I am running nunit-console-x86.exe that fire an nunit-agent-x86.exe process.
Do you know if the runner pass the /nothread option to nunit-agent-x86.exe?
I have noticed that my tests run successfully when they are executed inside the runner process with that option set (and with a modification of the runner configuration file to target the CLR 4.0)? I am using the version 2.6.4 of Nunit.
As runners are chained together, the same package is passed from one to the other. That package is created with a setting that reflects the use of /nothread, so every runner receives it, no matter what process they are in.
You haven't indicated why you need that option in the first place. It's a rather strange option, since it says you prefer that the tests be run on the same thread that is used by NUnit itself, rather than creating a new one.
I need the /nothread option because some of the objects I instantiate during my tests are COM objects and they need to be instantiated in the main STA thread.
When working with Mule ESB, we need to have (in our case) ActiveMQ running (in a terminal) or it won't work. That's fine, but I sometimes forget to start ActiveMQ, which caused me to wonder...
Can I somehow explain to my "Run configuration" that it should start an external program in conjunction with starting the run|debug session? And if so, can it be configured to only start it if it's not already running?
I am not sure whether you can run the external application using your project run configurations. But from mule studio you can start the external application using Run--> External tools. Refer the below kink for details
http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.platform.doc.user%2Ftasks%2Ftasks-exttools-running.htm
Eclipse CDT contains a useful type of launch configuration called a Launch Group. With a launch group you can set up different launches to run and what order. You can optionally add delays between launches (to allow for your service to start) or wait for a set up launch to terminate before running the next one.
To install the launch groups you can add "C/C++ Development Tools" to your installation.
Once installed, you should have a new launch type called a launch group.
Here is an example of one that may address your first question:
Launch Group Example
As my example shows, you don't need to have any CDT launches to be able to use Launch Groups.
As for your second part. This is in active development. Eclipse EASE is adding full scriptability to Eclipse and as it turns out I have just written a post about adding launching capabilities to the scripting. You can follow that work on bugzilla: Bug 478397
I want to do the following with application wrapped by Install4J:
have the Install4J Updater invoked from the code of the wrapped Java app
show the GUI dialogs, configured in the Install4J IDE to a user if there is an update available
pass custom proxy parameters to the Updater, if required
As far as I can understand Install4J I should be able to do it with the following:
List<String> args = new ArrayList<String>();
args.add("-DproxySet=true");
args.add("-DproxyHost="+MY_PROXY_SERVER);
args.add("-DproxyPort="+MY_PROXY_PORT););
args.add("-DproxyAuth=true");
args.add("-DproxyAuthUser="+MY_PROXY_USERNAME);)
args.add("-DproxyAuthPassword="+MY_PROXY_PASSWORD);
ApplicationLauncher.launchApplicationInProcess(
MY_UPDATER_ID.toString(),
args.toArray(new String[args.size()]),
null,
ApplicationLauncher.WindowMode.FRAME,
null);
but I keep getting the popup for entering proxy details.
I have tried changing parameters not to have prefix "-D", tried switching Updater to console mode or unattended mode, not passing the parameters but rather putting them to JVM directly with System.setProperty()... but with no success. I always ended either with proxy-popup or with message that "The update information could not be downloaded from ____ Please check your network settings."
Also: if I repeatedly invoke Updater but with different parameters the popup always shows the once I used for the first invocation.
Any help?
Thanks in advance.
Thanks to the support from EJ-tehnologies (developers of Install4J) we got the proxy thing working. In the moment of asking the question we were using v5.0.11, and they instructed us to use v5.1.2 (latest stable build in that moment). And finally we ended using the beta release v5.1.3 (not publicly available at the moment).
Details on how to have proxy working, without popup and with using dynamic parameters:
to the code above add additional argument that will prevent Install4J to detect system wide proxy settings:
args.add("-Dinstall4j.noProxyAutoDetect=true");
use method ApplicationLauncher.launchApplication() for invoking the Install4J wrapper as it will start it in the new JVM. starting like this is required due to JVM's handling of existing env variables, so if you start Install4J in the same JVM and append arguments in that JVM the Install4J might not pick the latest values (this is if you want to dynamically change proxy params)
wait for v5.1.3 to become stable and download it as it will support "not showing" of proxy popup dialog when proxy parameters are explicitly given to Install4J (this is my guess, I'm not speaking in the name of people from EJ-technologies)