JBOSS 4.2.3 Manual

  • Tutorial
Копаясь в своих старых записях совершенно случайно наткнулся на документ JBOSS 4.2.3 Manual, написанный мной (а по сути скомпилированный из разных источников) несколько лет назад. И чтобы не пропадать добру, решил немного поделиться знаниями с уважаемым Хабрасообществом.
Если вы являетесь специалистом с опытом более года — скорее всего ничего нового для себя не найдете и можете сразу проходить мимо, дабы не тратить свое время. Статья же может быть полезна следующим людям:
  • студентам, начинающим свой путь в IT карьере по Java направлению
  • java junior разработчикам
  • junior инженерам внедрения и техподдержки
  • junior deploy и build инжеренам

Понятно, что версия JBoss 4.2.3 достаточно древняя (сейчас актуален 8-ой JBoss, который по сути уже и не «Jboss»), но считаю, что она все еще может быть полезна, учитывая наличие большого количества старого унаследованного java-кода и приложений в жестоком интерпрайз секторе, которые все же необходимо иногда поддерживать.

Содержание




Что такое JBoss


JBossAS — J2EE сервер приложений с открытым исходным кодом.
Cервер приложений — это программная платформа (software framework) предназначенная для эффективного исполнения процедур (программ, механических операций, скриптов) которые поддерживают построение приложений.
J2EE — Java Platform, Enterprise Edition. набор спецификаций и соответствующей документации для языка Java, описывающей архитектуру серверной платформы для задач средних и крупных предприятий. Основная цель спецификаций — обеспечить масштабируемость приложений и целостность данных во время работы системы. J2EE является промышленной технологией и в основном используется в высокопроизводительных проектах, в которых необходима надежность, масштабируемость, гибкость.
JMX — Java Management Extensions ( JMX ) — Java технология, которая поставляет инструменты для управления и мониторинга приложений, системных объектов, устройства (например, принтеров) и сервис-ориентированных сетей. Эти ресурсы представлены объектами, называемыми MBeans.

Поддерживаемые форматы приложений


  • The WAR application archive;
  • The EAR application archive ;
  • The SAR application archive;
  • The *-ds.xml file defines connections to external databases;
  • XML files with MBean service definitions;
  • JAR files containing EJBs or other service objects directly in JBoss AS

Поставляемые в комплекте с JBoss конфигурации серверов


Минимальный (minimal) — включает сервис логирования, JNDI сервер и URL сканера развертывания, чтобы иметь возможность развертывания приложений. Это чистый сервер. Он без веб-контейнера, EJB или JMS поддержки. Это не J2EE 1.4 совместимая конфигурации.
EJB — Enterprise JavaBeans. спецификация технологии написания и поддержки серверных компонентов, содержащих бизнес-логику. Является частью Java EE.
JMS — Java Message Service. Cтандарт промежуточного ПО для рассылки сообщений, позволяющий приложениям, выполненным на платформе J2EE, создавать, посылать, получать и читать сообщения. Коммуникация между компонентами, использующими JMS, асинхронна (процедура не дожидается ответа на своё сообщение) и независима от исполнения компонентов.

По умолчанию(default) — является базой J2EE 1.4 Это наиболее часто используемые услуги, необходимые для развертывания приложений J2EE. Он не включает JAXR службы, службы IIOP, или любой из службы кластеризации.
Java API for XML Registries (JAXR)
IIOP (Internet Inter-Orb Protocol) используется GIOP для TCP/IP. IIOP является конкретной реализацией абстрактных определений GIOP.
GIOP (General Inter-ORB Protocol) — абстрактный протокол в распределённых объектных системах

Полный (all). Все конфигурации и все доступные услуги. Это включает в себя RMI / IIOP и службы кластеризации, которые не загружаются в конфигурации по умолчанию.
Если вы хотите знать, какие службы настроены в каждой из конфигураций, смотрите в файлах:
jboss-4.2.2/server/<instance-name>/conf/
jboss-4.2.2/server/<instance-name>/deploy

Методы администрирования JBoss Server


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

The JMX Console (путь: localhost:[ порт ]/jmx-console/ )
Обеспечивает доступ к произвольным администратративным параметрам, например выключение сервера, остановка услуг, внедрения новых услуг и т.д. Он может быть устанавливлен как и любые другие веб-приложения или удален.

The Web Console (путь localhost:[ порт ]/web-console/)
Использует сочетание апплета и HTML и обеспечивает тот же уровень доступа к администратративным функциям, что и JMX-console.war.

