worklight server configuration - separating adapte

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 file has entries publicWorklightHostname, publicWorklightPort, publicWorklightProtocol. Individual applications also specify much the same information in the application descriptor. It's clear that applications need the descriptor information to "find" the server. What purpose do the corresponding entries serve in worklight.properties? I believe that the two are supposed to match.

We have a scenario where we need to deploy our adapters to a particular machine as only it has connectivity to our backends. Ideally we would like each developer to develop applications that use those adapters. Each developer would deploy their applications to the own WL Server. I was hoping that by adjusting the application descriptor the applications would use the shared adapter server for their server calls. These seems not work, Worklight seemingly objecting to its adapters being used in this way - which makes sense from a security perspective. Can our approach be made to work?

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:

Configure application-descriptor.xml to point to the Worklight Server housing the adapters.
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:

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.
An alternative to (1) is to disable Direct Update.
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.