Posts Tagged JBoss

JMeter – budowa planu testu aplikacji stworzonej przy użyciu JBoss Seam, część 2

Druga część wpisu poświęconemu tworzeniu przy użyciu JMeter planu testów aplikacji napisanej za pomocą szkieletu JBoss Seam.

Przygotowanie testu do obsługi aplikacji napisane w JBoss Seam

Można teraz spróbować uruchomić test. Jeżeli testujemy aplikację napisaną w JBoss Seam, prawdopodobnie żadna strona nie zostanie wczytana (można to potwierdzić np. patrząc na zawartość pliku localhost_access_log) a serwer aplikacji wyrzuci stos wyjątków mówiącymi, że nie można odzyskać widoku. Spowodowane jest to tym, że Seam zapisuje na stronach oraz często w URL lub w wysyłanych formularzach dodatkowe wartość, które określają nazwę danego widoku raz numer konwersacji. Można sobie z tym poradzić, ale wymaga to dodatkowej pracy nad testem.

Trzeba będzie sobie poradzić z dwoma elementami: widokiem oraz konwersacją.

  • ViewState

    W przypadku widoku należy po kolej przejrzeć w aplikacji JMeter każde zapytanie, które zostanie wysłane do serwera aplikacji. Należy odszukać te strony, które zawierają w parametrach odwołanie do ciągu znakowego: javax.faces.ViewState. Powinna być tam określona wartość tego parametru, w moim przypadku było to j_id1:j_id2. W moim przypadku wywołanie to znajdowało się na drugiej stronie, w której następowało logowanie do aplikacji.

    JMeter - ViewState

    JMeter - ViewState

    Po identyfikacji właściwej strony należy należy teraz odszukać wywołanie poprzednie. Wartość dla parametru javax.faces.ViewState jest ustawiana w poprzednim wywołaniu, więc tam należy tę wartość przechwycić. Można to zrobić dodając do strony poprzedzającej to wywołanie komponent o nazwie Regular Expression Extractor, znajdujący się w menu Post Processors i go odpwiednio skonfigurować:

    • Name: ViewState Extractor – nazwa komponentu
    • Reference Name: VIEWSTATE – nazwa zmiennej, która będzie użyta do podstawienia wartości
    • Regular Expression: id="javax.faces.ViewState" value="([^"]*)" – wyrażenie regularne, które będzie użyte do pobranie właściwej wartości
    • Template: $1$
    • Match No.: 1
    JMeter - ViewState Extractor

    JMeter - ViewState Extractor

    Teraz jeszcze należy odpowiednio ustawić wartość dla parametru javax.faces.ViewState. Czyli trzeba otworzyć stronę na której występowało odwołanie do parametru i zmienić jego wartość na odwoła nie do zmiennej ${VIEWSTATE}.

    JMeter - konfiguracja zmiennej VIEWSTATE

    JMeter - konfiguracja zmiennej VIEWSTATE

    Jeżeli odwołanie do parametru javax.faces.ViewState występuje także na innych stronach, to także trzeba będzie takie zmiany wprowadzić. W moim przypadku wywołanie występowało na 5 stronach.

  • Konwersacje

    Konwersacje są jedną z włąściwości szkieletu JBoss Seam wyróżniającego go spośród innych rozwiązań (więcej na ten temat można znaleźć w manualu: Conversations and workspace management). W aplikacji Seamowej można zauważyć, że duża część linków zawiera dodatkowy parametr o nazwie conversationId czy też cid. Określa on numer określonej konwersacji, i wymaga także odpowiedniego potraktowania przez narzędzie testujące.

    Sposób radzenia sobie z konwersacjami jest podobny jak przy problemie z ViewState: należy odszukać wszystkie wystąpienia danej konwersacji i odpowiednio zmienić je na wywołania zmiennej.

    • najpierw należy zidentyfikować nazwę parametru używanego przez aplikację, może to być np. conversationId lub cid
    • odszukać wystąpienia tego parametru, powinien być przekazywany przy użyciu linku, czyli metodą GET, w moim przypadku jest to czwarta strona, wyświetlająca produkt:

      JMeter - wywołanie conversationId

      JMeter - wywołanie conversationId

    • należy do poprzedniej strony (analogicznie jak w przypadku ViewState) dodać komponent Regular Expression Extractor i go odpowiednio skonfigurować:
      • Name: ConversationID Extractor – nazwa komponentu
      • Reference Name: CID – nazwa zmiennej, która będzie użyta do podstawienia wartości
      • Regular Expression: conversationId=(\d+) – wyrażenie regularne, które będzie użyte do pobranie właściwej wartości
      • Template: $1$
      • Match No.: 1
      JMeter - ConversationID Extractor

      JMeter - ConversationID Extractor

    • odszukać wystąpienia danej konwersacji na następnych stronach i za wartość podstawić zmienną ${CID}:

      JMeter - konfiguracja zmiennej CID

      JMeter - konfiguracja zmiennej CID

    • powyższe kroki trzeba powtórzyć dla każdego numeru konwersacji (czyli jak zmienia się jej numer, to należy użyć wyrażenia regularnego do jego uzyskania, i następnie podstawiać tę wartość na następnych wywołaniach strony), w moim przykładzie należało użyć wyrażenia regularnego 3 razy i podmienić na zmienną 8 wartości

