The command bees app:list shows names of the applications, status, URL and instance count, but is there a way to see the latest commit message?
We set the commit message to be the Git revision of the sources that produce the deployed WAR and it would be nice to see which version is currently running of each app without having to look it from the RUN console wep application.
bees app:info shows a bit more information but not that deploy message, unfortunately. That may be a nice addition to it thought, I will pass that on.
bees app:info will show exact deployment time, if that helps.
Related
I am getting 'update is available' message from MFP after installing a new build via TestFlight. This only happen the first time.
This my steps
Build by app with cordova build command
Open Xcode and add the Push entitlement and deploy to the TestFlight
execute the mfpdev webupdate command
After installing the update from TestFlight I get the 'Web update is available' message from MFP..
I have not change any html,css since I deploy to TestFlight. So, I am not sure why the update message
All I am changing in step 1 is build# "android-versionCode" and "ios-CFBundleVersion"
I am using MFP V8
Direct Update is based on checksums. A checksum value is stored in the client whenever it is built. This checksum value is sent to the server as part of calls made to the server and is being compared to the client checksum value that is also stored on the server.
When performing mfpdev app webupdate, if there are any web resources changes in the application since its last state, the checksum value on the server will change.
Thus, the next time an application with an older checksum value attempts to connect, the checksum values will not match and a Direct Update will trigger.
That said, a change of a bundle identifier happening in the config.xml file and I am not sure if changes to this file are supposed to affect the checksum. Also note that changes to this file cannot be "updated" or "reflected" in the application by using Direct Update either. If you change something in this file then are you very much supposed to re-build the application and potentially release it with a new version number to the App Store / Google Play Store.
That said #2, as a workaround, simply do not execute the webupdate command and your issue should be resolved.
I do encourage you though to open a PMR to see if changes to the config.xml should or should not affect Direct Update.
I am trying to migrate the IBM Ready Healthcare app (https://github.com/IBM-MIL/IBM-Ready-App-for-Healthcare) from v6.3 to v8.0.
I ran "mfpmigrate client ..." command from 'healthcare-mfpf' folder (folder structure shown below), and I got "No supported platforms were detected to migrate" error. Next, I ran the command "mfp add environment" in order to add the environment, that would add the platform. However, I get an error saying that there needs to be a hybrid app available to add environment. I had no luck on running the commands from apps folder as well (folder structure shown below).
Would anyone please kindly let me know the folder I should run the command from, or do I need to go through some extra steps before I can run the "mfpmigrage client ..." command.
Folder structure
Notice: please note that the Ready Apps are no longer maintained by IBM. Just take this under considerations
This project is a Hybrid app, meaning you need to first add it to MobileFirst Studio and then add a supported environment. The project does not come with environments by default.
Only once you do this step will the migration tool find a platform (= environment) to migrate from...
Looking at the file structure you've provided, it's wrong.
It shows:
Apps
- android
- iphone
It's supposed to be:
Apps
- some app
--- android
--- iphone
--- common
It could be that they call the app in the platform name, but that doesn't matter, it still needs to have the environment folder, so maybe to "Android" you need to add the "Android environment" (right-click > add environment...).
It could be because you thought this is Cordova app and used mfp add environment in the wrong filesystem location (also looks like you're trying to use a CLI instead of Studio?).
Looking at the GitHub repository, this whole structure is unconventional and it's not clear why they did it this way.
The links to the documentation there are also dead. This looks like a dead project.
We're using Worklight 6.1.0.0 / WebSphere 8.0.0.2 (ND/aix).
This seemed pretty close to my question too, but for version 6.0.
I've successfully done uninstall/install to our worklight console war package. However, there is some extra work on re-deploying adapters and such. I was looking for a way to just update the console. Among the ant tasks there is a target 'minimal-update', which sounds like what I'm looking for (is it?). However when all other pieces fell into place, I have an error for mapping the datasources:
ADMA0007E: A validation error occurred in task Mapping resource references to resources. The Java Naming and Directory Interface (JNDI) name is not specified for resource reference jdbc/WorklightDS in module Worklight with EJB name .
Contents of the 'minimal-update' task is pretty much the same as for 'install'.
I tried that as update from websphere admin console (but i should use the ant task - right?), that gave me a wizard screen to map jdbc/WorklightDS from package to jdbc/WorklightDS on server. This left me wondering how could I tell this using the ant task.
The ant target minimal-update of the sample configuration files documented at http://pic.dhe.ibm.com/infocenter/wrklight/v6r1m0/topic/com.ibm.worklight.deploy.doc/devref/c_ant_tasks_sample_config_files.html is meant to update a WAR file already deployed (and not uninstalled). In particular, on WAS, it assumes that the JNDI datasources are in place.
If you have uninstalled the WAR file, you should use the target install instead, provided that your databases were created for Worklight 6.1.
If they were created for a previous version of worklight you must upgrade their schema as well running the target 'databases' (and if it's a production installation, you might want to read all the steps in detail at http://pic.dhe.ibm.com/infocenter/wrklight/v6r1m0/topic/com.ibm.worklight.upgrade.doc/devenv/c_upgrade_to_srvr610_in_production_env.html )
I'm just getting started with some of the samples at the Getting Started site, working with the Developers Edition. Whenever I Open Worklight Console, the eclipse environment abends. I'm sure I missed a set up item, but all seemed to install well. I appreciate any help / direction. Thanks.
I tried to post an image of the error, but stackoverflow indicates I need 10 reputations to post an image. Go figure.
The first line is Java was started but returned exit code=8096
There are some hits on this indicating that the license may not be compatible with the Rational license installed. Not sure what to do with that.
There's another post indicating Environment Variable corruption, but I don't have the corrupt Temp environment variables indicated.
StackOverflow has a FAQ explaining what one can and cannot do and when. It makes sense. Read it.
Did you at least create a new Worklight project and application?
If you do that and run the application by right-clicking on the application in the project tree and choose Run As > Run on Worklight Development Server this will: start the server + build the app + deploy the app.
Then you can right-click on the project icon and choose Open Worklight Console and you will see the console...
So unless you have some errors preventing the server from loading, the above should work.
Host the image elsewhere, like imgur.com
Explain what you have installed in your Eclipse. Which Eclipse is it? Did you install only Worklight Studio, or another plug-in in addition? Which?
What are those "hits" you mention? Elaborate.
Searching for the exit code in Google, I see the following IBM tech notes:
http://www-01.ibm.com/support/docview.wss?uid=swg21303648
http://www-01.ibm.com/support/docview.wss?uid=swg21567836
http://www-01.ibm.com/support/docview.wss?uid=swg21627887
Perhaps one of them is relevant for you as well.
If you have followed Idan's advice to Run on Worklight Development Server and it is still not started, try this:
Switch to the Servers view (on the bottom pane of Eclipse by default).
Check your Worklight Development Server status
Right-click and select Clean...
Select OK when prompted to discard all publish start.
Redeploy your app using Run As > Run on Worklight Development Server
I am not sure if this would clean up your environment variable error message as I have not seen that one, but it has helped with several other errors that have caused my server to not start or run properly. (The most common one I get is an Out of Memory in the server.)
I've deployed the jboss-as-helloworld-errai application in my standalone jboss7.1 instance, and I deleted it later ( in the */standalone/deployments folder). But every time I restart my server it redeploys that application.
Is there another place where jboss reads the application to deploy?
Best regard
Did you delete the file while the server was running?
Probably, JBoss still finds a deployment information in one your /standalone/configuration/standalone*.xml files (at the end of the file). JBoss unpacks its deployments in one of the /standalone/tmp/vfs/temp* folders. As long as it finds a deployment in your configuration file, it will start the application.
The deployment binaries are located under the standalone/data/content. These would also need to be deleted. The best solution is to properly undeploy the application via CLI, the maven plug-in or the web console.
This does not sound like expected behaviour. Can you please confirm the steps that you are taking when using the deployment folder? For example:
Deploy
Copy application file to /standalone/deployments folder
Deployment Scanner creates a .dodeploy marker file
Deployment Scanner picks up application and creates a .deployed marker file
Application confirmed as deployed (checking the Management Console to confirm)
Undeploy
Application deleted from /standalone/deployments folder
Delete application (or) delete .deployed marker file
Deployment scanner undeploys the application and creates .undeployed marker file
Confirm application removed in console
Restart server
Confirmed removal is persistent
The README.txt file in the deployments folder shows the simple undeployment workflow in one easy step in the command line.
rm $AS/standalone/deployments/example.war.deployed
Documentation
You can read more about the deployment scanner in the official docs. There's a topic about the scanner marker files, as well as a parent topic about the scanner and deployments in general. If you are finding issues with the scanner, it's a bug. You might like to test the expected behaviour, and also try the Management Console.
Red Hat Docs - Reference for Deployment Scanner Marker Files
Red Hat Docs - About Application Deployment
Potential Issues
Don't confuse the Deployment Scanner subsystem (which watches the Deployments folder for the Standalone server instance) with the Management Console or Management CLI deployments process. You might be better off using one of the Management tools instead of the hot deployment capability to allow for more control over the state and presence of your application.