Category Archives: Weblogic

Kilka sztuczek z BEA Weblogic

Witam po przerwie. Jak widać zgodnie ze zwyczajem zmieniłem po raz kolejny skórkę bloga – moim zdaniem jest bardzo czytelna, ale i też ładniejsza od poprzedniej. Poczyściłem także blogrolla – ileż to dobrych blogów zniknęło z blogosfery przez te raptem 2 lata. By mój nie podzielił tego losu dziś kolejny wpis dyktowany codzienną praktyką – na tapecie mamy serwer aplikacyjny BEA Weblogic w wersji 9.2.

JVM w wydaniu JRockit i diagnozowanie problemów

Do uruchamienia serwera Weblogic możemy wybrać dowolną implementację JVM, ale możemy też posłużyć się poprawioną wersją JVM o nazwie JRockit, która zmienia szereg pakietów (głównie tych niskopoziomowych),  celem zapewnienia szybkości i efektywności działania serwera. Jakie ma to przełożenie na rzeczywistość nie wiem – nie moją robotą jest benchmarkowanie serwerów (póki co przynajmniej). Uruchomienie serwera następuje poprzez wykonanie skryptów uruchomieniowych znajdujących się w katalogu /bin. Tam też znaleźć można skrypcik o dość znaczącej nazwie – setDomainEnv.sh. Mówiąc krótko zawiera on kod, który ma na celu ustawienie zmiennych i parametrów z jakimi zostanie uruchomiona JVM i sam serwer. Standardowo (o ile pamiętam) serwer startuje z JRockit – jednakże problem, na który się natknąłem wymagał zmiany używanej JVM. Dlaczego?

Rzecz konkretnie dotyczyła braku klas podczas uruchamiania aplikacji. Część JARów leżała w katalogu z bibliotekami wspólnymi dla całego serwera, część w domenie, zaś jeszcze inna część w samej aplikacji (proszę nie pytać co i jak, to skomplikowane jest).  Aplikacja wysypywała się przy próbie uploadu plików poprzez Struts i błąd polegał na tym, że w logach i na ekranie dostawałem piękne Internal Server Error 500 i na tym log i temat się kończył. I mógłbym zastanawiać się lata długie co było nie tak, gdyby nie szybki fix – zmianę  JVM użytej do uruchomienia serwera.

We wspomnianym pliku setDomainEnv.sh należy odszukać odpowiedni fragment:


if [ "${JAVA_VENDOR}" = "BEA" ] ; then
JAVA_HOME="${BEA_JAVA_HOME}"
export  JAVA_HOME
else
if [ "${JAVA_VENDOR}" = "Sun" ] ;  then
JAVA_HOME="${SUN_JAVA_HOME}"
export  JAVA_HOME
else
JAVA_VENDOR="BEA"
export  JAVA_VENDOR
JAVA_HOME="/sciezka/do/katalogu/z/serwerem/jrockit"
export  JAVA_HOME
fi
fi

Wystarczy zakomentować odpowiednie linijki (albo wcześniej ustawić zmienną) i zrestartować serwer. W mojej wersji JVM od Sun-a komunikat o błędzie był o wiele bardziej rozbudowany i ostatecznie doszedłem, że rzecz w konflikcie JARów.

Weblogic i Eclipse

Dobrze jest czasem mieć serwer podpięty pod nasze IDE – w tym przypadku Eclipse. Uruchomić łatwo, na projekcie prawyklik i już temat się restartuje, deploymenty śmigają po magistralach zaś konsola puszy się ślicznymi logami. To wszystko w IDE dość często skraca czas poświęcony na pracę, a tym samym zwiększa naszą efektywność. Tymczasem dziś napotkałem problem z poprawną konfiguracją serwera z Eclipse. Problem polegał na tym, iż utworzona instancja serwera w IDE istniała, dawała się uruchomić, logi nie mówiły nic złego – na pierwszy rzut oka wszystko OK. Jednakże po wykonaniu całej sekwencji startowej Eclipse zgłaszał problem o nazwie “Unable to validate domain” i nie widzał działającego serwera (proces był w porządku, do serwera dało się połączyć i uruchomić aplikację).   Ciutkę dziwne, gdyż serwer i domena odpalane “z palca” nie zgłaszały jakichkolwiek problemów.

Problemem okazała się być niezgodność używanych przez jeden i drugi JVM. Ostatni Eclipse Helios śmigał na wersji 6, zaś Weblogic w wersji 9.2 na wersji 5. I tutaj pojawiały się problemy, o których wspomniałem powyżej. By pozbyć się tego bardzo irytującego problemu wystarczy w pliku eclipse.ini w sekcji z parametrami uruchomienia JVM dla IDE dopisać takie coś:


-Dsun.lang.ClassLoader.allowArraySyntax=true

Restart IDE i jesteśmy w domu. Instancja Weblogica jest w pełni zarządzalna z poziomu IDE. Przydaje się to zwłaszcza w projektach, które dość mocno bazują na wsparciu od IDE – w moim przypadku był to webservice i klient do niego – mając plik WSDL stworzenie wszystkiego sprowadza się do kilku klików w Eclipse. Jednakże powyższy błąd powodował ubicie tworzenia i deploymentu usług na serwerze i tym samym pozostawiał robotę nie zrobioną. Teraz już działa.