worklight server configuration - separating adapters and server

Question

Two part question. Generic question about a server configuration feature, and then it\'s possible implications for what we\'d like to do.

The worklight properties fi

Answer 1

• 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.

• The properties that are found in application-descriptor.xml relate (mostly, not all) to the Worklight application. As you'ved mentioned, for the application to know to which Worklight Server to connect to.

• Some of the properties "overlap" and must match (host, port, context root, ...) for proper behavior.

As for your scenario - I think it is workable.

For this to work, the .war file you will deploy to the Worklight Server housing the adapters will have to contain an authenticationConfig.xml file that is able to cater for the needs of the various projects' applications - that is, contain all required realms, etc for all apps.

Keeping the above in mind:

1. Configure application-descriptor.xml to point to the Worklight Server housing the adapters.
2. Connect to the Worklight Console of that Worklight Server and deploy the generated .wlapp files of the applications. This is a must in order to make the applications recognizable by the Worklight Server.

The applications should now be able to connect to the server and use the adapters.
It is also assumed that these adapters, too, are part of the same project housing the applications.

Notes:

1. After every local build the developer will make, s/he will need to re-deploy the .wlapp to the remote server, because the application chceksum has changed and w/out re-deploy you will always be hit with Direct Update request.
2. An alternative to (1) is to disable Direct Update.
3. If you have Java code (for example for custom authentication) and you make changes to it, you will need to re-deploy the .war file to the remote server as well.

Notes 2:

• In Worklight 6.0 the mentioned overlap in server connectivity properties between worklight.properties and application-descriptor.xml is no more.

• In Worklight 6.0 you are now able to concurrently run multiple Worklight projects (or, .war files) in the same server instance, so while adapters are still per-project entities, you can have them duplicated in separated projects on the same server machine running Worklight Server and have multiple separate projects (applications) use that server to connect to the backend.