За и против пользования общей библиотекой по сравнению с полностью инкапсулированным EAR
Я хотел бы отметить, что установка атрибута 'checked' в непустую строку приводит к появлению флажка.
Таким образом, если вы установите для атрибута «флажок» значение «ложь» , флажок будет установлен. Мне пришлось установить значение на пустую строку, null или логическое значение false , чтобы убедиться, что флажок не был проверяется.
4 ответа
Основной компромисс между потреблением памяти и управлением версиями.
Если вы упаковываете библиотеки в EAR, то каждое приложение будет создавать свои собственные экземпляры класса, потребляя некоторое количество permgen (или эквивалент) а также занимают место в куче для статических данных.
Если вы храните библиотеку в каталоге lib приложения, то будет только один экземпляр каждого класса. Однако это означает, что каждое из приложений, использующих эту библиотеку, должно использовать одну и ту же версию и (если не обеспечена обратная совместимость) должны обновляться одновременно.
Учитывая, что вы говорите о 100 EAR, проблема управления версиями вероятно будет большим. Если ваша библиотека не настолько огромна (и я собираюсь предположить, что вы работаете на 64-битном сервере с большим количеством памяти, так что сделайте это ОГРОМНЫМ),
Я бы также посоветовал упаковывать с EAR. Ad kdgregory указал на то, что он управляет сотнями программ, и объем тестирования, связанный с обновлениями, становится непосильным; Кроме того, вы должны использовать систему контроля версий для управления экземплярами ваших двоичных файлов для клиентов.
Вместо того, чтобы помещать общие jar-файлы в lib / app, вы можете использовать общую библиотеку WebSphere. Это позволяет назначать разные версии одной и той же разделяемой библиотеки разным приложениям, тем самым обеспечивая некоторую гибкость для версий сообщений.
Различные подходы к совместному использованию имеют тенденцию приводить к некоторым сложностям, вам необходимо внимательно изучить задействованные загрузчики классов.
Я бы предпочел остаться ванильным, упаковать все в EAR. Это простой, понятный Java EE. Каждое приложение может выбрать собственную скорость принятия версии платформы.
См. Статью Кейса Ботзума об упаковке общего кода .
Также следует отметить, что если вы хотите совместно использовать экземпляры объектов между EAR, например, с помощью websphere dynacache, классы для этих объектов необходимо будет загрузить из разделяемых библиотек. (в противном случае, даже если они могут быть одного и того же класса / версии, они будут загружены разными загрузчиками классов и несовместимы)
Я обычно также использую простой ванильный подход «пакет все в EAR», но затем делаю исключения для вещей, которые необходимо совместно использовать, и поместите эти классы в специальный совместно используемый JAR.