I have some server with corrupted WL 6.1.0.0 install - the IIM does not show it in history, so I can not apply a fixpack in traditional way.
I need to update WL 6.1.0.0 to 6.1.0.1, in some non-traditional way.
Initially I thought that FixPack 001 major task is to update in /opt/IBM/Worklight/WorklightServer/ files worklight-ant-builder.jar, worklight-ant-deployer.jar, worklight-jee-library.jar (besides WAR application update, which I don't need - we don't use App Center Console, and WL applications are built with Studio 6.1.0.1 - no need to update)
I planned to copy the JAR files from the updated server, but comparing with another server which was updated (via IIM) to 6.1.0.1 I see that these files are just the same (however About menu tells 6.1.0.1 server version).
App Center Console is not used on the 6.1.0.0 server (actually I uninstalled it via WAS web admin console)
So, my question is: how to update WL 6.1.0.0 to 6.1.0.1 manually, possibly in non-supported way?
I'm not familiar with a manual way, however you should probably read and execute the recommended steps that are written in this user documentation topic: Upgrading from Worklight Server V6.1.0 to V6.1.0.1 in a production environment.
Highly suggested to also take a look at the parent topic.
Related
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 a worklight i/OS hybrid application built and deployed to the worklight console using RTC jazz team build and the ant-builder ant tasks (6.1.0.1). The ipa packaging is done on a separate machine, though using the same level of Worklight Studio (6.1.0.1).
I've compared the wlapp files that are generated, and they are basically identical except for some whitespace characters (tabs, line feeds), probably due to the different environments (Windows vs AIX), and the following:
index.html
"WORKLIGHT_NATIVE_VERSION": "3921556017",
"WORKLIGHT_PLATFORM_VERSION": "6.1.0.01.20140311-2356",
"WORKLIGHT_NATIVE_VERSION": "1475155033",
"WORKLIGHT_PLATFORM_VERSION": "6.1.0.01.20140311-2356",
deployment.data
native=3921556017
native=1475155033
However, the direct update never happens when the wlapp is updated on the server.
on the WL.Client.connect call, the following json comes back as part of the response
gadgetProps":{"directUpdate":{},"ENVIRONMENT":"iphone"}
What are we missing here? What can be preventing the direct update from triggering?
Any help would be greatly appreciated.
The 6.1.0.1 iFix version 6.1.0.01.20140518-1532 from IBM Fix Central seems to have resolved this problem for us.
And what if you are not using ant, but rather built the project in Worklight Studio straight to Xcode from then install the .ipa and test Direct Update. Does it work?
From your question it is not clear whether or not you've confirmed one or the other.
Regardless, since the v6.1.0.1 build you are using, several Direct Update-related fixes were introduce; one with close proximity to the error you mention (directUpdate:{ }), so I suggest to to open a PMR in order to receive the latest available iFix (not yet available at IBM Fix Central).
I use Worklight 5.0.6 and can't use direct update for a Windows 8 application.
IBM Worklight Information Center tells that windows 8 app can use direct update.
My way to test direct update as follows.
Please tell me how to use direct update in Windows8.
make windows8 env project
change wlInitOptions.connectOnStartup value "true" (in common\js\initOptions.js )
select [Build All and Deploy]
double click .jsproj file run simulator in visual studio 2012 for Windows8
make app "back ground"
change html file and "re [Build All and Deploy]"
make app "foreground"
This documentation page is misleading (I will open a defect to correct it).
Direct Update (as in the process of updating the web resources of the application after it has already been installed on the device) is available ONLY for iOS and Android. In those environments following your steps will indeed trigger a Direct Update.
The update (or rather, upgrade) of Desktop applications has no relation what-so-ever to the Direct Update mechanism mentioned above.
For Desktop enviornments consider it like updating any other desktop application - where you up the version number, and the app detects that there is an update available or so.
In the case of Adobe Air and Windows 7/Vista Gadgets:
Build your application and install it
In application-descriptor.xml, up the value of the version attribute in the envrionment's element (for instance from "1.0" to "1.1")
Build again
I believe that now you need to go to the Worklight Console and re-download the installer, and it will detect that it needs to upgrade rather than install afresh).
Note: iGoogle, Facebook, Windows 7/Vista Gadgets and Dashboard environments will be removed in the next version of Worklight. All have ample replacements with other supported Worklight environments.
In the case of Windows 8:
Direct Update most certainly does not exist for it
The steps above are also not relevant as it is not a downloadable executable
I have just upgrade my Eclipse client running Juno to Worklight 5.0.6 developer edition (5.0.6.20130311-0918)
The projects upgrade fine, but when building them and deploying to the local worklight server I get a constant 'persistency data access problem' This occurs across all of my projects and has only been seen since the update.
Any idea on what is causing this problem and how to solve?
I would add a screen shot of the issue but I am not allowed
Based on your comment - in 5.0.6, the database schema has changed, so you have missing tables now. In the Developer Edition of Worklight, upgrade is not supported (this is handled when purchasing a license and using the IBM Installation Mananger for installing Worklight).
Do you mean "HSQL"? What is "Web SQL?"
In any case you will need to clean your database so that it will be re-created, this time with the missing tables.
If you use the default database provided by Worklight (HSQL), go to your Eclipse Workspace and delete the WorklightServerHome folder. Then, re-build your application.
I want to upgrade Glassfish without internet connection. But I have already downloaded the latest version.
I have done the following steps,
For eg. galssfish-3.0 is the older version and glassfish-3.1 is the newer version.
Step: 1
I just copied the glassfish-3.0/glassfish/domains/domain1 and pasted in glassfish-3.1/glassfish/domains
Step: 2
In glassfish-3.1/bin ./asadmin i just give the command asadmin> start-domain --upgrade
then i checked the version asadmin> version the ouput was
Version = GlassFish Server Open Source Edition 3.1.1 (build 12)
Command version executed successfully.
Is this correct or I need to follow some other ways to achieve this? If wrong Please guide me the right way.
Can anyone help me?
Thanks in advance,
Gnik
Regarding the Oracle GlassFish Server 3.1 Upgrade Guide you did it right.
There are some hints in this guide for the migration of deployed applications:
Application archives (EAR files) and component archives (JAR, WAR, and
RAR files) that are deployed in the source server do not require any
modification to run on Oracle GlassFish Server 3.1. Components that
may have incompatibilities are deployed on GlassFish Server 3.1 with
the compatibility property set to v2 and will run without change on
GlassFish Server 3.1. You may, however, want to consider modifying the
applications to conform to Java EE 6 requirements.
...
Applications and components that are deployed in the source server are
deployed on the target server during the upgrade. Applications that do
not deploy successfully on the target server must be deployed manually
on the target server by the user.
If a domain contains information about a deployed application and the
installed application components do not agree with the configuration
information, the configuration is migrated unchanged, without any
attempt to reconfigure the incorrect configurations.
You should read through the guide carefully and check your deployed applications for any errors / exceptions during server startup or manual redeployment.
Some time ago I made an update as described in the update guide from 3.0 to 3.1.1 and cannot remember any bigger problems.