Posts Tagged Java

Instalacja Javy 7 w Ubuntu 11.04


W wersji 12.04 Ubuntu można Javę 7 zainstalować dużo prościej, korzystając z repozytoriów PPA. Wystarczy dodać odpowiednie repozytorium i zainstalować Javę:

sudo add-apt-repository ppa:webupd8team/java
sudo apt-get update
sudo apt-get install oracle-java7-installer

Java zostanie pobrana ze strony Oracle, zainstalowana i odpowiednie powiązania zostaną automatycznie ustawione.

Więcej można przeczytać tutaj: Install Oracle Java in Ubuntu via PPA repository.

Java w wersji 7 został wydana jakiś czas temu, ale ciągle nie ma odpowiednich pakietów do instalacji w Ubuntu. Pewnie pojawią się wraz z edycją 11.10, ale czekać tak długo nie mam ochoty :).

Instalacja nowej wersji Javy sprowadza się do wykonania kilku kroków, jedyną niedogodnością jest konieczność ręcznego pilnowania nowych wydań JDK.

  1. Pobranie pakietu z Java, najlepiej ze strony Oracle: Java SE Development Kit 7 Downloads. Mój plik z JDK nazywa się jdk-7-linux-x64.tar.gz.
  2. Rozpakować archiwum:
    tar xzvf jdk-7-linux-x64.tar.gz

    Zostanie utworzony katalog jdk1.7.0 a w nim Java w wersji 7.

  3. Przenieść rozpakowane archiwum do katalogu /usr/lib/jvm/ pod nazwą java-7-oracle, gdzie znajdują się dostępne wersje JVM w systemie.

    Ten i pozostałe kroki muszą być wykonane z uprawnieniami użytkownika root. Należy więc wcześnie zmienić konto lub używać polecenie sudo.

    mv jdk1.7.0 /usr/lib/jvm/java-7-oracle
  4. Ustawić odpowiedniego użytkownika oraz uprawnienia – właścicielem powinien być root a możliwość odczytu i wykonywania aplikacji powinni mieć wszyscy użytkownicy. Nie jest to krok być może konieczny, ale przy niektórych ustawianiach jego brak może uniemożliwić innym użytkownikom korzystania z Javy.
    chown -R root.root /usr/lib/jvm/jdk1.7.0/java-7-oracle

    Jeżeli jednak umask jest ustawiony na bardziej restrykcyjną wartość (w moim przypadku 007) to pojawi się problem: zwykły użytkownik nie będzie mógł ani uruchomić ani nawet odczytać katalogu z Javą. Można to poprawić przy użyciu prostej instrukcji:

    chmod -R a+rX /usr/lib/jvm/java-7-oracle
  5. W Ubuntu domyślne implementacja Javy (jak i wielu innych aplikacji) jest ustawiana przy pomocy polecenia update-alternatives. Mechanizm ten pozwala na zdefiniowania wielu rożnych aplikacji dostarczających daną funkcjonalność (np. wiele wersji Javy) oraz wybranie aplikacji, która będzie uruchamiana domyślnie.

    W przypadku polecenia java można sprawdzić jakie są jego różne implementacje:

    # update-alternatives --config java

    There are 3 choices for the alternative java (providing /usr/bin/java).

      Wybór       Ścieżka                                 Priorytet  Status
    ------------------------------------------------------------
      0            /usr/lib/jvm/java-6-openjdk/jre/bin/java   1061      tryb auto
      1            /usr/lib/jvm/java-6-openjdk/jre/bin/java   1061      tryb ręczny
    * 2            /usr/lib/jvm/java-6-sun/jre/bin/java       63        tryb ręczny

    W moim przypadku mam zainstalowane dwa różne JDK, z czego domyślnie ustawiona jest wersja Suna (teraz już Oracla).

    Można teraz dodać implementację Java 7:

    update-alternatives --install /usr/bin/java java /usr/lib/jvm/java-7-oracle/jre/bin/java 3

    Numer 3 oznacza kolejny numer po ostatniej dostępnej wersji JVM.

    Teraz pozostaje tylko wydanie polecenia:

    update-alternatives --config java

    A teraz mały test: wywołanie poleceń java oraz javac:

    # java -version
    java version "1.7.0"
    Java(TM) SE Runtime Environment (build 1.7.0-b147)
    Java HotSpot(TM) 64-Bit Server VM (build 21.0-b17, mixed mode)

    # javac -version
    javac 1.6.0_26

    Jak widać domyślnie została wywołana wersja Javy 7, natomiast wywołanie kompilator ciągle odwołuje się do wersji 6. Poradzić sobie można z tym definiując kolejną alternatywę a następnie ją ustawiając. Natomiast ilość plików binarnych które trzeba ustawić oraz stron MAN, które należy zmienić jest znaczna. Można to sprawdzić przy pomocy polecenia:

    update-java-alternatives -v -l java-6-sun
  6. Najlepszym sposobem zmiany wersji JDK w przypadku Ubuntu będzie użycie polecenia update-java-alternatives. Pozwoli ona na zmianę domyślnej implementacji wszystkich plików wykonywalnych oraz powiązanych z nimi stron MAN. Niestety, trzeba je odpowiednio skonfigurować, zanim zacznie działać poprawnie.

    Pierwszym krokiem będzie dodanie odpowiednich alternatyw dla wszystkich plików binarnych. Można to zrobić przy pomocy prostego skryptu o nazwie update-alternatives-java-7. Powstał on na bazie odpowiednich skryptów po instalacyjnych wykonywanych podczas instalacji OpenJDK w systemie.

    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
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    #!/bin/bash

    # instalacja JRE-headless

    priority=100
    basedir=/usr/lib/jvm/java-7-oracle
    basediralias=/usr/lib/jvm/java-7-oracle
    jdiralias=java-7-oracle
    mandir=/usr/lib/jvm/jdk1.7.0/man
    srcext=1.gz
    dstext=1.gz

    jre_tools='java keytool pack200 rmid rmiregistry unpack200 orbd servertool tnameserv'
                                                                                                                                                                                                                               
        for i in $jre_tools; do                                                                                                                                                                                                
            unset slave1 slave2 || true                                                                                                                                                                                        
            if [ -e $mandir/man1/$i.$srcext ]; then                                                                                                                                                                            
                slave1="--slave \                                                                                                                                                                                              
                    /usr/share/man/man1/$i.$dstext \                                                                                                                                                                            
                    $i.$dstext \                                                                                                                                                                                                
                    $mandir/man1/$i.$srcext"
                                                                                                                                                                                       
            fi                                                                                                                                                                                                                  
            update-alternatives --verbose \                                                                                                                                                                                    
                --install \                                                                                                                                                                                                    
                /usr/bin/$i \                                                                                                                                                                                                  
                $i \                                                                                                                                                                                                            
                $basediralias/jre/bin/$i \                                                                                                                                                                                      
                $priority \                                                                                                                                                                                                    
                $slave1 $slave2                                                                                                                                                                                                
        done                                                                                                                                                                                                                    
        update-alternatives --verbose \                                                                                                                                                                                        
            --install /usr/bin/jexec jexec $basediralias/jre/lib/jexec $priority                                                                                                                                                
                                                                                                                                                                                                                               
                                                                                                                                                                                                                               
    # instalacja JRE

    jre_tools='policytool ControlPanel java_vm javaws jcontrol'

        for i in $jre_tools; do
            unset slave1 slave2 || true
            if [ -e $mandir/man1/$i.$srcext ]; then
                slave1="--slave \
                   /usr/share/man/man1/$i.$dstext \
                   $i.$dstext \
                   $mandir/man1/$i.$srcext"

            fi
            update-alternatives --verbose \
                --install \
                /usr/bin/$i \
                $i \
                $basediralias/jre/bin/$i \
                $priority \
                $slave1 $slave2
        done

    # instalacja JDK


    jdk_tools='appletviewer apt extcheck idlj jar jarsigner javac javadoc javah javap jconsole jdb jhat jinfo jmap jps jrunscript jsadebugd jstack jstat jstatd native2ascii rmic schemagen serialver wsgen wsimport xjc'


        for i in $jdk_tools; do
            unset slave1 slave2 || true
            if [ -e $mandir/man1/$i.$srcext ]; then
                slave1="--slave \
                   /usr/share/man/man1/$i.$dstext \
                   $i.$dstext \
                   $mandir/man1/$i.$srcext"

            fi
            update-alternatives --verbose \
                --install \
                /usr/bin/$i \
                $i \
                $basediralias/bin/$i \
                $priority \
                $slave1 $slave2
        done

    W skrypcie należy zwrócić szczególną uwagę na definicję odpowiednich ścieżek dostępu. Po jego wykonaniu zostaną zdefiniowanie odpowiednie alternatywy dla odpowiednich plików, ale nie zostaną one jeszcze uaktywnione.

    Konfiguracja update-java-alternatives sprowadza się do zdefiniowania odpowiedniego pliku konfiguracyjnego. Należy utworzyć (lokalizacja i nazwa pliku jest ważna) plik: /usr/lib/jvm/.java-7-oracle.jinfo o następującej zawartości:

    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
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    name=java-7-oracle
    alias=java-7-oracle
    priority=100
    section=non-free

    jre ControlPanel /usr/lib/jvm/java-7-oracle/jre/bin/ControlPanel
    jre java /usr/lib/jvm/java-7-oracle/jre/bin/java
    jre java_vm /usr/lib/jvm/java-7-oracle/jre/bin/java_vm
    jre javaws /usr/lib/jvm/java-7-oracle/jre/bin/javaws
    jre jcontrol /usr/lib/jvm/java-7-oracle/jre/bin/jcontrol
    jre keytool /usr/lib/jvm/java-7-oracle/jre/bin/keytool
    jre pack200 /usr/lib/jvm/java-7-oracle/jre/bin/pack200
    jre policytool /usr/lib/jvm/java-7-oracle/jre/bin/policytool
    jre rmid /usr/lib/jvm/java-7-oracle/jre/bin/rmid
    jre rmiregistry /usr/lib/jvm/java-7-oracle/jre/bin/rmiregistry
    jre unpack200 /usr/lib/jvm/java-7-oracle/jre/bin/unpack200
    jre orbd /usr/lib/jvm/java-7-oracle/jre/bin/orbd
    jre servertool /usr/lib/jvm/java-7-oracle/jre/bin/servertool
    jre tnameserv /usr/lib/jvm/java-7-oracle/jre/bin/tnameserv
    jre jexec /usr/lib/jvm/java-7-oracle/jre/lib/jexec
    jdk appletviewer /usr/lib/jvm/java-7-oracle/bin/appletviewer
    jdk apt /usr/lib/jvm/java-7-oracle/bin/apt
    jdk extcheck /usr/lib/jvm/java-7-oracle/bin/extcheck
    jdk idlj /usr/lib/jvm/java-7-oracle/bin/idlj
    jdk jar /usr/lib/jvm/java-7-oracle/bin/jar
    jdk jarsigner /usr/lib/jvm/java-7-oracle/bin/jarsigner
    jdk javac /usr/lib/jvm/java-7-oracle/bin/javac
    jdk javadoc /usr/lib/jvm/java-7-oracle/bin/javadoc
    jdk javah /usr/lib/jvm/java-7-oracle/bin/javah
    jdk javap /usr/lib/jvm/java-7-oracle/bin/javap
    jdk jconsole /usr/lib/jvm/java-7-oracle/bin/jconsole
    jdk jdb /usr/lib/jvm/java-7-oracle/bin/jdb
    jdk jhat /usr/lib/jvm/java-7-oracle/bin/jhat
    jdk jinfo /usr/lib/jvm/java-7-oracle/bin/jinfo
    jdk jmap /usr/lib/jvm/java-7-oracle/bin/jmap
    jdk jps /usr/lib/jvm/java-7-oracle/bin/jps
    jdk jrunscript /usr/lib/jvm/java-7-oracle/bin/jrunscript
    jdk jsadebugd /usr/lib/jvm/java-7-oracle/bin/jsadebugd
    jdk jstack /usr/lib/jvm/java-7-oracle/bin/jstack
    jdk jstat /usr/lib/jvm/java-7-oracle/bin/jstat
    jdk jstatd /usr/lib/jvm/java-7-oracle/bin/jstatd
    jdk native2ascii /usr/lib/jvm/java-7-oracle/bin/native2ascii
    jdk rmic /usr/lib/jvm/java-7-oracle/bin/rmic
    jdk schemagen /usr/lib/jvm/java-7-oracle/bin/schemagen
    jdk serialver /usr/lib/jvm/java-7-oracle/bin/serialver
    jdk wsgen /usr/lib/jvm/java-7-oracle/bin/wsgen
    jdk wsimport /usr/lib/jvm/java-7-oracle/bin/wsimport
    jdk xjc /usr/lib/jvm/java-7-oracle/bin/xjc

    Teraz jest już dostępna nowa wersja JVM w systmie:

    # update-java-alternatives -l
    java-6-openjdk 1061 /usr/lib/jvm/java-6-openjdk
    java-6-sun 63 /usr/lib/jvm/java-6-sun
    java-7-oracle 100 /usr/lib/jvm/java-7-oracle

    Pozostaje ustawić Jave 7 jako domyślną implementację JVM:

    update-java-alternatives -v -s java-7-oracle

