将参数传递给 OSGi 应用程序
我所在的团队正在将一套 Java 应用程序转换为使用 OSGi。以前，我们使用了自己自制的类加载器系统，它与 OSGi 有一些相似之处，但除了麻烦之外什么也没有；我们希望通过转向使用 Apache Felix 这样的系统，我们可以拥有一个运行得更好的系统，同时需要我们更少的总体支持工作。
我们已经将组成应用程序的模块转换为 OSGi 捆绑包，这对于使用 Spring DM 来说基本上是一件轻松的事情。 然而，我们——嗯，我，因为这是我在团队中的责任——需要某种方法来通过像 Maven（或 Jenkins）这样的工具可靠地生成应用程序；绝对需要有一个可以为用户安装所有内容的可再发行应用程序安装程序。 （我们非常了解我们的用户群；他们想要一个简单的安装，安装后不会下载额外的东西，除非他们决定安装额外的插件，但那是另一个故事了。）我们不希望必须构建应用程序在控制台手动或使用 GUI，因为手动过程很可能会遇到愚蠢的人为错误；我们希望将其正确并调试一次。
此外，我们套件中的一些应用程序必须“像传统应用程序一样”采用命令行参数。 （有问题的应用程序在内部进行重要的处理，有时需要从其他进程调用，例如门户网站。）我知道这会导致默认的 Felix main 出现一些问题，它只允许命令行参数用于其自身目的，而不是默认提供将这些参数导出到捆绑包的方法。 （我知道我们可以用 shell 脚本包装一些东西，以便将它们作为属性传递，但是……ewwww...必须有更好的方法。我怀疑制作一个自定义 main< /code> 导出提供对命令行参数的访问的服务是最好的方法。）
所以，我的问题是自动构建整个 OSGi 应用程序的推荐方法是什么，我是否使用合理的方法来提供命令行参数？
I'm in a team that is converting a suite of Java applications to use OSGi. Previously, we used our own home-brew class loader system that has some similarities to OSGi, but it was nothing but trouble; we expect that by moving to using a system like Apache Felix we can have a system that works better while requiring less overall effort on our part to support.
We have been converting the modules that make up the applications into OSGi bundles, a largely painless affair with the use of Spring DM.
However, we — well, I as it's my responsibility in the team — need some way to reliably produce applications from this via a tool like Maven (or Jenkins); having a redistributable application installer that will install everything for the user is an absolute requirement. (We know our userbase fairly well; they want a simple install that won't download extra things after installation, well, not unless they decide to install extra plugins, but that's another story.) We do not wish to have to build the application manually at a console, or by using a GUI, as manual processes are too likely to run into silly human errors; we want to get it right and debugged once.
Moreover, some of the applications in our suite have to take command line arguments “like a conventional application”. (The application in question does significant processing internally, and sometimes needs to be invoked from other processes, such as web portals.) I know this causes some issues with the default Felix main, which only allows command line arguments for its own purposes instead of providing a way by default to export those to the bundles. (I know we could wrap things with a shell script so as to pass them in as properties, but… ewwww… there's got to be a better way. I suspect that making a custom main that exports a service providing access to the command line arguments is the best method.)
So, my question is what is a recommended way of building whole OSGi applications automatically, and am I using a reasonable approach to provide the command line arguments?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我猜你最好的选择是编写自己的 main 来专门完成你想要的事情。从 OSGi R4.2 开始，启动 API 是标准的并且非常简单。您可以从 Felix 的 Main 开始，因为它已经是通用的（即，它可以启动任何 R4.2 框架，例如 Felix 或 Equinox）并按照您的意愿进行更改。
如果命令行参数代表配置属性，您可以将它们推送到配置管理中。否则，就以您认为合适的方式暴露它们。
I'm guessing your best option is to write your own main that does specifically what you want. Since OSGi R4.2 the launching API is standard and pretty straightforward. You can just start from Felix' Main since it is already generic (i.e., it can launch any R4.2 framework, such as Felix or Equinox) and change it how you wish.
If the command line args represent configuration properties, you could just push them into Config Admin. Otherwise, just expose them how you see fit.
Apache Sling Maven Launchpad 插件 从一系列列表中生成一个完成的 OSGi 应用程序要包含的捆绑包，Sling 安装程序 可以也可用于包括初始配置。
尽管它们来自 Sling 项目，但这些模块并不要求您的应用程序使用 Sling 应用程序模型，它们只是用于构建、启动和配置它。
The Apache Sling Maven Launchpad Plugin generates a finished OSGi app from a list of bundles to include, and the Sling installer can be used to include initial configurations as well.
Even though they come from the Sling project, those module do not require your app to use the Sling app model, they are just used to build, launch and configure it.
对于您的参数，请使用 元类型。它将允许您的捆绑包加载默认值，并且当用户通过 Web 控制台或配置文件配置捆绑包时，元类型会将这些值注入到您的变量中。安装程序还可以在安装时通过配置文件设置这些值。
For your arguments, use metatype. It will allow your bundles to load with default values and when the user configures the bundle via the web console or config files, metatype will inject the values into your variables. An installer would also be able to set these values at install time via the config files.