1

两部分问题。关于服务器配置功能的一般问题，然后它可能对我们想做的事情产生影响。

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

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

4

1 回答 1

2

  • 在 worklight.properties 中找到的属性与 Worklight Server 相关。您提到的属性：publicWorklightHostname, publicWorklightPort, publicWorklightProtocol, 是必需的，因为服务器本身需要知道它到外部世界的 URL 是什么，以便它可以将其嵌入重定向等。这些对于移动 Web、桌面浏览器环境和 Worklight Console 也是必需的。

  • 在 application-descriptor.xml 中找到的属性（大部分，不是全部）与 Worklight 应用程序相关。正如您所提到的，让应用程序知道要连接到哪个 Worklight Server。

  • 一些属性“重叠”并且必须匹配（主机、端口、上下文根，...）才能正常运行。


至于您的情况-我认为这是可行的。

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

牢记以上几点：

  1. 配置 application-descriptor.xml 以指向容纳适配器的 Worklight Server。
  2. 连接到该 Worklight Server 的 Worklight Console 并部署生成的应用程序 .wlapp 文件。这是使 Worklight Server 可识别应用程序的必要条件。

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

笔记：

  1. 在开发人员将进行的每个本地构建之后，他/她将需要将 .wlapp 重新部署到远程服务器，因为应用程序 chceksum 已更改，并且如果不重新部署，您将始终受到直接更新请求的影响。
  2. (1) 的替代方法是禁用直接更新。
  3. 如果您有 Java 代码（例如用于自定义身份验证）并且您对其进行了更改，您还需要将 .war 文件重新部署到远程服务器。


注释 2：

  • 在 Worklight 6.0 中，上述提到的 worklight.properties 和 application-descriptor.xml 之间的服务器连接属性重叠不再存在。

  • 在 Worklight 6.0 中，您现在可以在同一个服务器实例中同时运行多个 Worklight 项目（或 .war 文件），因此尽管适配器仍然是每个项目的实体，但您可以将它们复制到同一台服务器机器上的不同项目中运行Worklight Server 并有多个单独的项目（应用程序）使用该服务器连接到后端。

于 2013-06-18T01:07:33.217 回答