Źródła

Tags: ,

Wyświetlenie parametrów Javy

Maszyna wirtualna Javy pozwala na ustawienie wielu różnych parametrów podczas uruchamiania, które moją wpływ na jej działanie. Pozwalają one m.in. na optymalizację pracy GC czy też związane z wielkością zajmowanej pamięci.

Jednym z parametrów jest AggressiveOpts, który pozwala na włączenie różnych parametrów optymalizacyjnych, które mogą zostać włączone w kolejnym wydaniu JVM. Warto jednak pamiętać, że wraz z każdym wydanie JVM lista tych opcji może się zmienć a ciężko znaleźć informację, jakie parametry są aktualnie używane.

Z pomocą tutaj przychodzą dwie opcje JVM:

  • PrintFlagsFinal – pozwala ona na wyświetlenie wartości wszystkich dopuszczalnych opcji
  • UnlockDiagnosticVMOptions – daje dostęp do dodatkowych opcji konfiguracyjnych

I tak listę wszystkich parametrów wraz z ich wartościami można obejrzeć przy pomocy polecenia:

java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -version

A lista dla włączonej optymalizacji AggressiveOpts:

java -XX:+AggressiveOpts -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -version

Lista jest dosyć spora, więc prościej będzie zobaczyć po prostu różnice pomiędzy uruchomieniem JVM z i bez parametru AggressiveOpts:

