Аргумент Java для указания файла Java.Security для JVM

Я ищу аргумент java (или, возможно, какой-то другой метод), чтобы я мог указать файл, который будет использоваться JVM в качестве файла java.security вместо того, чтобы использовать тот, который находится в JDK (в JRE lib).

Чтобы дать вам немного больше контекста, я работаю с сервером WebLogic, который был настроен кем-то другим и запускает две (или более) разные JVM на одном JDK. Теперь мы столкнулись с проблемой, когда работа, которую я выполняю на одной JVM, требует другого файла java.security, чем тот, который в настоящее время используется другой JVM . Я надеюсь g у меня будет способ просто указать моей JVM на новый java.security файл без необходимости указывать его на совершенно новый JDK (из-за нехватки места мы не хотели бы загружать JDK, специфичный для каждой JVM).

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

Я пытался найти решения, но, похоже, мой Google-Foo не так силен, как я надеялся. Надеюсь, у одного из вас есть ответ!

Большое спасибо.

РЕДАКТИРОВАТЬ
Извините, возможно, мое исходное сообщение было неясным, но меня интересует указание файла java.security, который также часто называют главным файлом свойств безопасности Java , а не файлом java. файл политики, который находится в том же каталоге.

Мое решение

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

Поскольку я не могу найти аргумент для указания при запуске, я решил, что мне придется отказаться от файла свойств java.security. Можно установить свойства и поставщиков (обычно настроенных в файле) в коде с помощью класса безопасности (java.security.Security). Итак, по крайней мере, на промежуточном этапе я планирую написать класс, который будет выполнять настройку конкретных конфигураций безопасности моей JVM после запуска (по сути, перезаписывая конфигурации по умолчанию, предоставленные файлом для другой JVM).Хотя очевидным недостатком этого решения является то, что оно не делает внешних конфигураций безопасности этой JVM, решение действительно предоставляет мне способ установить специфические свойства JVM и поставщиков, не влияя на конфигурацию других JVM, работающих на том же JDK.

Я ценю время и внимание, уделяемое другими. Спасибо =)