I'm running WL 6.1 (6.1.0.01.20140310-1427) on a macbook air (latest OSX). I have a dojo hybrid application that I'm trying to connect to a remote WL server. When I generate an iOS app and I'm changing the address of the worklight server to a remote server. It does not change the address in the generated iOS code. The steps I follow are:
Open the Build Settings and Deploy Target... On the hybrid app folder.
Select the check box for Build the application to work with a different Worklight server.
Put in the new server information and click OK
Build all environments
After the build is complete, I launch into xcode and look at the worklight.plist and Root.plist files.
At this point they are still referencing my local server. If I edit them to point to the remote server, then my app works. Since these files are regenerated every time you do a build this is not a valid solution.
To verify it is nothing in my app, I created a default dojo hybrid application. Performed the steps I listed above. When I launched into xcode, the Root.plist and worklight.plist still have the default local server information.
So here is the funny thing. I also have a win7 system running the same level of WL developer plugin. I perform the same steps and the worklight.plist file is updated correctly on windows, just not in osx. The only other difference is the win7 version is running jre 1.7_21 where the osx is running 1.7_51. Both are in 64-bit mode.
I believe the real difference between your Mac and Windows machines is step 5, where you "launch into xcode". If by that you mean that you are actually doing Run As > Xcode project, then see below. This option is available only in Mac and not in Windows.
This is the expected behavior in Worklight 6.0.0.x and 6.1.0.x.
If after changing the server address to a remote server (rather than the local development server) and building, and then selecting Run As > Xcode project, this will overwrite the server settings back to the local development server.
Run As > Xcode project does 3 actions:
Build & deploy the app to the local Worklight Development Server
Generate an Xcode project (this in turn overwrites worklight.plist back to use local server settings)
Open the generated Xcode project in Xcode
So if you want to use the app with the remote server settings, then after changing the settings and build the app, either:
Copy the .zip from the your-iphone\package folder
Navigate in the filesystem to the iphone\native folder and double-click the .xcodeproj file to open the it straight in Xcode (like what Run As > Xcode project does)
For future releases of Worklight it is being considered to streamline the behavior so that no matter if you choose, local or remote server settings, Run As > Xcode project will always use the ones you've selected.
Related
I have an Application developed in Worklight 6.1 and I upgraded the application to Mobile first 7.1. I have build and deployed the application in Mobile first 7.1.
But my application Not able to invoke the adapter and displayed the Message "The server was unable to process the request from the application. Please try again later"
I have followed the below procedure for up gradation.
1. Installed the Mobile first 7.1 Plugin in Eclipse
2. Imported the Existing 6.1 project in to My work space(I hope Tool will
auto upgrade app to 7.1)
3. Build the application and it generated .war, .wlapp and .adapter files
4. we have installed the standalone 7.1 Server.
5. Deployed the build files in servers.
6. Created the apk and installed in Mobile.
Now it is showing the Message "The server was unable to process the request from the application. Please try again later" while launching the application.
From the logs i found the below details when i try to invoke adapter
invocationContext: null
Status : 404
invocationResult : undefined
Note: It was working well in development environment
Kindly suggest
It'd be more useful to see the complete server and client logs as well. Please upload and edit the question with links to the log files.
That said, in step 6 (Created the apk and installed in Mobile.) you do not mention if you have re-built the project with the correct remote server host, port and context root values. Make sure you've done that. See The Build Settings and Deploy Target command.
I am running Eclipse Luna 4.4.1 with Worklight Studio 6.2...
I have made changes to my Worklight project. For some reason, I cannot get these changes to be seen/previewed when opening in the Worklight Console...
I have made simple changes such as adding print (console.log) statements to see if these changes are making it out to the console... I have even removed design elements to see if I can get this preview to error out...
Here is what I do:
Highlight the app folder (the folder under the "apps" folder) and right-click
Select Run As > 2 Build All Environments
Once that is complete, I highlight the project folder (the topmost folder in the project) and right-click, selecting Open Worklight Console, which opens the console in Firefox
Click the Preview as Common Resources link in the Console
The "old" code/project runs -- no changes appear
I have tried Cleaning the project, closing and re-opening Eclipse, rebooting my machine, etc. but nothing seems to shake this up. Worklight seems to use the "old" code no matter what I do in Eclipse...
Is there a setting on Worklight I may be missing?
Starting Worklight 6.2 you do not need to either build or deploy your application in order to see changes made to web resources.
The following should suffice:
Create a Project and application
Run As > Run on Worklight Development Environment
Open console, view the application (keep this tab open)
In Eclipse, change some resource (image, CSS, HTML, JavaScript)
Return to the previously opened tab and refresh it
The change should be visible to you.
Something to try:
Close Eclipse
Open your TMPDIR and delete the wlBuildResources folder
Open Eclipse, try again
You can also try adding a mobile environment to your application; there are some reports this some times, show how, helps 'refreshing' the web resources used while previewing applications
You can also make sure you are using the very latest 6.2.0.01 iFix; there were preview-related fixes in the past. You can get it from IBM Fix Central website (assuming you are an IBM customer/business partner; for evaluation purposes you should download the latest available version, from the Eclipse Marketplace - v6.3)
Note that Run As > Build all environment does not actually deploy your modified web resources to the server, it only generates the .wlapp for later consumption elsewhere, so I suggest to follow my steps at the very top of this answer, by using Run As > Run on Worklight Development Server, and later on simply save (ctrl/cmd-s) and then go to the console to verify the changes are there.
I have a Worklight 6.0 project that uses the new Dojo 1.9 libs, I created an external dojo project, like the documentation suggested, then, in the main project properties, under "Dojo toolkit", it references this dojo19 project.
The project works on the local server, then I did "Run As" | "Build for Remote Server...", and entered the correct domain:port and context path, clicked Build, the *.wlapp files were updated. (I've also updated the settings for publicWorkLightHostname / publicWorkLightPort / publicWorkLightProtocol in the "Environment Entries for Web Modules" in the installed war to match the remote server names/port/protocol.)
But, after deploying both war and -all.wlapp file, accessing the app I get JS errors when it tries to refer to the dojo19 library:
The page at
https://<myIP>:9443/<myproject>/apps/services/www/ /mobilewebapp/default/IODMobile.html
ran insecure content from http://localhost:64441/dojo19/<myproject>/IODMobile/mobilewebapp/dojo/nls/core-web-layer_en-us.js.
The dojo19 is the project name in my Worklight developer workspace that I referred to above.
Why is it trying localhost? Seems there's a missing step here in deploying the dojo library project into Worklight.
Where are you trying to preview the application when you get the error message?
See the changes in Dojo in Worklight 6.0
If launching the application in emulator/simulator/device, see Billy Rowe's answer in this question
Partial copy/paste:
Step 1: Verify your application works in the Mobile Browser Simulator
with Provide Library Resources checked. If the Console log is showing
resources being served from the server, then these have to be copied
to your application before deploying to AVD or a device
Step 2: After you think you have all Dojo/resources within your
project, uncheck Provide Library Resources and test it again in MBS.
If it fails in MBS, then something is missing in your application that
is in the library/server. You can check Provide Library Resources and
retest to see if it shows you what that is. Not all resources are
shown, e.g. if there's a missing CSS file.
Also I would suggest to do all of this in the Development environment (that is, in Eclipse) before starting to deploy the .war file and .wlapp file etc... (which, BTW, I hope you're doing based on the new instructions for Worklight 6.0)
In the information center, it will show you how to uncheck the Provide Library Resources in the Console Log.
I think what you're running into is:
1) Something is being served from the Dojo Library/Server
2) A bug in 6.0 that used "localhost" instead of the IP of the host (your machine running eclipse). This is fixed in the 6.0 iFix. With this fix, you can run your app external to Studio and still use the Dojo Library/Server. Without this fix, you must have everything you need within your app.
Can you install the iFix and let us know if that fixed the problem?
I've just installed Worklight 6.0 on Mac OS X Mountain Lion 10.8.4.
I'm trying to build a very simple HelloWorklight app to test the installed environment and I'm getting errors building and deploying it.
I'm getting these errors in Eclipse console:
[2013-07-13 02:11:21] Starting build process: application
'HelloWorklightApp', all environments
[2013-07-13 02:11:21] Application 'HelloWorklightApp' with
all environments build finished.
[2013-07-13 02:11:21] Deploying application
'HelloWorklightApp' with all environments to Worklight Server...
[2013-07-13 02:11:21] Failed to deploy the application to
Worklight server: Worklight module
HelloWorklightProject was not
successfully started. Full details of the error are available from the
Worklight Development Server console.
The Worklight Development Server console in my browser shows:
Application Error
SRVE0777E: Exception thrown by application class
'com.worklight.core.auth.impl.AuthenticationFilter.doFilter:110'
javax.servlet.ServletException: Worklight Project not initialized
at com.worklight.core.auth.impl.AuthenticationFilter.doFilter(AuthenticationFilter.java:110)
at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:194)
at [internal classes]
I'm truly stuck. On the other hand I'm sure it must be something simple to fix it.
Has anyone got an idea how?
I had a similar problem (at least WDS console error looks the same).
A little bit history:
My problems started, when I updated Worklight to version 6 (with version 5 I had no problems). Some compilation erros were fixed by adding Websphere Library to a project. But my custom authentication still wasn't working.
How I fixed it:
open new workspace in Eclipse
import Worklight project
clean project
restart Eclipse
downgrade compiler compliance level (in Eclipse: Window > Preferences > Compiler and set "Compiler compliance level" to lower version)
rebuild project and try to run it
At this point it started to work. I've spend lots of time to find out that compiler stuff, but still I'm not sure which part requires that.
So we had this issue with 2 macs and it took us a solid day and a half to figure it all out.
We went through a lot of reconfiguring, re-downloading eclipse and worklight.
Make sure your config files from the update are correct. (worklight.prop and authConfig)
This is the big one. Install JDK 1.7 and reference the new JRE 7. When we
were running on Oracle JRE 6, we had a ton of errors and even a Java
Heap memory issue.
Once you install it, it may to be tricky to find the actually path to the JRE.
First, go to Eclipse > Pref > Installed JRE's > Add
Then, add a new standard vm. Click Directory on the next pane and browse to the install path of JRE.
We found it in [name of your HD] > Library > Java > JavaVirtualMachines > jdk1.7.0_25.jdk > Contents > Home > jre
It should load everything it needs and you can click the check box of the new JRE. For good measure, I changed the compiler to 1.7 as well.
The jdk folder may have a slightly diff name depending on what update you have. Hopefully this helps.
I got the same error after deploy an new app deployment.
What I've done on Server is:
delete all application
delete all extra configuration between new server instance and my current instance. In my case it was: applicationMonitor and shared librairy
clean
restart
After that I managed to deploy my application normally
window -> show view -> servers -> server configuration -> HTTP EndPoint -> host
By default the host will be *. Try to change the host as your local machine ip address. for example host = . After changing the host, close the server.xml and then try to rebuild the project.
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