Afternoon All,
Here is my context:
I am setting up an existing worklight project with App Envs for IPhone, Android, and Mobile Web.
When using the Worklight Console to preview the apps, I get context root errors from the iPhone app only. (I get the Error: The Server was unable to process the request from the appl...)
When I open the browsers JS console, I see the problem is that the app is requesting the wrong context root. It is accessing the /worklight/ context, which is not there.
The contextroot that does work is the following:
http://localhost:8080/apps/services/api/[APPNAME]/iphone/init
The Context root that the iphone is trying to hit:
http://localhost:8080/worklight/apps/services/api/[APPNAME]/iphone/init
Here is the weird part. The context root is fine for the Android, and Mobile Web environments. Only the iPhone environment is having context root issues.
All three environments are sharing the same application-descriptor.xml file and same server.
Below are some file outputs.
Files below:
/server/conf/worklight.properties
publicWorkLightHostname=localhost
publicWorkLightProtocol=http
publicWorkLightPort=8080
publicWorkLightContext=/worklight/
/apps/[APPNAME]/application-descriptor.xml
<worklightServerRootURL>http://localhost:8080</worklightServerRootURL>
So a couple of questions.
1) When setting the context roots, what is the relationship between the client and server. Do the context roots have to match between the two? Is one a master and the other simply slaves from that and does not need settings?
2) (Somewhat unrelated) While debugging this issue I have come across zero documentation about how to go about "un-deploying" the server in the Eclipse dev ide. (un-deploy the server is right from IBM's documentation) I need to know how to redeploy the server when I make changes to the server settings (worklight.properties). I have seen references to cracking open the war manually, to just stopping and starting the server in the IDE.
Any help is greatly appreciated.
If you are using a context root, it must exist in both worklight.properties and application-descriptor.xml. make sure both match, then re-build and deploy and see if the problem persists.
When using the development edition of Worklight, your server is based on Jetty which is run within Eclipse (it is bundled with the Worklight Studio plug-in you have installed in Eclipse). You do not need to "undeploy" anything. Simply make the changes to worklight.properties and application-descriptor.xml and re-build your application. The changes will make their way to both the server and client.
Do note, though, that using a context root is mainly for when using application servers such as Tomcat, Liberty or WAS.
Related
I installed IBM Mobile First 8.0.0. I deployed Push service and the tables are also created. In the mobile first console the push service is showing as inactive. On inspecting the element in the chrome error window it points to GET URL returning 404. When i paste the URL in the browser and execute, it returns the live update adapter is not available and the database may be corrupted
Any help in this regard is highly appreciated
If you installed the MobileFirst DevKit, then this shouldn't happen since everything is built-in. Try reinstalling in this case.
If this is a production or test environment installation using the IBM Installation Manager and Configuration tool, then you may have specified an incorrect path of the push services .war file. You can confirm this by comparing the various paths that are defined in the application server's server.xml file.
I do not understand the purpose of the properties listed in worklight.properties:
publicWorkLightHostname
publicWorkLightProtocol
publicWorkLightPort
Those properties are set when you do in eclipse the Run As -> "Build settings and deploy target..."
Are they duplicated? Which one is the valid one? Are they used in different ways?
I have read the documentation in info center:
https://pic.dhe.ibm.com/infocenter/wrklight/v6r1m0/index.jsp?topic=%2Fcom.ibm.worklight.deploy.doc%2Fadmin%2Fr_configuring_the_ibm_worklight_server_location.html
But there is no mention to the "Build settings and...".
See this question and answer: worklight server configuration - separating adapters and server
The properties that are found in worklight.properties relate to the
Worklight Server. The properties you have mentioned:
publicWorklightHostname, publicWorklightPort, publicWorklightProtocol,
are required because the server itself needs to know what is its URL
to the outside world, so that it can embed it in redirects and such.
These are also required for the Mobile Web, Desktop Browser
environments and Worklight Console.
For example:
Create a new application and add the Mobile Web environment > Run on Worklight Development Server deploy. Open Worklight Console and click on "Get application URL". Copy the URL. Go to worklight.properties, change the publicWorklightPort to "100"; Go back to console, compare the previous URL with the current.
From Javier:
They are not used by the mobile apps. They are shipped with the .war and are used by the .war to provide information to the user like the web url, but the server does not use them for the execution of a mobile app.
With Direct Update, the mobile application can be automatically update with a new version of the web resources. In order to update the native resource, a new version of application must be uploaded to application store.
Consider the case that I have an update for my Worklight app with both native and web resources code update which has already been in application store.
Questions:
Is the following a correct way to update the app?
Step 1. Package the app in .ipa / .apk (with native + web code) and submit to application store
Step 2. Deploy an updated .wlapp file (with web code) to Worklight Server.
In application store, I can specify the application version when uploading the application. Will the application version be incremented automatically once I deploy the .wlapp to Worklight Server?
If the user does not update his application in application store and open the application, since there is a new web resource update in Worklight Server, it means that there will be a direct update alert box to prompt the user to download the latest application and in this case only web resource will be downloaded. There are some problems when the native code and web code are correlated?
Thanks a lot.
This would essentially be the correct order of steps, yes.
However, since you say you're updating both the native and web resources, I would make sure that the existing app can work with just the web resources update (without updating the native), because once deploying the .wlapp to the Worklight Server, existing users will receive a Direct Update.
If this scenario is not one you want to support, then in application-descriptor.xml you should also up the value of the version=" " attribute in the environment's element. When building the app after doing so, this will create a new .wlapp (for example: myProjectNameMyAppName-1.1.wlapp instead of ...-1.0.wlapp).
This means that the existing 1.0 users will not receive any Direct Updates, unless you deploy an updated ...-1.0.wlapp to the Worklight Server.
In relation to the above, no, the application version is not incremented automatically, it is something you need to control manually.
Also, I don't think the version value is something you control in the application store interface...
IFAIK the application version is changeable in Xcode prior to creating the .ipa for iOS and in AndroidManifest.xml prior to generating the .apk for Android (and in similar fashion for other environments).
EDIT: Actually... I think that changing the version value in application-descriptor.xml will also up the application's version number. Need to look at the end result (in AndroidManifest.xml or the Xcode project, in Xcode).
This would really depend on the behavior of your application and how resilient you've written it to be in the face of updates. I have slightly covered this in #1 above.
Other than talking about it theoretically I would suggest taking the jump actually upload an app to an application store, and test it privately, of course. This would be the most convenient to do using Google Play where publishing an app is near-instant.
I have developed a webapplication in my local machine. the application is hosted on tomcat 7.0.22 server. the application is accessed using http://localhost:8080/app
When i use this in my localmachine, I am not facing any problems. But when I intend to share the link with my fellow team mates using the links http://myipaddress:8080/app, I am getting Javascript errors. I placed the js files in the build path of the application.
Even i have noticed the tables width are changed in the same browser
I am unable to find the problem. Can any one help
Thanks,
Vamsi
When testing on your own machine, use your own IP instead of "localhost" and should be able to compare apples with apples and avoid confusing cause and effect.
I would say to check the configuration of your host or vhost files, but if all included JS files are on the same host, that is unlikely to be the problem.
My guess is that you hard coded a path somewhere or that the problem is related to some other difference between testing from your machine and their machine (different browser, versions, plugins, etc) and not actually related at all to the domain. Could possibly also be a file permission problem (but that is a wild guess).
I'll be using RTC in the near future here at work. My question is: where does it put the files the team members will be working on? I understand that each programmer will work on the projects files and they will push the changes to the main repository. We have a local web server where we test our work (php). So, do we have to configure RTC to publish the files to the web server? or the RTC server must be installed in the webserver so it can save the files?
We use Rational Team Concert almost exactly as you describe, and it works brilliantly. My small team of web developers collaborates on website source code and delivers it to two different streams depending on its readiness: production-stream and staging-stream. Then we have defined two builds that check out the source code, move some things around, and push the files to the web servers via SCP. So, with a few clicks we kick off a staging build, watch it finish in about two minutes and everyone can see the changes on the staging server. When the code is ready for prime-time, the change sets are delivered to production-stream and the production build is kicked off, which is configured to copy the files to the production web server.
But even before a staging or production build is run, any of us can simply configure a local web server in RTC using the Eclipse PDE and Web Tools add-ons and see the site running in localhost as we develop.
All our work is done within Rational Team Concert, from planning, to bug tracking, to source control, to builds. It's very well-suited for website management.
Your understanding is correct - you work on files locally, and they get uploaded on to the server when you checkin. Bear in mind that checkin in RTC terms really means back-up your files to the server, it is a Deliver command that shares the files with others (it is worth a quick look at the articles on jazz.net that explains how SCM works).
One way to pubish to your php server is to make that part of a build, or a build in its own right (which RTC also handles - in conjunction with your favourite build tool). The build would copy the files to the php server. The advantage of doing this as a build is you will know exactly what versions of your files are being copied, and you will be able to reproduce this copy at any point in the future.
You do not need to install the RTC server on the php server.
You can also try posting on the forums on http://jazz.net/ if you have questions on RTC.
Hope that helps.
Another alternative would be to use the command line interface to accept all changes into a workspace and run that with a cron job.
To handle discarded change sets, you'd probably want to use something like:
scm workspace replace-components <workspace-name> stream <uuid-of-stream> --all
after you had initially loaded the workspace on your web server.