Tomcat info (путь localhost:[ порт ]/status?full=true)
Информация о запущенных компонентах

Структура дирректорий конфигурации сервера


  • conf — каталог содержит файлы конфигурации сервера, например, JBoss-service.xml — определяет основные запущенные сервисы.
  • data — каталог доступен для использования сервисам, которые хотят хранить контент в файловой системе. Здесь хранятся данные, позволяющие восстановить работу сервисов после перезагрузки сервера. Некоторые JBoss сервисы, такие как базы данных Hypersonic, хранят ствои данные здесь.
  • deploy — каталог содержит службы для развертывания (те, которые могут быть добавлены или удалены по время работы сервера). Он также содержит приложения для текущей конфигурации сервера. Развертывание кода приложения происходит путем размещения пакетов прикладных программ (JAR, WAR и EAR-файлов) в указанный каталог. Каталог постоянно проверяется на наличие обновлений, а также любые модифицированные компоненты будут повторно развернуты автоматически.
  • lib — каталог содержит файлы JAR (Java библиотеки, которые не должны быть развернуты «на горячую»), необходимые для этой конфигурации сервера. Вы можете добавить необходимые файлы библиотек сюда. Например JDBC драйверы и т.д. Все JAR в этом каталоге загружаются в общий «сlasspath» при запуске.
  • log — каталог для записи файлов журнала. JBoss использует пакет log4j для логирования, и вы можете также использовать его непосредственно на ваших собственных приложений внутри сервера. Параметры логирования могут быть сконфигурированы через CONF/JBoss-log4j.xml файл конфигурации.
  • tmp — каталог используюется для временного хранения файлов Jboss
  • work — каталог используется Tomcat для компиляции JSP

