Testing worklight服务器配置-分离适配器和服务器_Testing_Ibm Mobilefirst_Worklight Server

Testing worklight服务器配置-分离适配器和服务器

testing ibm-mobilefirst

Testing worklight服务器配置-分离适配器和服务器,testing,ibm-mobilefirst,worklight-server,Testing,Ibm Mobilefirst,Worklight Server,问题分为两部分。关于服务器配置特性的一般性问题，以及我们想要做什么的可能含义 worklight属性文件包含条目publicWorklightHostname、publicWorklightPort、publicWorklightProtocol。各个应用程序也在应用程序描述符中指定了几乎相同的信息。很明显，应用程序需要描述符信息来“查找”服务器。worklight.properties中相应条目的用途是什么？我相信这两个应该是匹配的我们有一个场景，我们需要将适配器部署到一台特定的机器上，因为

问题分为两部分。关于服务器配置特性的一般性问题，以及我们想要做什么的可能含义

worklight属性文件包含条目publicWorklightHostname、publicWorklightPort、publicWorklightProtocol。各个应用程序也在应用程序描述符中指定了几乎相同的信息。很明显，应用程序需要描述符信息来“查找”服务器。worklight.properties中相应条目的用途是什么？我相信这两个应该是匹配的

我们有一个场景，我们需要将适配器部署到一台特定的机器上，因为只有它可以连接到我们的后端。理想情况下，我们希望每个开发人员开发使用这些适配器的应用程序。每个开发人员将把他们的应用程序部署到自己的WL服务器上。我希望通过调整应用程序描述符，应用程序将使用共享适配器服务器进行服务器调用。这些似乎不起作用，Worklight似乎反对以这种方式使用其适配器，这从安全角度来看是有意义的。我们的方法能奏效吗？

在worklight.properties中找到的属性与 Worklight服务器。您提到的属性：
```
publicWorklightHostname
```
、
```
publicWorklightPort
```
、
```
publicWorklightProtocol
```
，是必需的，因为服务器本身需要知道它到外部世界的URL是什么，以便它可以将其嵌入重定向等。移动Web、桌面浏览器环境和Worklight控制台也需要这些功能
application-descriptor.xml中的属性与Worklight应用程序相关（大部分，而不是全部）。如前所述，应用程序需要知道要连接到哪个Worklight服务器
某些属性“重叠”，必须匹配（主机、端口、上下文根等）才能正常工作

至于你的设想，我认为是可行的

为此，您将部署到容纳适配器的Worklight Server的.war文件必须包含一个authenticationConfig.xml文件，该文件能够满足各种项目应用程序的需要，也就是说，包含所有应用程序所需的所有领域等

请记住以上几点：

配置application-descriptor.xml以指向容纳适配器的Worklight服务器

连接到该Worklight服务器的Worklight控制台，并部署应用程序生成的.wlapp文件。为了使Worklight Server能够识别应用程序，这是必须的

应用程序现在应该能够连接到服务器并使用适配器。
还假定这些适配器也是容纳应用程序的同一项目的一部分

注意事项：

在开发人员将进行的每个本地构建之后，他/她将需要将.wlapp重新部署到远程服务器，因为应用程序chceksum已更改，重新部署后，您将始终收到直接更新请求

（1）的替代方法是禁用直接更新

如果您有Java代码（例如用于自定义身份验证）并对其进行了更改，则还需要将.war文件重新部署到远程服务器

注2:

在Worklight 6.0中，Worklight.properties和application-descriptor.xml之间提到的服务器连接属性重叠不再存在
在Worklight 6.0中，您现在可以在同一服务器实例中并发运行多个Worklight项目（或.war文件），因此，尽管适配器仍然是每个项目实体，但您可以在运行Worklight server的同一服务器机器上的单独项目中复制它们，并拥有多个单独的项目（应用程序）使用该服务器连接到后端