diff <(java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -version ) \
   <(java -XX:+AggressiveOpts -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -version )

W wersji JVM 1.6.26 wyświetli listę 6 różnych opcji, których ustawienie się różni. Łatwo także sprawdzić, czym się różni uruchomienie JVM z parametrem server oraz bez.

Dla ułatwienia analizy różnic, zamiast polecenia diff można użyć np. vimdiff:

vimdiff <(java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -version ) \
   <(java -XX:+AggressiveOpts -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -version )

Źródła

Tags: ,

Jak skompilować ze źródeł aplikacje RHQ Server oraz Jopr

Poniżej znajduje się krótki przewodnik w którym przestawię w jaki sposób skompilować oraz zainstalować ze źródeł zarówno serwer RHQ jak i pluginy dostarczane z aplikację JOPR. Kroki są te niezbędne, aby udało się uruchomić monitorowanie JBossa EAP 5 (lub też wersji społecznościowe 5.1) przy użyciu Jopra. Standardowa instalacja (w wersji 2.3.1) niestety nie zawiera odpowiedniego pluginu.

Krok 1: warunki wstępne

Przed rozpoczęciem kompilacji tych aplikacji, trzeba wcześniej zainstalować w systemie następujące aplikacje:

  • Java – zainstalować JDK 6, należy także poprawnie skonfigurować zmienną systemową $JAVA_HOME, która powinna wskazywać na katalog domowy z Javą
  • Maven – zainstalowany w wersji przynajmniej 2.1.x, można pobrać go ze strony http://maven.apache.org/download.html
  • Subversion – należy zainstalować klienta tego systemu wersji
  • PostgreSQL – zainstalować bazę danych, w wersji przynajmniej 8.3 (ja używałem wersji 8.4)

