Как определить, что системное свойство исходит от оператора-человека, а не от значения по умолчанию?

Question

У меня есть отдельное приложение, упакованное в JAR, которое при запуске распаковывает себя во временный каталог и порождает дочерний процесс в этом каталоге.Причина в том, что какой-то сторонний код и конфигурация предполагают, что файлы данных находятся относительно текущего рабочего каталога, а java не имеет метода chdir (), поэтому единственный способ - переключить рабочий каталог для дочернего процесса.

Все работает нормально, кроме системных свойств.Оператор может решить указать некоторые системные свойства в командной строке, как стандартные, так и относящиеся к сторонней конфигурации:

java -Djava.io.tmpdir=/temp -Dsomething=else -jar foo.jar (parameters)

Системные свойства, доступные для родительского процесса Java, по умолчанию не распространяются.ребенку.Я должен сделать это сам.И здесь я сталкиваюсь с препятствиями: у меня нет возможности сказать, какие свойства установлены оператором, а какие инициализируются по умолчанию JVM.

Возьмите тот java.io.tmpdir.Если оператор предоставил это, у него есть веская причина для этого (возможно, расположение по умолчанию «диск заполнен»).Я должен установить его на дочерний процесс, иначе он потерпит неудачу.Но как мне узнать, пришло ли это от оператора?Это может быть просто значение по умолчанию.

Я могу попытаться установить все доступные системные свойства для дочернего процесса.Это занимает длинный список, и, что еще хуже, не работает в некоторых средах, где длина командной строки ограничена.

Единственный обходной путь, который я нашел до сих пор (довольно злой), - сначала запустить другой дочерний процесс., без каких-либо аргументов, и пусть он вернет к родителю все системные свойства, которые он имеет.Значения, совпадающие с теми, которые имеет родительский, являются значениями по умолчаниюОстальные должны быть переданы рабочему дочернему процессу.

У кого-нибудь есть лучшая альтернатива?

Answer 1

Там, где я работаю, у нас был медленно растущий список системных свойств, которые могут применять пользователи, и, хотя у нас не было дочернего процесса, о котором беспокоиться, у нас была другая проблема: их было просто слишком много.

Вместо того, чтобы задавать системные свойства пользователя через командную строку (или, в нашем случае, сделать строку в скрипте, которая запускает приложение, еще одно свойство дольше), мы добавили поддержку загрузки файла .properties по умолчанию.

Если вы можете убедить пользователей поместить туда постоянные свойства, а затем запустить процесс запуска дочернего процесса, а затем загрузить его из файла, вы можете полностью избежать головной боли.

Тем не менее, выСкорее всего, будут представлены сценарии отладки, где временные или одноразовые свойства желательны без изменения файла (не то, что это действительно большое дело).У вас есть несколько вариантов здесь:

1. Продолжайте использовать подход, которым вы сейчас пользуетесь.
2. Получите от пользователя возможность передавать системные свойства в качестве аргументов командной строки, которые you затем загрузите в системные свойства как родительского, так и дочернего процесса.
3. Скажем жестко, используйте файл.(Не страшная вещь, но я был бы раздражен этим решением как пользователь)

Answer 2

Выбранное решение:

Мне все еще пришлось пойти с дочерним процессом, который ничего не делает, но передает родителю все системные свойства, которые он получает для сравнения. Единственной незначительной проблемой, с которой я столкнулся, было свойство line.separator, из-за которого мой код чтения строк оступился на лишней пустой строке. Это было легко исправить.

Почему я не принял ни одного ответа:

Подходы, предложенные в ответах ниже, являются разумными, но ни один из них не является полностью удовлетворительным.

У меня нет особых полномочий для пользователей говорить им, что системные свойства Java должны передаваться через файл свойств или специальный аргумент командной строки. Это неудобно и идет вразрез с практикой работы (особые случаи всегда плохие).

Я также не могу выбрать подмножество системных свойств для передачи дочернему процессу. Документация системного класса не говорит, какие из них можно перезаписать (и здравый смысл не заменяет никакой документации). У конечного пользователя также есть возможность определять свои собственные свойства, и те, которые я не могу предсказать, ни по имени, ни по номеру.

Answer 3

Я не думаю, что есть хороший ответ на это.Но, к счастью, большинство стандартных системных свойств либо не могут быть переопределены, либо никто в здравом уме не переопределит.

Так что следующие подходы, вероятно, ваши лучшие ставки:

• передает подмножество стандартных свойств, которые, по вашему мнению, имеет смысл передавать,
• предоставляют способ указать параметры JVM (включая параметры -D), которые будут использоваться для дочерних элементов.JVM, или
• комбинация вышеуказанных подходов.