Weblogic принудительно перекомпилирует EJB при переходе с версии 9.2.1 на версию 9.2.3.

У меня есть несколько EJB, скомпилированных с помощью Weblogic EJBC, совместимого с Weblogic 9.2.1. Наш клиент использует Weblogic 9.2.3. При запуске сервера Weblogic выдает следующее сообщение:
<BEA-010087> <The EJB deployment named: YYY.jar is being recompiled within the WebLogic Server. Please consult the server logs if there are any errors. It is also possible to run weblogic.appc as a stand-alone tool to generate the required classes. The generated source files will be placed in .....>
Следовательно, запуск сервера занимает 1,5 часа вместо 20 мин. Следующий запуск сервера занимает точно такое же время, то есть Weblogic не кэширует продукты перекомпиляции. Излишне говорить, что мы не можем перекомпилировать все наши EJB в версию 9.2.3 только для этого конкретного клиента, поэтому нам нужно решение на месте.
Мои вопросы:
1. Есть ли каким-либо образом указать Weblogic оставить эти файлы EJB как есть и избежать повторной компиляции во время запуска сервера?
2. Могу ли я указать Weblogic кэшировать перекомпилированные компоненты EJB, чтобы избежать длительных перезапусков?

Наш текущий обходной путь состоял в том, чтобы написать сценарий, который выполняет эту перекомпиляцию вручную перед созданием и развертыванием EAR (простым запуском java weblogic.appc ‹jar-name›), но мы предпочел бы избежать использования этого решения в производстве.


weblogic ejb
person RonK    schedule 01.08.2010    source источник
comment
Почему бы вам не использовать ту же версию, что и ваш клиент?   -  person Pascal Thivent    schedule 02.08.2010
comment
@Pascal: Наш клиент настаивал на работе с этой версией, мы не можем ее поддерживать, так как потребуется много испытаний, за которые никто не будет платить.   -  person RonK    schedule 13.08.2010
comment
Понимаю. Но кто тогда платит за время, потраченное на попытки улучшить время запуска? :)   -  person Pascal Thivent    schedule 13.08.2010
comment
:) К счастью, этот конкретный клиент платит за решение без фактического регрессионного тестирования. (Мы ожидаем обратной совместимости от BEA)   -  person RonK    schedule 20.08.2010

Ответы (3)


arrow_upward
0
arrow_downward

Я ИСПРАВИЛ эту проблему, потратив много времени на исследование и декомпиляцию некоторых классов. Я столкнулся с этим при переходе с weblogic8 на 10, к этому времени вы, возможно, поняли всю боль, связанную с технической поддержкой oracle weblogic.

к сожалению, у них не было настройки конфигурации сервера, чтобы отключить это

Вам нужно сделать 2 вещи

Шаг 1. Если вы откроете jar-файлы EJB, вы увидите

ejb-jar.xml=3435671213

com.mycompany.myejbs.ejb.DummyEJBService=2691629828

weblogic-ejb-jar.xml = 3309609440

WLS_RELEASE_BUILD_VERSION_24=10.0.0.0

вы видите эти хэш-коды для каждого из ваших имен ejb. Сделайте эти хэш-коды равными нулю. упакуйте файл jar и разверните его на сервере.

com.mycompany.myejbs.ejb.DummyEJBService=0

weblogic-ejb-jar.xml = 0

Это просто файл маркера, который weblogic.appc хранит в каждом банке ejb для запуска перекомпиляции во время загрузки сервера. Я автоматизировал этот процесс обнуления этих хадкодов. Эти хэш-коды остаются одинаковыми для каждого ejb, даже если вы выполняете appc более одного раза, если вы добавляете новый класс EJB или удаляете класс, эти записи добавляются в этот файл маркера.

Примечание 1: как получить этот файл? если вы откроете domains/yourdomain/servers/yourServerName/cache/EJBCompilerCache/XXXXXXXXX, вы увидите этот файл для каждого ejb.weblogic, который обнуляет хэш-коды после перекомпиляции

Примечание 2. Когда вы создаете EJB с помощью appc. сгенерируйте их в развернутый каталог, используя -output C:\myejb вместо C:\myejb.jar. Таким образом, вы можете поиграть с файлом маркера.

Шаг 2. Также вам нужен PATCH от weblogic. Когда вы устанавливаете патч, вы видите сообщение вроде этого: «ПУТЬ CRXXXXXX успешно установлен. Исключите перекомиляцию EJB для appc». я не помню номер патча, но вы можете запросить для этого weblogic.

Вам нужно использовать оба шага, чтобы решить проблему. Патч исправляет только часть проблемы. Удачи!

ура радж

person rajdevar    schedule 02.08.2010
comment
Спасибо, в конце концов мы решили перекомпилировать EJB один раз на сайте Заказчика вместо того, чтобы возиться с внутренними маркерами EJB (мы не хотим, чтобы Oracle говорила, что не может поддерживать проблемы, возникающие из этого сценария). - person RonK; 13.08.2010

arrow_upward
0
arrow_downward

файл маркера в EJB - WL_GENERATED

person rajdevar    schedule 02.08.2010

arrow_upward
0
arrow_downward

Просто для того, чтобы обновить решение, которое мы выбрали - в конце концов мы решили перекомпилировать EJB один раз на сайте Заказчика вместо того, чтобы возиться с внутренними маркерами EJB (мы не хотим, чтобы Oracle говорил, что не может поддерживать проблемы, возникающие из этого сценария).

Мы создали два сценария KSH: первый перебирает все файлы EJB jar, копирует их в temp каталог, а затем параллельно перекомпилирует их, запуская несколько экземпляров второго. скрипт, который делает только одно: java -Drecompiler=yes -cp $CLASSPATH weblogic.appc $1 (Конечно, с обработкой ошибок :))

Это решение сократило время компиляции с 70 до 15 минут. После этого мы повторно создаем файл EAR и повторно развертываем его с новыми компонентами EJB. Мы делаем это один раз для нескольких созданий среды UAT, поэтому здесь мы экономим довольно много времени (55 минут X количество env на дроп X количество дропов)

person RonK    schedule 20.08.2010