Krok 2: pobranie źródeł

Zanim przystąpimy do konfiguracji kolejnych aplikacji, można rozpocząć pobieranie źródeł aplikacji. Proces ten zajmuje trochę czasu, więc może się wykonywać w czasie gdy przystosujemy kolejne elementy instalacji.

Źródła należy pobrać z repozytorium SVN udostępnianego zarówno przez RHQ jak i Jopra. Najprościej to zrobić używając komendy svn, ale można też użyć innych aplikacji współpracujących z tym systemem kontroli wersji.

Pobranie kodu źródłowego RHQ Server:

svn co http://svn.rhq-project.org/repos/rhq/trunk/ rhq

Pobranie kodu źródłowego Jopr:

svn co https://anonsvn.jboss.org/repos/jopr/trunk/ jopr

W moim przypadku została dla RHQ Serwer została pobrana wersji repozytorium o numerze 5305 a dla Jopr o numerze 1360, także pozostałe informacje dotyczą tych wersji kodu. W nowszych niektóre rzeczy na pewno mogą się zmienić.

Krok 3: konfiguracja bazy danych

RHQ Server do swojego działania potrzebuje bazy danych. Może on działać produkcyjnie na bazie danych PostreSQL lub Oracle, testowo na HSQL (istnieje także eksperymentalne wsparcie dla MSSQL). Na potrzeby tej instalacji skonfigurujemy bazę danych PostgresSQL.

