Как Домены glassfish отделены друг от друга?

GlassFish позволяет создавать N доменов. Каждый домен имеет свои собственные классы Java (библиотеки и т. д.) и системные настройки.

например, у нас есть два домена - domain1 и domain2.

через веб-консоль GF (http://localhost:4848) для domain1 было установлено одно системное свойство -com.temp.foo=test1. Кроме того, через веб-консоль GF (http://localhost:7575) для domain2 было установлено одно системное свойство -com.temp.foo=test2.

теперь, в domain1 

System.out.println(System.getProperty("org.temp.foo"))
//returns `test1`

и в domain2

System.out.println(System.getProperty("org.temp.foo"))
//returns `test2`

как я понимаю, GF и все его Домены работают в одном экземпляре JVM. И я не понимаю, как это возможно в одном экземпляре отдельных системных свойств JVM. Кто-нибудь может объяснить?

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

9
glassfish java java-ee

2 ответов

кажется, что понимание "GF и все его Домены работают в одном экземпляре JVM" неверно.

согласно текущей версии GlassFish документация (Глава 3):

домен содержит группу администрируемых экземпляров сервера GlassFish вместе. [...] Экземпляр сервера GlassFish-это одна виртуальная машина для платформы Java (Java Виртуальная машина или машина JVM) на одном узле, в котором находится сервер GlassFish бегущий.

, Что значит каждый экземпляр любого домена работает в своем собственном JVM! Как следствие, все они могут иметь свои собственные различные свойства системы.

справедливости ради: есть средства для администрирования виртуальные серверы в GlassFish, которые, кажется, разделяют JVM, но я думаю, что вы не говорите о них.

4

такие продукты, как GlassFish, JBoss, WebSphere,... "просто" используйте Java загрузка класс механизм для создания изоляции. Используя несколько загрузчиков классов, даже a static поля класса могут существовать "более одного раза"; и каждый" домен " получает свою особую версию этого.

начать чтение здесь или здесь например:

Application Universe-каждое приложение Java EE имеет свой собственный Вселенная загрузчика классов, которая загружает классы во все модули приложения.

и за этим, посмотрите в этой.

другими словами: хотя системный класс, очевидно, представляет собой "системный вид" - механизм загрузки класса должен позволить дать разные экземпляры системного класса для каждого домена. Таким образом, это позволяет иметь доменные свойства в каждом доменном системном классе. Но будьте точны: я не смог найти четких доказательств, подтверждающих это утверждение. На эту тему здесь и здесь должен помочь (более поздний, указывающий, что есть даже способы вмешиваться в система загрузчика).

но, думая дальше, есть проблема с этой идеей: на самом деле два механизмы загрузки классов. Есть загрузчики класса "система / пользователь"... и начальный загрузчик загрузчиком.

и загрузчик классов bootstrap фактически "запечен" в JVM (например, он реализован в собственном коде) - и это не может быть заменить.

и java.ленг.Система должна быть загружена этим загрузчиком классов bootstrap!

Так невозможно использовать " classloader magic "для включения системных свойств" для каждого домена"!

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

но, опять же; агенты приходят "после" загрузки завершены!

Итак, единственный логический вывод (принимая то, что осталось после исключения всех вариантов): посылка вопроса должна быть неправильной!

Это просто невозможно это разные "приложения", работающие на то же самое JVM дают различные системные свойства. И, к счастью, великий ответ Seelenvirtuose подтверждает этот вывод.

1