Po powyższych zmianach można uruchomić test i powinien już zadziałać bez problemów.

Uruchomienie testu

Ostatnim elementem testu będzie uruchomienie go w kilku wątkach oraz konfiguracja JMetera tak, aby używał do logowania kont różnych użytkowników.

Za zarządzanie użytkownikami odpowiada kontroler User Parameters. Pozwala on na zdefiniowanie użytkowników, jacy mogą zostać użyci w trakcie testu.

W ramach tego komponentu należy zdefiniować nazwę zmiennej która będzie używana do podstawienia za login oraz hasło użytkownika. W kolejnych kolumnach należy zdefiniować wartości dla tych zmiennych.

W przypadku aplikacji DVD Store występuje pięciu użytkowników o nazwach od user1 do user5, wszyscy z hasłem pasword. Definicja dla nich może wyglądać następująco:

JMeter - definicja użytkowników

JMeter - definicja użytkowników

Należy jeszcze zmodyfikować odpowiednio proces logowania do aplikacji, i zamiast wysyłania wartości w formularzu, wstawić odpowiednie zmienne JMeter:

JMeter - modyfikacja formularza logowania

JMeter - modyfikacja formularza logowania

Ostatnim elementem będzie uruchomienie większej ilości wątków i przetestowanie aplikacji. Można to zrobić w ramach komponentu Thread Group. W nim ustala się następujące parametry:

  • Number of Threads – ilość jednocześnie uruchamianych wątków, jeden wątek odpowiada jednemu użytkownikowi, jeżeli wątków będzie więcej niż zdefiniowanych użytkowników, to od nowa brany jest do logowania pierwszy użytkownik i potem następni
  • Ramp-Up Period – po jakim czasie wszystkie wątki mają działać, czyli ustawienie tu wartości na 5 sekund przy 5 wątkach spowoduje, że każdy wątek będzie uruchamiany co sekundę
  • Loop Count – ilość powtórzeń testów

Przykładowa konfiguracja może wyglądać tak:

JMeter - definicja sposobu uruchamiania testu

JMeter - definicja sposobu uruchamiania testu

Pozostaje teraz zdefiniować obciążenie serwera, uruchomić test i oglądać jak wygląda obiciążenie i kiedy serwer przestanie odpowiadać na zapytania.

JMeter - wyniki testu

JMeter - wyniki testu

Na koniec przygotowany plan testów dla aplikacji: Plan testu DVD Store.

Źródła

Tags: , ,

JMeter – budowa planu testu aplikacji stworzonej przy użyciu JBoss Seam, część 1

Ostatnimi czasy musiałem przygotować test wydajności dla aplikacji stworzonej przy użyciu szkieletu JBoss Seam. I okazało się, że nie do końca jest to takie trywialne. Poniżej opis, jak przygotować plan testu dla takiej aplikacji (oczywiście, spokojnie można go także użyć do budowy testu dla dowolnej aplikacji webowej).

Wpis składa się z dwóch części:

Oprogramowanie