Konfiguracja bazy danych sprowadza się do następujących punktów:

  • konfiguracja pliku pg_hba.conf, w przypadku Ubunut plik ten znajduje się w tym katalogu: /etc/postgresql/8.4/main, należy włączyć logowanie zaufane dla użytkowników korzystających z lokalnego interfejsu sieciowego oraz z lokalnego komputera (uwaga, powoduje to, że nie będą oni pytani o hasło dostępu przy próbie łączenia się z bazą danych):
    82
    83
    84
    85
    86
    #local   all         all                               ident
    local   all         all                               trust
    # IPv4 local connections:
    #host    all         all         127.0.0.1/32          md5
    host    all         all         127.0.0.1/32          trust
  • utworzenie użytkownika w bazie danych o nazwie rhqadmin oraz z hasłem rhqadmin:
    createuser -U postgres -S -D -R -P rhqadmin
  • utworzyć bazę danych rhq, której właścicielem będzie użytkownik rhqadmin:
    createdb -U postgres -O rhqadmin rhq

Krok 4: kompilacja RHQ Server

Można teraz przystąpić do kompilacji oraz instalacji serwera RHQ. Robi się to przy użyciu aplikacji Maven, która powinna być dostępna na ścieżce. Pierwsze wykonanie kompilacji może zająć sporo czasu (w moim przypadku trwało to ponad godzinę), ponieważ muszą zostać pobrane odpowiednie biblioteki niezbędne do kompilacji.

Uruchomić kompilacje można wydając takie polecenie (należy jednocześnie znajdować się w katalogu z plikami źródłowymi RHQ Server):

mvn -Penterprise,dev -Dmaven.test.skip=true -Ddbsetup install

Parametr -Ddbsetup powoduje utworzenie schematu w bazie danych i jest wymagany podczas pierwszej kompilacji i za każdym razem gdy jej schemat zostanie zmieniony.

W trakcie procesu kompilacji zostanie utworzony schemat bazy danych. Zostanie także utworzony katalogu dev-container, w którym będzie znajdowała się aplikacji. Aby uruchomić RHQ Server, należy wejść do katalogu dev-container/bin i wykonać polecenie:

cd dev-container/bin
./rhq-server.sh start

Spowoduje to uruchomienie serwera RHQ. Po uruchomieniu powinien o być dostępny pod adresem: http://localhost:7080. Aby się do niego zalogować, należy użyć loginu rhqadmin oraz hasła rhqadmin.

About RHQ

Informacje o wersji RHQ Server

Istnieje także możliwość utworzenia archiwum z serwerem RHQ, które będzie można następnie użyć do instalacji nowej jego instancji. Należy w takim przypadku wydać następujące polecenie (będąc w katalog głównym ze źródłami RHQ):

mvn -Penterprise,dist -Dmaven.test.skip=true -Ddbsetup install

Spowoduje to kompilację projektu i utworzenie w katalogu modules/enterprise/server/container/target zarówno katalogu z serwerem (rhq-server-1.4.0-SNAPSHOT), jak i odpowiedniego archiwum zip (rhq-server-1.4.0-SNAPSHOT.zip). Uruchomienie tak przygotowanego serwera spowoduje konieczność przejścia przez kolejne kroki związane z jego konfiguracją.

Krok 5: kompilacja Jopr

Ostatnim elementem jest kompilacja pluginów wchodzących w skład Jopr oraz ich instalacja w ramach serwera RHQ.

Zanim jednak uda się zbudować Jopr, trzeba zmodyfikować pliki konfiguracyjne pom.xml w kilku miejscach. Jest to spowodowane tym, że znajdują się w nich odwołania do repozytorium Mavena, które nie istnieją, więc nie daje się przeprowadzić pomyślnie kompilacji projektu. Mam nadzieję, że zostanie to zmienione w repozytorium i nie będzie potrzeby wprowadzania tych zmian, ale dla wersji której ja używałem niestety było to potrzebne.

Przygotowałem plik o nazwie jopr-1360.patch, który zawiera różnice pomiędzy modyfikacjami które wprowadziłem oraz wersją źródeł które używałem. Należy pobrać ten plik i użyć aplikacji patch, która zastosuje go do źródeł. Aplikację te należy wywołać w katalogu w którym znajdują się źródła jopr:

$ patch -p0 < ../jopr-1360.patch.txt
patching file modules/tools/jbas5-plugin-descriptor-gen/pom.xml
patching file modules/plugins/jboss-as-5/testsuite/pom.xml
patching file modules/plugins/jboss-as-5/pom.xml
patching file modules/plugins/jboss-cache-v3/pom.xml
patching file pom.xml
patching file etc/jbas5-ejb2-mdb-test/pom.xml
patching file etc/jbas5-jnp-client/pom.xml
patching file etc/jbas5-ejb-client/pom.xml

Należy zwrócić uwagę na to, że niekoniecznie ten plik będzie działał, jeżeli coś się zmieniło w źródłach aplikacji. Dlatego też w przypadku gdy kompilacja nie będzie działać, proponują zobaczyć co ten plik modyfikuje i ręcznie te modyfikacje nanieść do odpowiednich plików.

Sama kompilacja Jopr polega na wywołaniu aplikacji Maven (w katalogu ze źródłami aplikacji):

mvn -Pdev -Drhq.containerDir=rhq/dev-container/ install

Za pomocą parametru -Drhq.containerDir wskazujemy miejsce, gdzie znajduje się skompilowana wersja RHQ Server. Należy zwrócić uwagę, aby podać pełną ścieżkę do tego katalogu, w innym przypadku pluginy mogą zostać skopiowane do innego katalogu.

Zamiast katalogu z wersją deweloperską serwera RHQ można także podać katalog modules/enterprise/server/container/target/rhq-server-1.4.0-SNAPSHOT. Wtedy wtyczki zostaną skopiowane do tej instancji serwera, wystarczą ją teraz skompresować i już można spróbować zainstalować na innym serwerze.

