This question already has an answer here:
IBM Worklight - How to retrieve an already-deployed .wlapp file?
(1 answer)
Closed 7 years ago.
Does anyone know what will be the locaton of wlapp files on worklight server, once you deploy the wlapp files it should be copying the same to some location, I am trying to back up some wlapp files from server and enable to find the location of same.
When you build your application in Worklight Studio, the build produces .wlapp files and stores them in the yourProject\bin folder, these files do not get deleted from the bin folder unless you've manually deleted them.
After deployment, the .wlapp file is not stored in the filesystem, but in the database.
So as for retrieving previously deployed .wlapp files if you do not have backup (this is very bad, BTW), these are stored in your database in the APP_SYNC_DATA table in the deployable column. You can try to extract and save the APP_SYNC_DATA.deployable data relevant for you as a .wlapp file.
More here: IBM Worklight - How to retrieve an already-deployed .wlapp file?
Related
Is a war file deployment required for changes in java file in the server folder in a worklight project?
Yes. Any changes done under the your-project\server folder trigger a re-generation of the .war file, where such data resides. This updated .war file then needs to be re-deployed to the application server.
How does MobileFirst Server update a single WAR file? does it update the existing or add with new version? can we have multiple war files with same application versions?
In an IBM MobileFirst Development environment (= Eclipse Studio plug-in or CLI tool), after any change made to files that reside in the your-project\server folder, an updated .war file is generated for you and is automatically being re-deployed to the server. You could say that the existing .war file is replaced with the new .war file.
In a QA/UAT/Production environment (= WebSphere Full profile/Liberty profile with IBM MobileFirst Server running on top of it), you as the person who administers the application server must re-deploy the updated .war file by either manually replacing the file or by using the IBM-provided Ant task scripts. As in the development environment, this action also replaces the existing .war with the new .war file.
A MobileFirst Server is able to run multiple projects (.war files) at the same time.
It is not clear from the question what do you mean by "can we have multiple war files with same application versions?"
If you mean multiple .war files of the same project, each being an exact replica of the other - it sounds useless to me, but as long as each .war file is given a different context root in the server.xml file, you should be able to do that.
If that is not what you mean, well, take the time to better explain yourself.
Before that, read the documentation: http://www-01.ibm.com/support/knowledgecenter/SSHS8R_6.3.0/com.ibm.worklight.installconfig.doc/topics/c_install_config.html
I have added the worklight.plist in nativeResource folder with my cloud server details. While building the environment it still gets my localhost development server details, not update from nativeResources folder. Same issue with android, copied wlclient.property file to nativeResources->assets->wlclient.property.
Thanks
AFAIK these two files are not files you can overwrite using the nativeResources folder.
Use the Build Settings and Remote Target wizard to build your application with connection properties to another Worklight Server.
Migrating my project(made up of 3 apps and 2 adapters) from Worklight v6.0 to Worklight v6.1 i'm facing problems over adapters migration.
I had already deployed .war, .wlapp and .adapter files in production environment using an Ant script(for .war file).
The application server used is Websphere, the dbms server used is Derby.
I upgraded the worklight studio's plugin to the latest version, created a new, clean workspace, exported the project from the old workspace and imported in the new one.
For what concerns development environment everything works.
For what concerns production environment i successfully deployed all the applications(but don't work yet becouse the adapters lack).
When i try to deploy the adapter(each one) i get the following exception:
Failed to deploy adapter 'adapter1.adapter'. The 'adapter' version '6.0.0' is different than the version of the Worklight project '6.1.0.00.20131219-1900'. Use Worklight Studio '6.1.0.00.20131219-1900' to build and deploy the application.
I tried also to create a new adapter and deploy it but i'm still getting the same error.
Edited the answer entirely based on edits to the question
All artifacts produced by Worklight Studio: .adapter, .wlapp and .war must be generated using the same Worklight Studio version.
Make sure that after importing the project to Worklight 6.1, that you are building all the the project's applications and adapters.
Next, you need to deploy the re-generated .war file and then deploy the .wlapp and .adapter files.
To verify that the adapter is of the same version as the project's .war file, extract the .adapter file from the bin folder and open the XML file. You should see the platform version like this:
<ns2:adapter xmlns:ns2="http://www.worklight.com/integration"
name="test" platformVersion="6.1.0.00.20131126-0630">
IBM Worklight Information Center topics to read:
Installing and configuring
Upgrading from one version of IBM Worklight to another
You can also see this in Worklight Console > About > Additional Support Information:
I'm trying to update an application in the evaluation version of Mule ESB EE.
I upload to repository, create a new deployment and start it.
But the server is still serving up the old .xml
I've tried stopping and starting the service, creating a new one with another name and whatnot but still no luck. Only thing that works is hot-deploying (drop the zip file into the directory) but that has the drawback of not showing up in the mmc.
Checking the Mulesoft forums yields one similar question that was posted 8 months ago (around october 2012) with no resolution.
Has anyone here run into this and knows of a fix?
Edit
I figured out a workaround:
When exporting the project in Mule Studio, instead of "Publish to Application Repository" select "Mule Studio Project to Mule......" (the zip file)
Using the mmc interface go to deployments tab, select repository and create new.
Import the .zip file you just created and deploy as usual.
(Also added this answer to the Mulesoft forum question)
I guess the workaround is all there is so I'm marking this as solved with that as the solution
Workaround:
When exporting the project in Mule Studio, instead of "Publish to Application Repository" select "Mule Studio Project to Mule......" (the zip file)
Using the mmc interface go to deployments tab, select repository and create new.
Import the .zip file you just created and deploy as usual.