Archive for Październik, 2010

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: , , ,

Instalacja bazy danych PostgreSQL 8.4 w systemie RHEL 5.4

Prosty problem: jak zainstalować wersję 8.4 bazy danych PostgreSQL w RHEL 5.4. W tej wersji jest dostarczona wersja 8.1 całkiem już stara. Na szczęście z wersja RHEL 5.5. zawiera już nowszą wersję tej bazy danych (pakiet postgresql84-server), ale ja tej wersji używać nie mogłem.

  1. Instalacja repozytorium z PostgreSQL w systemie:
    # rpm -Uvh http://yum.pgsqlrpms.org/reporpms/8.4/pgdg-redhat-8.4-2.noarch.rpm
  2. Instalacja bazy danych w systemie:
    # yum install postgresql postgresql-server postgresql-contrib
  3. Inicjalizacja bazy danych:
    # service postgresql initdb
  4. Start bazy danych:
    # service postgresql start
  5. Automatyczny start podczas włączania systemu:
    # chkconfig postgresql on

Źródła

Tags: , ,

Różnice w konfiguracji pomiędzy profilami all i production w JBoss EAP 5

Serwer aplikacji JBoss EAP 5 zawiera szereg profili, które pozwalają uruchomić rożne jego konfiguracje. Między innymi można znaleźć tam profile all oraz production.

Profil all wspiera klastrowanie i jest przeznaczony do używania podczas tworzenia czy też testowania aplikacji, natomiast profil production jest zoptymalizowany pod typowy serwer produkcyjny. Poniżej znajdzie się opis różnic w konfiguracji obydwóch profili.

Modyfikacje w logowaniu informacji

W wersji production występuje sporo różnic w sposobie logowania informacji przez serwer JBoss:

  • wyłączenie logowania informacji na konsolę
  • włączenie konfiguracji pozwalającej na logowanie asynchronicznie
  • przekierowanie komunikatów z pakietów org.jgroups oraz org.jboss.ha do pliku cluster.log
  • zwiększenie priorytetu logowanych informacji z INFO do WARN

Hot deploy

Zwiększenie czasu skanowania katalogu deploy z 5 na 60 sekund.

Modyfikacje w pliku hdscanner-jboss-beans.xml

all
14
<property name="scanPeriod">5000</property>
production
14
<property name="scanPeriod">60000</property>

Wyłączenie śledzenia połączeń do bazy danych

W profilu production zostaje wyłączone śledzenie otwartych połączeń do bazy danych i ich automatyczne zamykanie:

Modyfikacje w pliku jca-jboss-beans.xml

all
47
48
<!-- Whether to track unclosed connections and close them -->
<property name="debug">true</property>
production
47
48
<!-- Whether to track unclosed connections and close them -->
<property name="debug">false</property>

Generowanie unikalnych identyfikatorów

W usłudze uuid-key-generator.sar zostało zwiększone bezpieczeństwo uzyskiwanych danych w przypadku używania klastrów:

Modyfikacje w pliku uuid-key-generator.sar/META-INF/jboss-service.xml

all
42
43
44
45
46
<!-- Uncomment to make it cluster-safe: Select current Hi value query (FOR UPDATE is recommended)
<attribute name="SelectHiSql">
   select HIGHVALUES from HILOSEQUENCES where SEQUENCENAME='general' FOR UPDATE

-->
production
42
43
44
45
<!-- Uncomment to make it cluster-safe: Select current Hi value query (FOR UPDATE is recommended) -->
<attribute name="SelectHiSql">
    select HIGHVALUES from HILOSEQUENCES where SEQUENCENAME='general' FOR UPDATE
</attribute>

Wyłączenie możliwości ładowania klas nie będących ziarnami EJB

Klient RMI ma możliwość ładowania klas bezpośrednio z serwera aplikacji. Dzięki temu nie trzeba razem z klientem dostarczać klas znajdujących się po stronie serwera. Jednakże włączenie tej opcji udostępnia wszystkie wszystkie zasoby znajdujące się na w ramach zmiennej classpath każdemu klientowi, bez możliwości kontroli co on pobiera.

W przypadku profilu production zostaje włączona możliwość ładowania jedynie klas EJB.

Modyfikacje w pliku jboss-service.xml

all
160
161
<!-- Should non-EJB .class files be downloadable -->
<attribute name="DownloadServerClasses">true</attribute>
production
160
161
<!-- Should non-EJB .class files be downloadable -->
<attribute name="DownloadServerClasses">false</attribute>

Tags: , , ,

Vim – nawigacja po długich liniach

Jeżeli pracujemy w Vimie z plikiem tekstowym zawierającym długie linie tekstu, możemy spotkać następująca niedogodność: jeżeli przemieszczamy kursor (w dowolnym trybie pracy) pomiędzy liniami, to zawsze przeskakuje tak naprawdę nie tyle pomiędzy liniami tak jak je widzimy na ekranie, ale między poszczególnymi akapitami (czy naciśnięcie strzałki w dół przeniesie nas do linii występującej po znaku nowej linii).

Takie zachowanie jest przynajmniej dla mnie jest lekko irytujące. Na szczęście istnieje możliwość przeniesienia się do następnej linii, wystarczy w normalnym trybie zamiast klawisza j (przeniesienie kursora w dół) wybrać kombinację gj. Jak dla mnie jest to jednak rozwiązanie dosyć niewygodne. Problem można jednak łatwo rozwiązać, zmieniając odpowiednio mapowania standardowych klawiszy nawigacyjnych i umieścić w pliku konfiguracyjnym (np. ~/.vimrc) następujące definicje:

23
24
25
26
27
28
29
30
31
32
33
" Nawigacja pomiędzy długimi liniami
nnoremap j gj
nnoremap k gk
nnoremap  gj
nnoremap  gk
vnoremap j gj
vnoremap k gk
vnoremap  gj
vnoremap  gk
inoremap  gj
inoremap  gk

Rozwiązuje to problem poruszania się po łamanych liniach.

Źródła

Tags: , ,