Tyle przynajmniej w teorii :(. Z jakiś magicznych powodów podczas instalacji serwera RHQ łącznie z wtyczkami z Jopra pojawiał się błąd o niemożliwości instalacji jednej z aplikacji (rhq.ear).W moim przypadku nie chciało to do końca działać. Rozwiązaniem okazało się utworzenie dwóch oddzielnych archiwów: w jednym był serwer RHQ, w drugim wtyczki Jopr. Czy w przypadku kompilacji wtyczek Jopr nie podajemy katalogu do samego serwera, ale jakiś katalog tymczasowy. Zostanie w nim odzwierciedlona odpowiednia struktura serwera, i wtyczki zostaną zapisane w odpowiednie miejsca. Wystarczy po instalacji serwera RHQ po prostu skopiować te pliki i już powinno działać.

Oto serwer RHQ Server oraz wtyczki Jopr, skompilowane:

Logowanie zadawanych zapytań do bazy danych przy użyciu log4jdbc

Duża (jeżeli nie większość) część aplikacji korzysta z bazy danych. Zapisuje oraz pobiera z niej informacje praktycznie na okrągło i co ważniejsze, nie jest w stanie poprawnie funkcjonować bez niej. W przypadku Javy połączenia realizowane z bazą danych są opisane poprzez standard JDBC (Java DataBase Connectivity). Praktycznie wszystkie sterowniki do baz danych relacyjnych opierają się na tym standardzie i realizują opisane w nim funkcje. Ponieważ aplikacje tak silnie zależą od baz danych, często pojawiają się różne problemy związane z ich użyciem. W celu ich analizy przydatne może być możliwość sprawdzenia, jak wyglądają poszczególne zapytania do bazy danych wysłane przez aplikację, łącznie z informacje jakie dane są w nich przesyłane.

Jedną z możliwości sprawdzenia (dokładnego) jak wyglądają poszczególne zapytania do bazy danych, jest użycie specjalnego sterownika pośredniczącego pomiędzy naszą aplikacją a serownikiem bazodanowym. Pośrednik ten umożliwia zalogowanie odpowiedniego zapytania zanim zostanie ono przekazane do sterownika odpowiedzialnego za połączenie się z bazą danych i wykonywania na niej operacji. Takim sterownikiem pośredniczącym jest log4jdbc.

Instalacja biblioteki w aplikacji

Pierwszym krokiem powinno być pobranie odpowiedniej wersji biblioteki ze strony log4jdbc. Należy zwrócić uwagę, że inne wersje są zalecane w zależności od tego, jaka wersja Javy zostanie użyta do uruchomienia aplikacji. W moim przypadku najwłaściwszy był plik log4jdbc4-1.2beta1.jar.

Powyższy plik JAR należy dołączyć do ścieżki aplikacji. Ja w swoim przypadku korzystałem z aplikacji uruchomionej na serwerze aplikacyjnym JBoss, więc skopiowałem ten plik do katalogu [cc]common/lib[/cci]. Pozostał jeszcze tylko restart serwera i biblioteka jest gotowa do użycia.

Inicjalizacja połączenia

Istnieją dwa sposoby inicjalizacja biblioteki: w kodzie aplikacji poprzez wywołanie odpowiedniej klasy oraz poprzez odpowiednie utworzenie łańcucha połączenia z bazą danych w standardzie JDBC.

Inicjalizacja log4jdbc w kodzie aplikacji

Oto przykładowy kod źródłowy, jaki należy użyć w aplikacji :

1
2
3
4
5
6
7
// get connection from datasource
Connection conn = dataSource.getConnection();

// wrap the connection with log4jdbc
conn = new net.sf.log4jdbc.ConnectionSpy(conn);

// now use Connection as normal (but it will be audited by log4jdbc)

Czyli najpierw tworzymy lub pozyskujemy połączenie do bazy danych, a następnie przekazujemy je do instancji klasy ConnectionSpy, która od tej pory będzie pośredniczyć w wywoływaniu odpowiedniego kodu i logowaniu informacji przez bibliotekę log4jdbc.

Inicjalizacja połączenia przy użyciu JDBC

Drugim sposobem jest zdefiniowanie połączenia do bazy danych przy użyciu łańcucha JDBC. Robi się to dodając informację o użyciu biblioteki log4jdbc w łańcuchu definiującym połączenie. Jeżeli podstawowe połączenie z bazą danych wygląda następująco (połączenie z bazą danych MySQL):

jdbc:mysql://localhost:3306/baza_danych

To należy dodać do łańcucha ten ciąg znaków log4jdbc, tak aby wyglądał on następująco:

jdbc:log4jdbc:mysql://localhost:3306/baza_danych

Jako klasę sterownika należy użyć klasy: net.sf.log4jdbc.DriverSpy. Przykładowa konfiguracja źródła danych dla JBossa wygląda następująco:

1
2
3
4
5
6
7
8
9
<?xml version="1.0" encoding="UTF-8"?>
<datasources>
  <local-tx-datasource>
    <jndi-name>bazaDanychDS</jndi-name>
    <connection-url>jdbc:log4jdbc:mysql://localhost:3306/baza_danych</connection-url>
    <driver-class>net.sf.log4jdbc.DriverSpy</driver-class>
    <!-- definicja użytkownika, hasła, innych parametrów potrzebnych do połączenia z bazą danych -->
  </local-tx-datasource>
</datasources>

Biblioteka log4jdbc automatycznie postara się zaincjalizować odpowiednią klasę sterownika dla używanej bazy danych. Pełna list domyślnie używanych klas (w zależności od wybranej bazy danych) znajduje się na stronie domowej tego projektu, poniżej znajduje się wybór kilku najczęściej używanych:

Baza danych Klasa sterownika
Oracle oracle.jdbc.driver.OracleDriver
MySQL com.mysql.jdbc.Driver
PostgresSQL org.postgresql.Driver
HSQLDB org.hsqldb.jdbcDriver

Jeżeli istnieje potrzeba użycia innego sterownika do bazy danych, można te informacje przekazać do biblioteki konfigurując odpowiednią zmienną systemową log4jdbc.drivers:

-Dlog4jdbc.drivers=<driverclass>[,</driverclass><driverclass>...]

Teraz pozostaje uruchomić aplikację i w logach powinny znaleźć się informacje o zadawanych zapytaniach, o wartościach poszczególnych parametrów w zapytaniu (szczególnie pomocne w podczas używania klasy PreparedStatement).

Konfiguracja loggerów

Biblioteka log4jdbc definiuje pięć różnych loggerów odpowiedzialnych za zapisywanie różnych informacji dotyczących komunikacji z bazą danych. Każdy z nich może mieć ustawiony jeden z poziomów logowania: DEBUG, INFO, ERROR, FATAL.

Jeżeli wszystkie będą ustawione na poziom FATAL, to faktycznie log4jdbc zostanie wyłączony. Wtedy też nowo tworzone połączenie nie będą otaczane klasą ConnectionSpy tylko będzie to bezpośrednie połączenie z bazą danych. Taki sposób działania jest przydatny, ponieważ można nawet w środowisku produkcyjnym mieć zdefiniowane połączenie z bazą danych przy użyciu log4jdbc, ale włączać je za pomocą definicji odpowiednich zmiennych, bez potrzeby modyfikowania łańcucha definiującego połączenie.

Znaczenie pozostałych poziomów logowania:

  • ERROR – wypisanie stack trace w logu w przypadku wystąpienia wyjątku SQLException
  • INFO – dodanie wyświetlania poleceń SQL
  • DEBUG – dodanie nazwy klasy oraz numeru linii w której zostało wykonane dane polecenie SQL (powoduje także większy narzut czasowy na zapisanie takie informacji w logu)

Dostępne loggery:

Logger Opis
jdbc.sqlonly logowanie samych poleceń SQL, w przypadku korzystania z klasy PreparedStatement także zostaną podane wartości poszczególnych parametrów
jdbc.sqltiming informacje o czasie wykonywania poszczególnych zapytań SQL
jdbc.audit logowanie wszystkich wywołań JDBC poza wynikami (używane do wyszukiwania problemów z JDBC)
jdbc.resultset logowanie wszystkich wywołań do klasy ResultSet
jdbc.connection logowanie informacji o otwieraniu i zamykaniu połączeń, pomocne w przypadku wystąpienia problemów z wyciekami połączeń

Przykładowa fragment linii poleceń wywołującej JVM w którym są te loggery włączane:

-Djdbc.sqlonly=DEBUG -Djdbc.sqltiming=DEBUG -Djdbc.audit=INFO -Djdbc.connection=INFO

Źródła

Tags: , , , , , , , ,

Odszukanie plików JAR z brakującymi definicjami klas

Często pojawiającym się problem (i bardzo irytującym przy okazji) podczas uruchamiania aplikacji napisanych w Javie jest brak jakiś klas potrzebnych do uruchomienia aplikacji. Ja się ostatnio spotkałem z takim problemem próbując testować jakąś aplikację, której autorów nikt od dawana nie widział.

Znam dwie metody na sprawdzenia, jak nazywa się plik JAR z daną klasą:

Odszukanie pliku JAR przy użyciu strony internetowej

Przy użyciu wyszukiwarki FindJAR.com można w łatwy sposób sprawdzić, w jakich plikach znajduje się poszukiwana klasa. Wystarczy w polu wyszukiwania wpisać nazwę klasy (niekoniecznie nawet z pełną nazwą pakietu), ewentualnie wybrać dokładną nazwę klasy z prezentowanych odpowiedzi i już widać, w jakich plikach znajduje się dana klasa.

Zrobiłem test dla klasy javax.jws.WebParam, wyniki można zobaczyć tutaj: http://www.findjar.com/class/javax/jws/WebParam.html:

findJAR wyniki dla WebParam

findJAR wyniki dla WebParam

Teraz pozostaje tylko pobrać plik i przynajmniej jedną klasę mamy już głowy ;).

