Я ищу аргумент java (или, возможно, какой-то другой метод), чтобы я мог указать файл, который будет использоваться JVM как файл java.security, а не использовать тот, который найден в JDK (в JRE lib).
Чтобы дать вам немного больше контекста, я работаю с сервером WebLogic, который был настроен кем-то другим, и работает с двумя (или более) разными JVM с одного и того же JDK. Мы столкнулись с проблемой, когда работа, которую я делаю на одной JVM, требует другого файла java.security, чем тот, который в настоящее время используется другой JVM. Я надеюсь, что мне удастся просто указать мою JVM на новый файл java.security, не указывая на совершенно новый JDK (из-за ограничений пространства мы хотели бы избежать загрузки JDK для каждой JVM).
Я понимаю, что настроенный сервер не идеален, но полная перестройка существующего набора не является жизнеспособной, а не той, что я могу сделать. Поэтому я надеюсь, что у кого-то может быть творческое решение, позволяющее нескольким JVM запускать один JDK, но с разными конфигурациями безопасности.
Я пытался найти решения там, но, похоже, мой Google-Foo не так силен, как я надеялся. Здесь, чтобы надеяться, у одного из вас есть ответ!
Большое спасибо.
ИЗМЕНИТЬ
Извините, возможно, мое оригинальное сообщение было неясно, но мне интересно указать файл java.security, также часто называемый файлом свойств безопасности Java, а не файлом java.policy, который находится в том же каталоге.
Мое решение
Я отправлю свое решение здесь только для справки других, которые могут попасть в аналогичную ситуацию.
Как я не могу найти аргумент для указания при запуске, я решил, что мне придется отказаться от файла свойств java.security. Можно указать свойства и провайдеры (обычно настроенные в файле) в коде, используя класс безопасности (java.security.Security). Поэтому, по крайней мере, в промежуточный период, я планирую написать класс, который будет проходить через настройку определенных JVM-конфигураций безопасности после запуска (существенно переписывая конфигурации по умолчанию, предоставляемые файлом для другой JVM). Хотя очевидным недостатком этого решения является то, что он не обеспечивает экстернализацию конфигураций безопасности этого JVM, это решение предоставляет мне способ установки специфических свойств и поставщиков JVM, не влияя на конфигурацию других JVM, работающих на одном JDK.
Я ценю время и внимание, данные другими. Спасибо =)
