When I install (upload) new .wlapp file in application's console, I would like to make backup of the existing application set up. I am not sure where unZIPed wlapp files located after they uploaded via console, so I don't know, which folder to backup.
Also, is .wlapp makes modification of database and filesystem backup is not enough in this case?
Or, rephrase question: what can I do to backup current wlapp before trying new wlapp install. So I can safely back out if anything went wrong?
The .wlapp is located in the following location inside of your workspace:
/"WORKSPACE_NAME"/"PROJECT_NAME"/bin
On a successful build of your project the .wlapp for your environments will be found in the above location. You will see environment specific .wlapps as well as one that includes all of the environments. If you wish to backup these files you can simply copy them to another location after a successful build. Also as a note if you update the version of application environments inside of your applicationDescriptor these wlapps should manage each specific version in the bin folder as well. For example:
FormBasedAuthApp-iphone-1.0.wlapp
FormBasedAuthApp-iphone-2.0.wlapp
Once the wlapp is deployed it is actually stored in the database and it is much harder to guarantee exporting this resource. Please look Idan's post here for suggestions on this topic:
IBM Worklight - How to retrieve an already-deployed .wlapp file?
The wlapp file once uploaded to Server becomes a part of Database and can not be retrieved as a normal file for backup.
The best practice is to keep the wlapp file in a separate backup and also making sure that you change the version before building a new wlapp (especially for the production environment)
Related
I'm working on an IBM MobileFirst Platform 7.1 project where there are many name value pairs in the worklight.properties file.
Say for example,
HOST_NAME = www.google.com
I access these variables form the MobileFirst adapter.
var hostName = WL.Server.configuration["HOST_NAME"]
There will be cases where I'll have to change the HOST_NAME in the worklight.properties to a different value. But sometimes, even after the value is changed in the worklight.properties file, they are not getting updated in the adapter.
Every time when I change the values I do the following,
Clean the project
Restart the server
Deploy the adapter again
Nothing seemed to change the value.
I suspect, the MobileFirst server caches the values and reuses the old values without updating the new ones. I say this because, I tried deleting the values in the worklight.properties file, and even tried deleting the file itself. Still the adapter was using the old value.
I tried deleting the MobileFirstServerConfig Folder in my workspace. Even that didn't work.
It would be great if someone could help me clear the cache or find a work around to this issue. Thanks in advance.
I kind of followed the above method but initially it didn't work.
But later I tried to follow these steps in this exact order and it seemed to work.
Stop Worklight Server.
Remove your project from Mobile First Development Server.
Go to the "bin" directory and remove your project war.
Clean and Build the entire workspace.
Start the server
Deploy the adapters
Run your app.
The worklight.properties file is embedded into the project runtime WAR file. So, if you change anything in worklight.properties, you must rebuild the WAR file and redeploy it. Based on your description, it sounds like you're only building the adapter (and not the app). At minimum, I would suggest to remove the runtime WAR file from the project "bin" directory (just to ensure that it gets rebuilt) and build all app environments. That should build / redeploy the WAR file and restart the server, and then what you're doing should work.
Here are the steps to follow:
1. If worklight server is up and running, stop it or restart your system.
2. Clear bin folder.
3. Do Clean Project and Build for enviournment.
4. Open Mobile first Console(Start server)
5. Deploy All adapters
6. Run your app.
If wlq or wl error is comming we can give an alert message 'test' in our main file where we have all the javascript files.
It's convenient while developing with the MFP studio (Once any files change, the client will get a update notification which is so-called "direct-update"). But how could make this in a MF production server ?
Do we have to do "Replace project war file" in the MF Server configuration Tool and then the re-select a large version number .wlapp file in the worklightconsole ?
Unlike what Srik wrote - you shouldn't carelessly delete the old .wlapp. By doing so, users who use the version of said .wlapp will not longer be able to connect to the server.
So you if need to trigger a direct update, re-deploy the updated .wlapp file when you need to, don't first delete it.
Do not delete it even if deploying a new version (1.1 instead of 1.0).
You should delete only after you are certain that all of the users of 1.0 have migrated to 1.1.
1.1 constitutes of a new version that was also uploaded to the app store.
You can force users to upgrade by "remote disable"ing v1.0 (and point to download the new version). When everyone migrated, you can then delete the old version if you really feel like it.
Deletion is done via MobileFirst Console.
Load the console URL
Click on Applications
You can delete:
The entire all with all of its environments:
or a specific environment, or a specific version of an environment (if you had for example 1.0 and 1.1):
You can delete the old .wlapp file and put in your new .wlapp file. There is no need to replace the .war file
Agree with what #Idan Adar wrote, and make some addtion IMO:
You are doing iterative development of your app and upgrade your product frequentlyly, but just in UI level and adapter level, you can just update .wlapp files (DO NOT delete it ) which will trigger a direct update;
I don't think version number in WL console is so important to the end user (they cannot see it and they don't care), so you can just define a version number inside the app then update by direct update;
If you changed something big, and changed something platform related ,e.g : in iOS developing you change worklight.plist (in this file, which WL server your app is connecting to or WL platformVersion is defined here), then you have to rebuild your app and publish them to App Store or Android market.
We have weblogic 10.3.6.0 installed on windows server. We have stagging deployments enabled.Deployment process consists of undeployment for the old application and deployment for the new application vie python script. Each deployment consists of several .war files.
All .war files are versioned, ex:
application-a-123.war
applicatiom-b-222.war
The problem is that following directory is not cleaned after deployment:
C:\oracle\middleware\user_projects\domains\myApp\servers\SERVER-xy\tmp_WL_user
As the result there are many directories left from older deployments.These directories take to much disk space on server.
Is there a possibility to force weblogic to delete non-used folders in this directory? Or maybe modify deployment process, so older folders will be deleted after deployment?
I want to enable user customization at run time with Oracle ADF. With JDeveloper, if I deploy my application directly to the server, a window permits me to choose a repository previously registered on my Enterprise Manager, as depicted in following image:
In this way my application works great. Now I would to deploy to EAR file (in order to save a copy of my release) but I don't know how to target MDS repository. On the web I've found that maybe the adf-config.xml file has to be modify, but in which way?
have a look at this blog entry, which explains how to do it. Apparently this information needs to be provided upon EAR file deployment
http://andrejusb.blogspot.de/2011/05/target-mds-repository-for-adf.html
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.