Odszukanie pliku jar przy użyciu aplikacji

Do odszukania potrzebnych plików można także użyć aplikacji [cco]jarSearch[/cci]. W artykule Which jar contains my… można znaleźć dokładny opis możliwości aplikacji (większy niż przedstawiony tutaj) oraz link do źródeł.

Aplikacja przeszukuje podany katalog oraz podkatalogi w celu odnalezienia plików JAR i sprawdza czy znajduje się w nim podana klasa. Jeżeli znajdzie ją, to wyświetla odpowiednią informację.

Po pobraniu pliku zip jarSearchSrc.zip z plikami źródłowymi, należy je skompilować:

$ ant build
Buildfile: build.xml

build:
   [delete] Deleting directory /home/lukasz/install/java/jarSearch/classes
    [mkdir] Created dir: /home/lukasz/install/java/jarSearch/classes
    [javac] Compiling 4 source files to /home/lukasz/install/java/jarSearch/classes

BUILD SUCCESSFUL
Total time: 1 second

Aby użyć jarSearch należy z katalogu z plikiem build.xml wydać komendę:

$ java -cp jarSearch.jar com.isocra.utils.jarSearch.DirectorySearcher /jboss-as/client/ javax.jws.WebParam.class
/jboss-as/client/jbossws-native-jaxws.jar: javax/jws/WebParam.class
1 entries found.
Directory searcher: http://www.isocra.com

Pierwszym parametrem jest katalog z który zawiera pliki jar, drugim natomiast nazwa szukanej klasy. W powyższym przykładzie widać, że został odnaleziony jeden plik, który zawiera poszukiwaną klasę jbossws-native-jaxws.jar

Widać, że efekty działania obu sposobów są trochę inne. Strona findJAR oferuje nam możliwość odnalezienia wybranej klasy i następnie ściągnięcia odpowiedniego pliku. Natomiast aplikacja jarSearch pozwala po prostu sprawdzić w której bibliotece ukrywa się szukana klasa.

Źródła

Tags: , , , , ,