I am using Unleash feature toggle (from getunleash.io). The feature toggle and its variant are setup on the non-production and production environment. To make sure unleash configuration is loaded, I am subscribing to the "ready" event
unleash?.subscribe(name: "ready") {
...
}
In non-production env, I am able to get the event back and receive the feature toggle configuration. However in production environment nothing is coming back. All the setup of the feature toggle and its variant is no different with lower environment. Is there any specific thing that has to be configured in the production environment that may have caused this?
Related
I have a Run configuration which builds an exploded web app, deploys it to tomcat, and opens the home page after that. However, I want to hit a few URLs to set some state in the app before opening the home page (Or after opening the homepage; it does not matter). Is there a way to trigger a few URL hits after the run configuration? This feature would be similar to "before launch." Instead, it would be "after launch".
There is no such feature at the moment, you can vote for the related feature request.
It's not as simple as it looks since it's not clear what would trigger the after event. The app server doesn't exit/terminate, but is still running, therefore it's not possible to use another run configuration with your app server added in its Before launch steps, otherwise you could create a Shell script configuration that would call curl/wget.
For the app server the proper after event would be the moment when the artifact deployment is complete which requires the tight integration with this specific app server so that IDE knows the exact moment when it happens and allows to call some custom action.
This might be possible with the custom plug-in as IDE already knows when the artifact deployment is complete.
A really hacky workaround would be to run some tiny HTTP server and open its URL from the IDE instead of your real app server. This custom server would call the URLs/APIs you need and then open a browser for your real app URL.
In this Eclipse RCP application I am making, when a new launch is made, it checks some details of the already running launches which are retrieved by DebugPlugin.getDefault().getLaunchManager().getLaunches().
If it has certain details of its configuration the same as any of the running launches, it should stop. Currently so far, so good.
The Issue
What happens when I edit a LaunchConfiguration while launches of its type are still ongoing? Will that change the attributes of all the running launches' launch configurations? (I am talking about what is retrieved by: ILaunch.getLaunchConfiguration() )
EDIT: More details: in this case it is a hardware connection, and the hardware can only receive one ongoing concurrent connection. If the launch configuration changes, and we check all of the running launches' configurations, we will be unable to check if we're launching for the same hardware twice
When I call ILaunch.getLaunchConfiguration().getAttribute(String,String) it retrieves the new value that has been changed DURING the launch.
So, yes, if an ILaunchConfiguration during an active ILaunch has some attributes changed, if there is no deep copy made in the ILaunch, the changes will reflect on the running ILaunch. Ugh.
I am deciding between using a login item and launch agent.
In this respect I have few questions:
Is it possible for a non root user to quit a login item helper if it is launched with service management framework using SMLoginItemSetEnabled? Will the helper app be reloaded by launchD if it is killed by user or in some cases OS?
Why does apple not recommend presenting a UI with an app that can be executed via a LaunchAgent? Is there a problem if we present a minimal UI?
A login item as a helper application requires the main application to call SMLoginItemSetEnabled. This implies that the main app must be called at least once to enable the login item. This differentiates it from a launch agent which can be loaded as soon as the plist is installed on the system. Can we execute the helper login item irrespective if the user has opened the main app or not?
Any help would be appreciable
LaunchAgents that are configured using SMJobBless are intended to be non-gui services. They run without UI in the background, and don't run as the logged in user.
If you want a gui, you're going to have to use SMLoginItemSetEnabled, or manually install a user LaunchAgent via a .plist with the "LimitLoadToSessionType" = "Aqua" property.
Helpers launched by SMLoginItemSetEnabled run as the current user, so they can be terminated by that user. The process will get relaunched if launchd detects that the agent went away because of a signal or due to an abnormal termination. If it terminates due to a clean termination it will not be restarted until the next login of the user (by clean termination we mean terminating with an exit code of 0, which will not happen if the program is killed e.g. via the activity monitor. If the helper has an option to quit, and that option causes it to exit with a 0 return code, then it will not be restarted, which would be considered good form by the application.
It's a stylistic thing - a user cannot disable the agent without interacting with the command line which would be considered poor standing. There is no issue displaying a UI from a LaunchAgent. As long as it's registered with the appropriate keys, it will be launched in the user's gui login context which means that it can be fully interactive. I have several applications which act like that - TunnelBlick, 1Password (this is via the LaunchAgent plist) and they only put up a menu bar item on startup.
If you're just shipping an application - e.g. via the app store, then there's no way to have anything automatically start without some interaction by the user - you have to launch the main app to get the helper to be enabled. The helper login item can be launched manually without ever launching the main application; but it won't have the 'launch at startup' magic enabled. If you can register a LaunchAgent plist, then you can get the launch at startup & starting it up immediately behaviour.
For uninstallation, however, LaunchAgents require the removal of the .plist, and interacting with launchd to disable it, items registered with the Service Mangement framework will naturally vanish once the app is dragged to the trash.
IMHO, (bit soapboxy, bit opinionated) If you're shipping a standard app with a helper, then rely on first launch before configuring such things as helper start on login; primarily because it keeps the user in control. Autoinstalling startup items is one of my pet peeves with windows applications (so many status bar items...).
The docs for SMLoginItemSetEnabled state the login item will be "kept running", which seems to indicate it will be relaunched if it is killed:
The Boolean enabled state of the helper application. This value is effective only for the currently logged in user. If true, the helper application will be started immediately (and upon subsequent logins) and kept running. If false, the helper application will no longer be kept running.
https://developer.apple.com/documentation/servicemanagement/1501557-smloginitemsetenabled
We have already delivered the 1.0 version of our Worklight application. By mistake we have disabled the Direct update feature by updating the attribute "connectOnStartup = false"
We dont want to redeploy the application to markets (AppStore/GooglePlay) again, but wanted to make our users to utilize the direct update feature. We do have the access to WL server.
Our issue is little different from the one which is already discussed here "IBM Worklight - How to disable Direct Update?"
How can we provide the direct update feature to our end users without redeploying the application to AppStore/Googleplay. And just by changing the Webresources of the application.
We are using the adapters in our application but no where we are explicitly calling the "WL.Client.connect".
The Direct Update feature is always enabled by default.
You need to edit your question and explain what it is you've done in your Worklight project.
The feature will not work if:
You have set connectOnStartup:false
You are not using WL.Client.connect
You are not invoking adapters
You disabled it via the checkbox in Worklight Console
Otherwise, the feature will work, and a check for Direct Update will be performed:
On application startup
On return to foreground
The application will need Re-deployment on the App stores.
So the solution to your problem is
Rebuild the Application with connectOnStartup:true.
Redeploy the Application on App Stores
Once the users download the updated application, future updates will go to the users directly.
While rebuilding, make sure that you change the Version of your application within ApplicationDescriptor.
I've deployed an application inside a corporate network and I want the update process to require less attention from users, similar to how Google Chrome install updates - in the background. I don't need to give the user a choice to update.
I've used the System.Deployment library to detect when new ClickOnce updates are available and install them automatically. I'm wondering if its necessary to restart the app after the update is complete. Currently I invoke Application.Restart() at the end of my update script.
But what if (to make the update process more transparent for the user) I performed a 'silent' async update and then displayed an icon prompting the user to restart the app to apply the changes? Would this make the app unstable in any way?
Furthermore, if I ran my custom InstallUpdate() process on a timer, say every 30 minutes, would ClickOnce be stable to continue to update for every new version that was released even thought the user has not restarted (nb: I'm expecting the updates to only apply once the user restarts the app)?
I would think it depends on what your application does at startup, and what it's doing when the update is installed and the application is restarted, and what the update contains. You could try running it and then attaching a debugger to it and see what it's doing and what impact it has.
For example, our application loads a lot of information into memory when it starts up. If the update included a change to one of the data structures, and the app didn't reload the data for some reason, it would cause a problem.
After a few years of doing it like this, we have found that it is possible to silently install updates this way. However there are a few issues to be aware of:
If the thread terminates prematurely during the Update() (eg: the user exits out of the app while the updating is in progress), the install will become corrupt and the next time the user loads the app, the ClickOnce normal deployment will fire off and re-install the app.
The user's desktop icons always redraw (flicker) after an update is installed.
Calling ApplicationDeployment.CurrentDeployment.CheckForUpdate() more than 65536 times causes a System.NullReferenceException Source.
An alternative is not to actually check for an update, I have found that this locks one of my dlls and prevented a form from loading, so use with care:
If ApplicationDeployment.CurrentDeployment.Update Then ' update app
console.writeline("update installed")
' code to inform user update was sucessfull and they need to restart
End If
If your ClickOnce project is 32bit, and you run it on an x64 platform, any file associations your app has will break after performing a manual ClickOnce update. See this MS support case for more details.