W trakcie konstruowania testu używałem następujących aplikacji:

  • JMeter 2.3.4
  • JBoss EAP 5.1
  • JBoss DVD Store – aplikacja przykładowa dostarczana z biblioteką JBoss Seam 2.2.1

Przed przystąpieniem do budowy testu należy aplikację DVD Store zainstalować w serwerze aplikacyjnym.

Jeżeli będziemy się łączyli bezpośrednio z serwerem aplikacyjnym (np. używają linku http://localhost:8080/seam-dvdstore, to warto jeszcze dodać do niego możliwość logowania przychodzących połączeń HTTP. Może to się przydać, aby sprawdzić czy wszystko, czy nie występują jakieś błędy. Można to zrobić modyfikując plik $JBOSS_HOME//server/default/deploy/jbossweb.sar/server.xml. Należy w nim odkomentować nastepujący linie (więcej informacji na ten temat można znaleźć we wpisie Logowanie przychodzących połączeń HTTP w serwerze JBoss AS i Apache Tomcat):

80
81
82
83
<valve className="org.apache.catalina.valves.AccessLogValve"
   prefix="localhost_access_log." suffix=".log"
   pattern="common" directory="${jboss.server.log.dir}"
   resolveHosts="false" />

Plik z logiem będzie znajdował się w katalogu z logami: $JBOSS_HOME//server/default/log/localhost_access_log.DATA.log.

Zebranie danych do testowania

Pierwszym krokiem będzie zebranie stron, na których będzie wywoływany test. Można to zrobić na dwa sposoby:

  • zdefiniować wywołanie każdej strony ręcznie
  • użyć modułu proxy, który umożliwi nagranie sesji przy użyciu przeglądarki

Ponieważ drugi sposób będzie szybszy, to za jego pomocą nagramy sesję przeglądarki. JMeter udostępnia odpowiedni komponent, który działa jak serwer proxy i pozwala przechwycić żądania z przeglądarki. Konfiguracja jest prosta:

  • w JMeter należy dodać następujące komponenty:
    • do Test Plan komponent Thread Groupp – pozwala on na konfigurację przebiegu testu: ilość użytkowników, uruchomionych wątków, co ma się dziać w momencie wystąpienia błędu
    • do Thread Group dodać kontroler Recording Controller – zostaną w nim zapisane wszystkie przechwycone żądanie z komponentu proxy
    • do WorkBench dodać komponent HTTP Proxy Server – to jest nasz serwer proxy, pozwala on na konfiguracja kilku zachowań, teraz najważniejsz będzie port na którym zostanie on uruchomiony. W domyślnej konfiguracji jest to port 8080, które jest zajęty przez proces JBossa, należy więc zmienić go na jakiś inny, np. 9000.

      Wybór portu dla HTTP Proxy Server

      Wybór portu dla HTTP Proxy Server

  • skonfigurować odpowiednio przeglądarkę internetową, tak aby korzystała z serwera proxy. W przypadku Firefoksa powinno wyglądać to mniej więcej tak:
    Konfiguracja serwera proxy w Firefoksie

    Konfiguracja serwera proxy w Firefoksie

    Należy zwrócić uwagę na pole No Proxy for, domyślnie znajduje się tam wartość localhost, co może uniemożliwić nagranie sesji, jeżeli serwer JBoss jest uruchamiany na maszynie lokalnej.

Teraz czas na pobranie kilku stron, które będą używane następnie w trakcie testu. Należy jeszcze włączyć serwer proxy: w komponencie HTTP Proxy Server należy wybrać przycisk Start. W przypadku aplikacji DVD Store można wykonać takie kroki:

  • połączyć się ze stroną http://localhost:8080/seam-dvdstore/home
  • można zalogować się na konto wybranego użytkownika, w tym przypadku będzie to użytkownik user1
  • następnie obejrzeć jedną, dwie płyty
  • dodać płytę do koszyka i złożyć zamówienia
  • wylogować się

Te kroki powinny spowodować, że w aplikacji JMeter pojawi się pod komponentem Record Controler szereg zapytań o strony. Można zauważyć, że znajdują się tam wszystkie wywołania HTTP które wygenerowała przeglądarka, czyli łącznie z pobraniem obrazków, arkuszy stylów czy skryptów JavaScript. W moim przypadku skasowałem te wpisy. W przypadku gdy chcemy pobierać dodatkowe elementy strony, można w ramach zapytania o stronę w JMeter zaznaczyć opcję Retrive All Embedded Resources from HTML files.

W moim przypadku nagrana sesja wygląda następująco:

Nagrana sesja zapytań HTTP

Nagrana sesja zapytań HTTP

Uporządkowanie testu

Nagrane zapytania do serwera można teraz uporządkować wg funkcji które wykonują oraz trzeba jeszcze dodać kilka dodatkowych komponentów do projektu.

  • HTTP Cookie Manager – pozwala on na zarządzanie ciasteczkami, które są ustawiane przez badaną stronę
  • Graph Results – tworzy wykres w trakcie uruchamianie testu, można także dodać jakieś inne elementy, które będą zbierały dane z testu
  • Simple Controller – dodanie kilku (w tym przypadku 4) kontrolerów, które pozwolą na pogrupowanie zapytań do serwera
  • usunąć komponent Record Component

Grupowanie nie ma wpływu na sam test, ale na pewno zwiększy przejrzystość poszczególnych elementów testu.

Po uporządkowaniu zapytań, wygląda to następująco:

JMeter - grupowanie zapytań

JMeter - grupowanie zapytań

Źródła

Tags: , ,

Kompilacja serwera aplikacji JBoss AS 5.1 ze źródeł (aktualnych)

Wersja społecznościowa (community) serwera aplikacji JBoss jest wydawana co jakiś czas w wersji stabilnej i na tym kończy się wsparcie ze strony Red Hata. Można to łatwo zauważyć na przykładzie wersji 5.1 serwera. Została ona wydana 23.05.2009 (czyli ponad półtora roku temu) i następną wersja stabilna, która się pojawiła do wersja 6.0 wydana pod koniec grudnia. W międzyczasie nie została opublikowana żadna wersja pośrednia.

Oczywiście, nie oznacza to że serwer nie posiada żadnych błędów. Jest to raczej związane z polityką firmy Red Hat, która poprawki do poszczególnych wersji wydaje tylko w ramach subskrypcji. Pozostają więc takie możliwości:

  1. Wykupić wsparcie w Red Hacie i mieć dostęp do wszelkich aktualizacji (generalnie najlepsza opcja).
  2. Pobrać aktualne źródła serwera aplikacji JBoss i samodzielnie je skompilować.

Przy pierwszym wariancie dużo do roboty nie ma, i w razie problemów zawsze można zawracać głowę firmie Red Hat. Zapewni to dostęp do przetestowanej aplikacji i da gwarancje, że wszystkie elementy działają poprawnie.

Jeżeli nie zdecydujemy się wykupienie wsparcia, pozostaje samodzielna kompilacja aplikacji. Pojawia się tutaj pytanie: po co w ogóle kompilować serwer aplikacji? Czy nie wystarczy po prostu używać opublikowanej aplikacji?

Poniższe polecenia będzie można wykonać samodzielnie po pobraniu źródeł serwera aplikacji.

Lista wszystkich zmian w repozytorium od momentu wydania wersji stabilnej JBossa 5.1:

svn log -r {2009-05-24}:BASE

Możemy sprawdzić, ile było poszczególnych zmian w kodzie źródłowym:

svn log -r {2009-05-24}:BASE | grep  ^r[[:digit:]] | wc -l

W moim przypadku wyszło 866 zmian w kodzie źródłowym.

Można także sprawdzić, ile usunięto zgłoszeń w systemie śledzenia błędów:

svn log -r {2009-05-24}:BASE | grep JBPAPP- | wc -l

W moim przypadku wyszło 502 zgłoszenia.

Jak widać, prace nad wersją JBossa 5.1 cały czas trwają.

Konfiguracja systemu

W moim przypadku cały proces kompilacji odbywa się na maszynie z systemem Ubuntu 10.10. Na szczęście system nie ma podczas tego procesu dużego znaczenia (poza detalami związanymi z instalacją pakietów).

Wymagania początkowe:

  • dostępność JDKw wersji co najmniej 1.5 (ja testowałem na JDK 1.6.22)
  • instalacja klienta Subversion
    sudo aptitude install subversion
  • instalacja aplikacji patch:
    sudo aptitude install patch

Kolejnym krokiem jest utworzenie odpowiedniego katalogu przeznaczonego na źródła serwera JBoss a następnie pobranie źródeł przy użyciu klienta Subversion:

mkdir JBoss-5.1
svn co http://anonsvn.jboss.org/repos/jbossas/branches/JBPAPP_5_1/ JBoss-5.1

Teraz pozostaje odczekać, aż źródła zostaną pobrane.

Jeżeli w przyszłości będziemy chcieli zaktualizować źródła, wystarczy wejść do katalogu z nimi (w moim przypadku do katalogu JBoss-5.1) i wydać polecenie:

svn update

Kompilacja źródeł

Pozostaje teraz skompilować serwer aplikacji. Jest to czynność stosunkowo łatwa, sprowadza się do uruchomienia jednego skryptu:

cd build
./build.sh

Podczas pierwszego uruchomienia zostaną pobrane wszystkie niezbędne do kompilacji i działania serwera biblioteki (przy użyciu aplikacji Maven). Proces ten może trwać dość długo. Po zakończeniu pobierania bibliotek źródła zostaną skompilowane i pliki binarne można będzie znaleźć w katalogu build/output.

W moim przypadku znalazł się tam katalogu jboss-5.1.1.Branch, co jak widać jest wersją nowszą niż ostatnia wersja społecznościowa serwera aplikacji JBoss 5.1.

Kompilacja ta jest także bardzo podobna do wersji komercyjnej serwera:

  • znajdziemy w niej profil production
  • w profilach jest także wyłączony dostęp do konsol zarządczych, użytkownik admin jest wyłączony w plikach konfiguracyjnych

Jeżeli z jakiś powodów wolimy wersję podobną do wersji społecznościowej, należy uruchomić na binarnym serwerze odpowiednie pliki przy użyciu polecenia patch. Dokładne instrukcje można znaleźć w pliku build/REDME.

Na zakończenie mały skrypt, który wywoła kompilację serwera JBoss, ale zapisze ją w katalogu zawierającym numer wersji repozytorium. Pozwoli to w łatwy sposób oznaczyć wersje źródeł, co może przydać się podczas testowania, czy aktualna wersja działa poprawnie i może zostać użyta na serwerach produkcyjnych.

Skrypt nazwa się build_jboss.sh i należy wywołać go z nazwą katalogu w którym znajdują źródła serwera JBoss:

./build_jboss.sh JBoss-5.1

Skrypt:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
#!/bin/bash

if [ ! -n "$1" -o ! -d "$1" ]; then
        cat <<EOF
Prosze podac katalog ze zrodlami serwera JBoss:

$0 jboss-svn
EOF

        exit 1
fi

JBOSS_DIR="$1"
BUILD_DIR="build"

echo -n "Numer wersji repozytorium: "

cd $JBOSS_DIR
REVISION=$(svn info | grep Revision | cut -c 11-)
echo $REVISION

cd $BUILD_DIR

echo "Kompilacja"
./build.sh -Dversion.tag=$REVISION

echo Kompilacja zakonczona, sprawdz katalog $JBOSS_DIR/build/output
echo

exit 0

Źródła

Tags: ,

Znaczenie poszczególnych katalogów w JBoss AS

Serwer aplikacji JBoss AS (jak każda większa aplikacja) jest podzielony na wiele różnych katalogów, mających różne znaczenie.

Struktura katalogu głównego

Katalogi serwera w JBoss 5

Katalogi serwera w JBoss 5

Katalogi serwera w JBoss 6

Katalogi serwera w JBoss 6

  • bin – skrypty niezbędne do uruchomienia oraz zatrzymania serwera, różne inne narzędzie pozwalające na zarządzanie serwerem
  • client – niezbędne biblioteki do uruchomienia aplikacji klienckich
  • common/deploy – aplikacja, które są uruchamiane we wszystkich profilach
  • common/lib – pliki jar, które są używane przez wszystkie profile
  • docs – schematy XSD oraz DTD używane przez różne pliki konfiguracyjne, pliki z licencjami oraz przykładowe konfiguracja dla JTA, JMS oraz źródeł danych
  • lib – biblioteki niezbędne do uruchomienia jądra serwera aplikacji
  • server – w tym katalogu umieszczone są wszystkie konfiguracje serwera

Struktura katalogu z profilami (server)

Rodzaje profili w JBoss 5

Rodzaje profili w JBoss 5

Rodzaje profili w JBoss 6

Rodzaje profili w JBoss 6

  • default – podstawowa konfiguracja pozwalająca na uruchamianie aplikacji, najczęściej używana do uruchamiania aplikacji JEE, nie zawiera usług JAXR, IIOP oraz elementów związanych z klastrowaniem
  • all – konfiguracja z pełnym wsparciem JEE, łącznie z klastrowaniem oraz usługami RMI/IIOP
  • minimal – podstawowa konfiguracja, która umożliwia uruchomienie serwera WWW, bez żadnych dodatkowych komponentów
  • standard – konfiguracja przygotowana do zapewnianie jak najlepszej zgodności z komponentami JEE
  • jbossweb-standalone
  • web – konfiguracja przygotowana do instalacji aplikacji webowych, zawiera włąc-
    zony usługę JBoss Web oraz wsparcie dla JPA oraz JTA/JCA
  • production – konfiguracja przygotowana do uruchomienia na serwerach produkcyjnych (o różnicach mięszy profilami all a production można poczytać w tym wpisie: Różnice w konfiguracji pomiędzy profilami all i production w JBoss EAP 5)

Struktura katalogów w danym profilu

Struktura katalogu w ramach profilu

Struktura katalogu w ramach profilu

  • conf – katalog zawiera pliki konfiguracyjne związane z danym profilem
  • deploy – podstawowy katalog, w którym znajdują się aplikacje instalowane w ramach serwera
  • deployers – usługi, które są odpowiedzialne za poprawne rozpoznanie oraz zainstalowanie właściwej aplikacji
  • deploy-hasingelton – w katalogu tym nalezy umieścić aplikacje, które powinny być uruchomione tylko jeden raz w jednym momencie w ramach klastra
  • farm – aplikacje umieszczone w tym katalogu zostaną automatycznie zainstalowane w ramach całego klastra
  • lib – biblioteki danego profilu, wspólne dla wszystkich działających aplikacji
  • log – logi serwera
  • data – katalog przeznaczony do zapisywania informacji przez aplikacje, znajdują się w nim m.in. domyślna baza danych serwera
  • tmp – katalog tymczasowy, do którego są rozpakowywane poszczególne aplikacje podczas ich instalacji w ramach serwera
  • work – katalog tymczasowy używany przez usługę JBoss Web

Tags: ,

Rozdzielenie logów z aplikacji do plików w serwerze JBoss 5

Standardowy sposób logowanie w ramach serwera JBoss 5 sprowadza się do zapisywania informacji o zdarzeniach do pliku server.log. Trafiają tam wszystkie zdarzenia, jakie mają zostać zalogowane.

Niekiedy jednak istnieje potrzeba separacji logowania danych z rożnych aplikacji do oddzielnych plików. W przypadku serwera JBoss do logowania używana jest biblioteka log4j a jej konfiguracja znajduje się w pliku jboss-log4j.xml. Bibliotekę tę można skonfigurować do logowania danych z danej aplikacji w jeden z dwóch sposobów:

  • logować informacje pochodzące z odpowiednich pakietów (rozwiązanie uniwersalne, wymaga tylko odpowiedniej konfiguracji biblioteki log4j)
  • logować informacje pochodzące z danej aplikacji – rozwiązanie korzystające z bibliotek JBossa, będzie działać tylko w ramach serwera aplikacji

Przedstawię obie metody na przykładzie logowania informacji pochodzących z aplikacji Admin Console.

Podział logowania ze względu na pakiety

Konfiguracja logowanie informacji o wybranych pakietach sprowadza się do kilku kroków:

  • konfiguracja pliku, do którego będą zapisywane logi oraz konfiguracja odpowiedniego formatu ich zapisu:
    361
    362
    363
    364
    365
    366
    <appender name="AdminConsoleLog" class="org.apache.log4j.FileAppender">
      <param name="File" value="${jboss.server.home.dir}/log/admin_console.log"/>
      <layout class="org.apache.log4j.PatternLayout">
        <param name="ConversionPattern" value="%d %-5r %-5p [%c] (%t:%x) %m%n"/>
      </layout>
    </appender>
  • identyfikacja pakietów, z których informacje powinny być logowane – czyli najlepiej przejrzeć plik JAR z aplikacją i wypisać odpowiednie pakiety, w przypadku aplikacji Admin Console będzie to pakiet org.jboss.on.embedded
  • konfigurację logowania wybranych pakietów do odpowiednio wcześniej zdefiniowanego pliku:
    368
    369
    370
    371
    372
    373
    374
    375
    376
    <category name="org.jboss.on.embedded">
      <priority value="DEBUG" />
      <appender-ref ref="AdminConsoleLog">
    </category>

    <category name="org.rhq.core">
      <priority value="DEBUG" />
      <appender-ref ref="AdminConsoleLog">
    </category>

Co zrobić jednak z takimi sytuacjami:

  • aplikacja składa się z różnych bibliotek i chcemy także uzyskać z nich uzyskać logi – najprościej, dodać kolejny wpis w pliku jboss-log4j.xml z odpowiednią kategorią (w przykładzie powyżej logowanie z pakietu org.rhq.core)
  • ta sama biblioteka jest wykorzystywana w wielu aplikacjach, ale logować informacje chcemy tylko z jednej aplikacji – i tutaj jest kłopot, powyższy sposób spowoduje logowanie danych z każdej instancji biblioteki, nawet jeżeli nie jest ona związana z daną aplikacją. Być może dałoby się skonfigurować logowanie w ramach danej aplikacji, ale nie widzę możliwości konfiguracji tego na poziomie serwera JBoss (w ramach takiej konfiguracji logowania)

Podział logowania ze względu na aplikację

W ramach serwera JBoss istnieje jednak możliwość konfiguracji logowania na podstawie samej aplikacji, ale wymaga do kilku dodatkowych kroków:

  1. Aktualizacja bibliotek odpowiedzialnych w JBossie za logowanie to nowsze wersji.

    Do konfiguracji logowania na poziomie aplikacji w przypadku JBossa 5.1 będzie trzeba użyć klasy filtrującej logi o nazwie org.jboss.logging.filter.TCLMCFilter, która jest dostępna w wersji 2.2.1 biblioteki jboss-logging (w ramach serwera dostępna jest wersja 2.2.0). Aktualizacja sprowadza się do:

  2. Konfiguracja logowania na poziomie aplikacji.
    • Najpierw należy zdefiniować w pliku jboss-log4j.xml nową pozycję, w której podamy do z jakiej aplikacji logi nas interesują oraz gdzie mają zostać zapisane:
      378
      379
      380
      381
      382
      383
      384
      385
      386
      387
      388
      389
      390
      391
      <appender name="AdminConsole2Log" class="org.apache.log4j.FileAppender">
        <param name="File" value="${jboss.server.home.dir}/log/admin_console2.log"/>
        <param name="Threshold" value="DEBUG"/>
        <layout class="org.apache.log4j.PatternLayout">
          <param name="ConversionPattern" value="%d %-5r %-5p [%c] (%t:%x) %m%n"/>
        </layout>
        <filter class="org.jboss.logging.filter.TCLMCFilter">
          <param name="AcceptOnMatch" value="true"/>
          <param name="DeployURL" value="admin-console.war"/>
        </filter>    

        <!-- end the filter chain here -->
        <filter class="org.apache.log4j.varia.DenyAllFilter"></filter>
      </appender>

      Definicja odpowiedniego filtru, który ma za zadanie wybranie tylko logów pochodzących z wybranej aplikacji znajduje się w linii 384, sama nazwa aplikacji znajduje się w linii 386.

    • Teraz należy dodać zdefiniowany obiekt appender do kategorii root:
      402
           <appender -ref ref="AdminConsole2Log"/>

Teraz pozostaje jeszcze start (lub restart) serwera JBoss i w plikach powinny znaleźć się odpowiednie logi z poszczególnych aplikacji.

Źródła

Tags: , , ,