2010-08-01 1 views
1

У меня есть несколько EJB, скомпилированных с помощью EJBC Weblogic с 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, чтобы избежать длительных перезапусков?Утилиты Weblogic перекомпилируют EJB при переходе с 9.2.1 до 9.2.3

Нашего текущий обходной путь был написать скрипт, который делает это перекомпиляцию вручную до создания и развертывания Уха (в просто запустив Java weblogic.appc < банку-имя >), но мы предпочли бы избежать этого решения, существует используемый в производстве.

+0

Почему бы вам не использовать ту же версию, что и ваш клиент? –

+0

@Pascal: Наш клиент настаивал на том, чтобы работать с этой версией, мы не можем «поддерживать» его, поскольку для этого потребуется много испытаний, за которые никто не заплатит. – RonK

+0

Вижу. Но кто заплатит за потраченное время, пытаясь улучшить время запуска? :) –

ответ

0

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

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

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

0

я исправила эту проблему, проводя много времени на изучение и декомпиляция некоторые classes.I сталкивались с этим при переходе от weblogic8 10 к этому времени вы, возможно, понял, боль в работе с Oracle WebLogic технической поддержки.

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

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

Шаг 1.You, если вы откроете файлы EJB банку вы можете увидеть

ejb- jar.xml = 3435671213

com.mycompany.myejbs.ejb.DummyEJBService = 2691629828

WebLogic-jar.xml-EJB = 3309609440

WLS_RELEASE_BUILD_VERSION_24 = 10.0.0.0

вы видите эти hascodes для каждого из вашего EJB names.Make этих hadcodes ноля. упаковать файл jar и развернуть его на сервере.

com.mycompany.myejbs.ejb.DummyEJBService = 0

WebLogic-jar.xml-EJB = 0

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

Примечание 1: , как получить это файл? Если вы откроете домены/yourdomain/servers/yourServerName/cache/EJBCompilerCache/XXXXXXXXX , вы увидите этот файл для каждого ejb.WebLogic делает hashcodes к нулю после перекомпилирует

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

Step2. Также вам нужен PATCH из weblogic. Когда вы устанавливаете патч, вы видите какое-то сообщение вроде этого «PATH CRXXXXXX установлен успешно. Исправьте рекомбинацию EJB для приложения». Я не помню номер патча, но вы можете запросить weblogic для этого.

Для устранения проблемы необходимо выполнить оба действия. Патч исправляет только часть проблемы Goodluck !!

веселит Raj

+0

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