Содержимое дирректории conf

  • JBoss-service.xml — определяет основные сервисы и их настройки.
  • jndi.properties — файл определяет JNDI InitialContext свойства, которые используются внутри сервера JBoss, когда InitialContext создается с помощью конструктора без аргументов
  • Java Naming and Directory Interface (JNDI) это Java API организованный в виде службы каталогов, который позволяет Java клиентам открывать и просматривать данные и объекты по их именам.
  • JBoss-log4j.xml — настройка логирования
  • login-config.xml — этот файл содержит конфигурацию аунтификации, которые применяются при использовании безопасности на основе JAAS
  • JAAS — Java Authentication and Authorization Service
  • props/* — каталог содержит пользователей и роли JMX-консоли
  • standardjboss.xml — содержит Standard JBoss EJB конфигурацию
  • standardjbosscmp-jdbc.xml — Этот файл представляет собой файл конфигурации по умолчанию для движка JBoss CMP (Container-Managed Persistence)
  • xmdesc/-mbean.xml* — каталог содержит XMBean дескрипторы для некоторых служб указанных в JBoss-service.xml файле.

Содержимое дирректории deploy

  • jbossjca-service.xml — является реализацией сервера приложений спецификации JCA. Он предоставляет средства управления связи интеграции адаптеров ресурсов на сервере JBoss.
  • JCA( Java EE Connector Architecture ) — решения для соединения серверных приложений и корпоративных информационных системам (EIS) как часть решений для корпоративных приложений для интеграции (EAI)
  • properties-service.xml — позволяет настраивать PropertyEditors JavaBeans, а также их свойства.
  • Настройка EJB3 сервисов осуществляется правкой файлов ejb3-interceptors-aop.xml и ejb3.deployer
  • ejb3-entity-cache-service.xml настройка кластерного кэша для EJB3 entity beans (см. пункт Кластеризация).

Запуск JBOSS


Запуск JBoss как приложения

Для запуска необходимо выполнить пакетный файл run с необходимыми параметрами:

run.bat
usage: run.bat [options]
options:
    -h, --help                    Show this help message
    -V, --version                 Show version information
    --                            Stop processing options
    -D<name>[=<value>]            Set a system property
    -d, --bootdir=<dir>           Set the boot patch directory; Must be absolute or url
    -p, --patchdir=<dir>          Set the patch directory; Must be absolute or url
    -n, --netboot=<url>           Boot from net with the given url as base
    -c, --configuration=<name>    Set the server configuration name
    -B, --bootlib=<filename>      Add an extra library to the front bootclasspath
    -L, --library=<filename>      Add an extra library to the loaders classpath
    -C, --classpath=<url>         Add an extra url to the loaders classpath
    -P, --properties=<url>        Load system properties from the given url
    -b, --host=<host or ip>       Bind address for all JBoss services
    -g, --partition=<name>        HA Partition name (default=DefaultDomain)
    -u, --udp=<ip>                UDP multicast address
    -l, --log=<log4j|jdk>         Specify the logger plugin type

Для остановки необходимо выполнить пакетный файл shutdown с необходимыми параметрами:
usage: shutdown [options] <operation>
options:
    -h, --help                Show this help message (default)
    -D<name>[=<value>]        Set a system property
    --                        Stop processing options
    -s, --server=<url>        Specify the JNDI URL of the remote server
    -n, --serverName=<url>    Specify the JMX name of the ServerImpl
    -a, --adapter=<name>      Specify JNDI name of the MBeanServerConnection to use
    -u, --user=<name>         Specify the username for authentication
    -p, --password=<name>     Specify the password for authentication
 
operations:
    -S, --shutdown            Shutdown the server
    -e, --exit=<code>         Force the VM to exit with a status code
    -H, --halt=<code>         Force the VM to halt with a status code

Запуск JBoss как сервис в Windows

Для данной цели можно воспользоваться Tanuki java service wrapper.
В таком случае у нас будет следующий пример: wrapper.exe -i ..\etc\conf\wrapper.conf
Usage:
  wrapper <command> <configuration file> [configuration properties] [...]
  wrapper <configuration file> [configuration properties] [...]
     (<command> implicitly '-c')
  wrapper <command>
     (<configuration file> implicitly 'wrapper.conf')
  wrapper
     (<command> implicitly '-c' and <configuration file> 'wrapper.conf')
 
where <command> can be one of:
  -c  --console run as a Console application
  -t  --start   starT an NT service
  -a  --pause   pAuse a started NT service
  -e  --resume  rEsume a paused NT service
  -p  --stop    stoP a running NT service
  -i  --install Install as an NT service
  -it --installstart Install and sTart as an NT service
  -r  --remove  Uninstall/Remove as an NT service
  -l=<code> --controlcode=<code> send a user controL Code to a running NT service
  -d  --dump    request a thread Dump
  -q  --query   Query the current status of the service
  -qs --querysilent Silently Query the current status of the service
  -v  --version print the wrapper's version information.
  -?  --help    print this help message 

Вообще tanuki java service wrapper достаточно полезная утилита, которой возможно стоит посвятить отдельную статью в будущем.

Запуск сервисов и приложений при работающем JBoss


./server/<instance-name>/deploy
При удалении или перемещении в эту папку файлов приложений, они будут сразу же развертываться с отображением результатов в лог-файлах.
Пример:
Удаляем файл ear-deployer.xml
...
INFO  [TomcatDeployer] undeploy, ctxPath=/mbg, warUrl=.../tmp/deploy/tmp5055106795108270921mbg-2.10.1.41.ear-contents/mbg-console-exp.war/
INFO  [TomcatDeployer] undeploy, ctxPath=/webstarter, warUrl=.../tmp/deploy/tmp5055106795108270921mbg-2.10.1.41.ear-contents/mbg-webstarter-exp.war/
....

Помещаем файл mail-service.xml в каталог deploy
...
INFO  [org.jboss.mail.MailService] Mail Service bound to java:/Mail
DEBUG [org.jboss.mail.MailService] Started jboss:service=Mail
...


Настройки безопасности


Чтобы закрыть доступ пользователей к какому либо сервису JBoss нужно раскомментировать параметры в файлах (например чтобы закрыть доступ к jmx-console):
deploy/jmx-console.war/WEB-INF/jboss-web.xml
deploy/jmx-console.war/WEB-INF/web.xml

Имя пользователя и пароль берутся из файла:
conf/login-config.xml

Который используюет параметры из файлов:
conf/props
jmx-console-roles.properties
jmx-console-users.propertie

Настройка портов


Имеется возможность указать JBoss серверу какие порты использовать для своей работы.

Для этого необходимо поменять на нужные номера портов значения в файлах:
port-bindings.xml (если данный файл задан в конфигурации conf/jboss-service.xml и задан ServiceBindingManager)
\server[server_name]\conf\jboss-service.xml
Посмотреть текущие используемые порты можно из Web Console.

Настройка RMI


RMI (Remote Method Invocation) — программный интерфейс вызова удаленных методов в языке Java.
В терминах RMI объект, который вызывает удаленный метод, называется клиентским объектом, а удаленный объект — серверным объектом.
Компьютеры выступают в роли клиента и сервера только для конкретного вызова. Вполне возможно, что при выполнении следующей операции эти компьютеры поменяются ролями, то есть сервер предыдущего вызова может сам стать клиентом при обращении к объекту на другом компьютере.

URL, который клиент может использовать для получения удаленной ссылки на объект. Эта ссылка применяется для вызова методов удаленного объекта. URL обычно имеет форму
rmi://хост: порт/ИмяУдаленногоОбъекта
где хост представляет собой имя компьютера, который выполняет сервер реестра (rmiregistry) для удаленных объектов (он также является компьютером, на котором выполняется удаленный объект),
порт представляет собой номер порта, на котором выполняется сервер реестра на хост-компьютере, а ИмяУдаленногоОбъекта — имя, которое клиент будет предоставлять при попытках обнаружить удаленный объект в реестре.

Для переопределения портов RMI в jboss необходимо изменить параметры RmiPort и RMIObjectPort в файле
\server[server_name]\conf\jboss-service.xml

Настройки для подключения к БД


Источники данных конфигурируются в файлах с суффиксом -ds.xml
Данные файлы могут лежать в дирректориях jboss/server/default/deploy либо jboss/server/default/farm при использовании кластерной конфигурации JBoss
Примеры конфигурационных файлов для подключения к БД можно увидеть в документации: jboss/docs/example/jca

Кластеризация


Самый простой вариант организации кластера на JBosss — это запуск нескольких экземпляров сервера в локальной сети с параметром -c all

Связь между узлами осуществляется c помощью коммуникационной библиотеки JGroups, которая предлагает основные функциональные возможности отслеживания узлов, которые находится в кластере и надежного обмена сообщениями между членами кластера.
Узлы могут быть динамически добавлены или удалены из кластеров в любое время, путем запуск и остановки канала с конфигурацией и именем, совпадающим с другими членами кластера.
По умолчанию 4.2.x А.S., создает четыре различных канала:
  • копирование веб-сессии службы,
  • EJB3 копирование SFSB службы,
  • службы кэширования EJB3,
  • ядро общего назначения службы кластеризации службы, известной как HAPartition

Политика Load-Balancing (Балансировщика Нагрузок)

Балансировка на стороне клиента

Типы балансировки на стороне клиента:
  • Round-Robin — каждый запрос отправляется на новый узел, проходя последовательно по списку узлов. Первый узел случайно выбирается из списка.
  • Random-Robin — для каждого запроса целевой узел выбирается случайным образом из списка.
  • First Available — один из доступных узлов случайно выбирается в качестве основной мишени и затем использоваться для каждого вызова. Когда список целевых узлов измененяется (так как узел стартует или умирает), будет выбираться новый узел цель. Каждый клиент выбирает свой собственный целевоой узел независимо от других.
  • First Available Identical All Proxies — имеет такое же поведение, как «First Available», но выбор целевого узла является общим для всех клиентов. Так что если два клиента используют одну и ту же целевую службы (например, EJB), каждый клиент будет использовать одну и ту же цель.


Развертывание приложения в кластер

Чтобы развернуть приложение в кластере, необходимо скопировать его в папку:
<server_name>/farm/
После этого приложение будет автоматически развернуто на других узлах кластера.
Чтобы удалить приложение, достаточно удалить его из папки <server_name>/farm/ на одном из узлов кластера и оно будет удалено и из других узлов.

Конфигурация farm-развертывания (множественное развертывание) доступна через файл farm-service.xml находящегося в директории deploy/deploy.last
Если необходимо включить поддержку farm-развертывания в вашу конфигурацию, то нужно скопировать файл farm-service.xml в дирректорию с вашей конфигурацией, например:
$JBOSS_HOME/server/your_own_config/deploy/deploy.last

Конфигурация cluster-service.xml

Настройки работы служб JBoss в кластерном режиме находятся в файле cluster-service.xml в директории /deploy
  • optional-attribute-name — обязательный атрибут для службы HAPartition который используется для связей внутри кластера
  • URLs — указывает на каталог в котором находятся приложения для развертывания их в кластере. Нужно указывать так: farm/, т.е. полный урл будет таким: $JBOSS_HOME/server/all/farm
  • ScanPeriod — интервал проверки папки на изменения
  • Port — необязательный атрибут, который указывает адрес, по которому HA-JNDI сервер ожидает клиентов JNP. Значение по умолчанию 1100
  • Backlog — это необязательный атрибут для указания ожидания, используемого серверным сокетом TCP по время ожидания клиентов JNP. Значение по умолчанию 50 .
  • RmiPort — определяет, какой порт сервер должен использовать для связи с заглушкой. Этот атрибут является необязательным. Значение по умолчанию 1101. Если значение не установлено, то сервер автоматически назначает порт RMI.
  • AutoDiscoveryAddress — необязательный атрибут, указывает групповой адрес для прослушивания автоматического обнаружения JNDI. Значение по умолчанию значение свойства системы jboss.partition.udpGroup, или 230.0.0.4, если это не установлено.
  • LoadBalancePolicy — указание типа Балансировщика нагрузки
  • Имеется возможность запустить несколько копий некоторых сервисов, указанных в файле cluster-service.xml путем конфигурирования нарстроек (напр. адерсов портов и т.д.). Это бывает необходимо, если сервер является узлом у нескольких различных кластеров.

Известные проблемы кластеризации в JBoss версии 4.2.3

  • Если вы положите архив в папку all/farm/ и присоедините сервер к уже работающему кластеру, то данное приложение не будет развернуто, т.к. JBoss не знает это новое приложение для развертывание или же это старое приложение, которое было удалено из других узлов кластера, пока данный сервер был недоступен.
  • Нельзя поместить в кластерную конфигурацию приложения для развертывания в виде папки, т.к. оно не будет корректно развернуто на других узлах кластера.
  • Развертывание и сворачивание приложения не является атомарной операцией. Т.е. если приложение не будет развернуто на одном из узлов кластера, то это не помешает развертывание данного приложения на других узлах кластера. Невозможно сделать откат. Нельзя контролировать поряд развертывания приложния на всех узлах кластера, т.е. оно может разворачиваться одновременно на всех узлах, что сделает сервис временно недоступным для клиентов.


P.S. Исправления, замечания, дополнения а также комментарии привествуются.
Поделиться публикацией
Комментарии 20
    0
    Аааа, mammoth shit!

    Вероятно, стоит поправить блок «Поддерживаемые форматы приложений», то непереведённый кусочек смотрится странно.
      0
      Мне кажется, что данный блок лучше оставить в исходном виде, уж больно специфические вещи в нем описаны.
      Ведь лучше так:
      the SAR application archive
      Чем как-то так:
      приложение в архиве формата SAR или SAR архив-приложение
        0
        Как минимум можно перевести
        The *-ds.xml file defines connections to external databases;
        XML files with MBean service definitions;
        JAR files containing EJBs or other service objects directly in JBoss AS

        А по первой части можно написать в стиле WAR (Webapp ARchive), SAR (Service ARchive), EAR (Enterprise ARchive).
      0
      JBOSS 4 — эх, молодость! джуниорство босоногое)
        0
        Вот, если бы этому мануалу дали продолжения, золотой ман получился бы :)
          0
          А что конкретно вас в продолжении интересует?
            0
            Больше информации по каждому пункту.
          0
          JBOSS: Jmx-Console и JMXInvokerServlet. Сколько же серверов было взломано и забекдорено благодаря JBOSS. Черви, шеллы, руты… Ностальгия. JBOSS, cпасибо тебе, за такие простые и эффективные механизмы pwnage и внимательных админов, что читают мануалы!
            0
            Чем сложнее конфигурирование системы, тем больше в ней дыр
            0
            Красава, пока что один из лучших туториолов о жбоссу. Но уже конечно эра 7го на дворе, а там и WildFly уже родился.
              0
              7-ой это да, но у многих в продакшене до сих пор старые версии.
              0
              Где мои семнадцать лет )) Помню, мы в итоге отказались от JBOSS, т.к. красная шапка не публиковала сорцы для патчей. Можно было, конечно, годами ждать major releases, либо судиться с Red Hat ввиду явного нарушения LGPL… Но проще оказалось мигрировать на другой продукт.

              Интересно, JBoss EAP по-прежнему нельзя собрать из сорцов, или что-то поменялось?
                0
                Сейчас можно, но готовых скриптов для сборки никто не предоставлял. По крайней мере, для jboss as 7.1.
                  0
                  Скрипты для jboss AS ничем не привлекательны. Это community edition, для которой и так доступны официальные сборки. Вот только релизов надо ждать годами.

                  В то же время, коммерческий вариант EAP обновляется гораздо чаще. Понятно, что готовые сборки без лицензии не получить. Но LGPL обязует публиковать сорцы. Вот только не знаю, выполняет ли Red Hat на сегодняшний день свои обязательства.
                    +1
                    Вы говорите про всю платформу (включая всякий мониторинг, web framework kit) или только appserver, входящий в EAP?

                    Если только appserver, то его исходники лежат тут: ftp.redhat.com/redhat/jbeap/6.3.1/en/source/, необходимые артефакты для сборки лежат тут maven.repository.redhat.com/techpreview/eap6/6.3.1/. Если лень собирать самому — есть. например, github.com/hasalex/eap-build от Alexis Hassler, который гуглится первой ссылкой по «build jboss eap».

                    Jboss AS 7.2.0.Final, соответствующий JBoss EAP 6.1.0.GA доступен на GH и собирается мавеном. Как-то патчил и собирал без проблем.

                    А в чём они нарушали LGPL? Они не предоставляли исходники подписчикам?

                    У меня из возможностей jboss as 7 использовались только базовые (servlet, jax-rs, cdi), но я переехал на голый tomcat/jetty, т. к. хотелось независимых от jboss'а версий weld, resteasy, jackson, slf4j и т. д. Оно не на много сложнее, но проблем меньше.
                      0
                      Хорошие ссылки, беру к себе в копилку. Возможно пригодится в следующем проекте.

                      У Вас, похоже, небольшое несоответствие: официальный faq утверждает, что Jboss AS 7.2.0.Final, соответствует JBoss EAP 6.1.0.Alpha, а не 6.1.0.GA, как у вас.

                      И да, LGPL обязует публиковать сорцы. Причем не только для подписчиков, а для всех. Если собрать из сорцов EAP 6.3.0 свой билд, то можно легально использовать его в production environment без всякой подписки.
              0
              Как я вижу, даже в случае GPL, нет обязанности отдавать собранную программу и/или исходники всем. www.gnu.org/licenses/gpl-faq.html#DoesTheGPLRequireAvailabilityToPublic


              Прочитайте внимательно вопрос из Вашей ссылки. Распространение GPL'd software for a fee действительно ни к чему не обязывает.

              Но случае изменений в (L)GPL коде, есть прямая обязанность открыть исходники. В этом, собственно, вся суть GNU лицензий.
                0
                Но случае изменений в (L)GPL коде, есть прямая обязанность открыть исходники. В этом, собственно, вся суть GNU лицензий.
                Только тем, кто легально получил копию программы. Суть GPL — в наборе свобод, а не в бесплатности (которое необязательное). Исходники требуются для свободы изучения/модификации, в первую очередь.

                Если вы легально получили бинарную сборку и/или исходники (которые, например, доступны со страницы jbossas.jboss.org/downloads), то coryright не запрещает вам это распространять. Но стоит учитывать, что в этом случае вы явным образом нарушаете EULA и часть законодательства по товарным знакам. Но вы имеете полное право вырезать их и пересобрать EAP. Это явно указано в EULA.

                Также приведу фрагмент из этого поста:
                Essentially we give you three choices:
                1. Stick with community — You get always get the latest and greatest cutting edge stuff (including experimental features), but you have to get support from the community and update more frequently since the community really only focuses on the latest major + minor version.
                2. Buy an EAP subscription — You get all of the features above, which lead to minimizing the amount of work you need to spend on app server maintenance and support.
                3. Self build and support EAP — You get some of the benefits of the enterprise releases (e.g. patches to older major versions and so on), but you have to invest time and energy to build and maintain/verify your app server distribution bits.


                Ситуация очень напоминает Firefox-Iceweasel. И то, и другое под MPL, но первый нельзя распространять на некоторых условиях (из-за ограничений по trademark'ам).
                  0
                  Но случае изменений в (L)GPL коде, есть прямая обязанность открыть исходники. В этом, собственно, вся суть GNU лицензий.

                  Только тем, кто легально получил копию программы.

                  Вы заблуждаетесь. Открытие кода, это не обязательство перед покупателями продукта.

                  3. Self build and support EAP — You get some of the benefits of the enterprise releases (e.g. patches to older major versions and so on), but you have to invest time and energy to build and maintain/verify your app server distribution bits.

                  Это именно тот вариант, о котором я говорю с самого начала.

                  Ситуация очень напоминает Firefox-Iceweasel. И то, и другое под MPL, но первый нельзя распространять на некоторых условиях (из-за ограничений по trademark'ам).

                  Я ни слова не написал про распространение ПО. Вы же возвращаетесь к этому сценарию второй раз. Зачем?

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое