存储和编辑Java EE应用程序的配置 [英] Storing and editing configuration for Java EE applications

问题描述

UPDATE ：在撰写这篇文章一年后，查看关于此主题的博文： http://blog.ringerc.id.au/2012/07/java-ee-7-needs-improvements-in-app.html

...用于引用有关此主题的Java EE 7计划讨论。

---

我已经完成了一个小型的Java EE 6应用程序的编写工作，并且正在用适当的动态配置接口替换硬编码的首选项。

我不知道如何 - 或更具体地说，在哪里 - 存储设置。 必须是一些明显的标准方式，可以在各种框架和容器上正常工作，但对于我而言，我找不到它。

我想要的是一种简单的加载和存储设置的方法，一种适用于不同应用服务器和操作系统的设置，不需要用户进行任何配置，实际上可以正常工作的。 Java Preferences API是理想的 - 但在Glassfish 3.1下看起来很糟糕。

存储配置的选项在理论上将包括：

1. 使用容器环境中的上下文参数


2. 使用Java首选项API存储它们


3. 读/写一个属性文件...某处


4. 使用JPA将它们存储在容器提供的JavaDB中


5. 将它放入一个已加载的属性文件classpath


6. 使用系统属性设置配置选项或.properties文件的路径

这似乎是一个基本要求，在容器应该为您提供所有您可能需要的核心服务的环境中，这些都是很好的选择 - 但所有这些方法都有问题。

glassfish中的错误呈现（1）不可行，并且无论如何Glassfish的Web管理员用户界面缺乏配置上下文参数的任何方式，所以你必须使用`asadmin'和一些不太可爱的命令行语法来完成它。只能通过ServletContext访问上下文参数 - 在JSF2，JAX-RS和原始Servlet之类的框架之间不能以一致的方式访问上下文参数 - 但至少Seam Servlet可以处理它。

Glassfish中的另一个bug是已部署应用程序与Glassfish 中断（2）之间的库版本冲突。首选项后端无法将首选项刷新到磁盘，因此在重新启动应用程序服务器时，存储的首选项数据将丢失。 Java Preferences API似乎也被认为是J2SE /桌面版的东西，尽管它包含在Java EE 6规范中。

（3）可能工作 - 但是没有办法了解您的应用程序在文件系统上的读/写访问权限以及它应该在哪里显示。你无法做到这一点，因为它变成了鸡与鸡蛋的问题。可以应用各种特定于平台的猜测，但会在SecurityManager存在的情况下中断。

（4）可以工作，但它是一种飞行。它要求运行JavaDB服务并强制用户确保应用程序服务器中的JDBC和池资源配置正确。对于一个简单的工作来说，这是一个巨大且复杂的过程，实体建模并不适合偏好存储，因为它大部分都是关键/价值结构。

（5）可以工作，但要求用户知道将配置文件放在哪里可以在各种不同的应用程序服务器下找到的位置。这也使得应用程序难以提供任何类型的配置UI，因为它不一定能够找到配置文件的本地路径或打开它进行写入，特别是在存在SecurityManager的情况下。

（6）也可以工作，但强制用户在配置应用程序之前配置配置系统。毋庸置疑，这并不会让我兴奋，因为部署应用程序和创建资源的相对复杂的情况已经发生在尚未知道Glassfish / EE的用户身上。

所以......你如何处理选项的配置和存储？你有没有找到一种方式让你做到这一点，而用户不必配置任何东西来允许你的应用程序存储其配置？

解决方案

首选API的问题是由应用程序的战争中包含jaxb和stax实现jar引起的，由jersey-json提供。如果将这些排除在外（因为它们始终由应用程序服务器提供），首选项API将恢复正常运行。

它看起来像使用自定义用户界面进行设置的prefs API似乎是最好的选择。

UPDATE: See my blog post on this topic about a year after this was written: http://blog.ringerc.id.au/2012/07/java-ee-7-needs-improvements-in-app.html

... for references to the Java EE 7 planning discussion on this topic.

---

I've mostly finished writing a small Java EE 6 application, and am in the process of replacing the hard-coded preferences with a proper dynamic configuration interface.

I'm not sure how - or, more specifically, where - to store settings. There must be some obvious, "standard" way to do this that's expected to "just work" across various frameworks and containers, but for the life of me I cannot find it.

What I want is a simple way to load and store settings, one that works across different app servers and OSes, doesn't require any confguration by the user, and actually works properly. The Java Preferences API would be ideal - but seems broken under Glassfish 3.1.

Options for storing configuration would theoretically include:

1. Using context-parameters from the container environment
2. Storing them using the Java Preferences API
3. Reading/writing a properties file ... somewhere
4. Using JPA to store them in a JavaDB provided by the container
5. Putting it in a properties file that's loaded off the classpath
6. Using system properties to set configuration options, or path to a .properties file

This would seem to be a basic requirement that'd be well catered for in an environment where the container supposedly provides you with all the core services you might need - but all these approaches have issues.

A bug in glassfish renders (1) unworkable, and in any case the Glassfish web admin user interface lacks any way to configure context parameters, so you have to use `asadmin' and some less than lovely command line syntax to do it. Context parameters can only be accessed via the ServletContext - which isn't accessible in a consistent way between frameworks like JSF2, JAX-RS, and raw servlets - but at least Seam Servlet handles that.

What appears to be another bug in glassfish was a library version conflict between the deployed app and Glassfish breaks (2). The preferences backend fails to flush preferences to disk, so the stored preferences data is lost when the application server is restarted. The Java Preferences API also seems to be considered a J2SE/desktop thing, despite its inclusion in the Java EE 6 specs.

(3) might work - but there's no way to know where your app has read/write access on the file system and where it should look. You can't make this configurable, as it becomes a chicken-and-egg problem then. Various platform-specific guesses could be applied, but would break in the presence of a SecurityManager.

(4) would work, but it's nuking a fly. It requires that a JavaDB service be running and forces the user to make sure the JDBC and pool resources in the app server are configured properly. It's big and complicated for a simple job, and entity modelling isn't a lovely fit for preferences storage anyway, as it'll mostly land up being key/value structured.

(5) would work, but requires users to know where to put the config file where it'll be found under various different app servers. It also makes it hard for the app to provide any kind of configuration UI because it can't necessarily find the local path to the config file or open it for writing, especially in the presence of a SecurityManager.

(6) would also work, but forces the user to configure the configuration system before they can configure the application. Needless to say, that doesn't excite me, given how relatively complicated deploying the app and creating the resources already is for users who don't already know Glassfish/EE.

So ... how are you handling configuration and storage of options? Have you found a way that lets you "just do it" without the user having to configure anything to allow your app to store its configuration?

解决方案

The problem with the preferences API was caused by the inclusion of jaxb and stax implementation jars on in the application's war, pulled in by jersey-json . With these excluded (as they're provided by the app server anyway) the preferences API resumed functioning correctly.

It looks like the prefs API with custom UI for setup appears to be the best way to go.

这篇关于存储和编辑Java EE应用程序的配置的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！