Posts Tagged JBoss

Konfiguracja klastra oparta o moduł mod_cluster – konfiguracja

Maj 18

Posted by Łukasz Stelmach in JBoss AS | Comments off

Po wstępie wyjaśniającym czym jest mod_cluster oraz jak skompilować odpowiednie moduły potrzebne do jego uruchomienia czas na konfigurację.

Oto wpisy poświęcone konfiguracji modułowi mod_cluster:

  1. Konfiguracja klastra oparta o moduł mod_cluster — wprowadzenie
  2. Konfiguracja klastra oparta o moduł mod_cluster — kompilacja modułów
  3. Konfiguracja klastra oparta o moduł mod_cluster – konfiguracja

Pobranie modułu mod_cluster

Odpowiednie pliku do ściągnięcie można znaleźć na stronie projektu. Ja użyłem wersji stabilnej oznaczonej jako 1.0.3 GA dla platformy 64 bitowej:

Instalacja modułów w serwerze Apache

Należy pamiętać, że mod_cluster wymaga wersji Apacha przynajmniej 2.2.8. Może to być problem w przypadku RHEL 5.5, ponieważ tutaj dostępna jest wersja 2.2.3. Należy w związku z tym zainstalować nowszą wersję aplikacji.

Należy rozpakować plik z bibliotekami dynamicznymi (mod_cluster-1.0.3.GA-linux2-x64-so.tar.gz) i skopiować zawarte w nim biblioteki do katalogu /etc/httpd/modules):

cp mod_advertise.so mod_manager.so mod_proxy_cluster.so mod_slotmem.so /etc/httpd/modules

W przypadku gdy nie znajdziemy odpowiedniej wersji modułów, należy skompilować je samodzielnie.

Konfiguracja serwera WWW Apache

Jeżeli wszystko poszło OK, to powinniśmy już dysponować zainstalowanymi modułami potrzebnymi do działania klastra. Aby je włączyć, należy kazać je serwerowi Apache załadować i odpowiednio je skonfigurować.

Należy utworzyć plik /etc/httpd/conf.d/jboss.conf. Pliki znajdujące się w tym katalogu i z rozszerzeniem conf zostaną automatycznie wczytane podczas startu serwera i zinterpretowane. W pliku tym załadujemy potrzebne moduły oraz zdefiniujemy serwer wirtualny, w ramach którego będzie działa balansowanie ruchem.

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
LoadModule slotmem_module modules/mod_slotmem.so
LoadModule manager_module modules/mod_manager.so
LoadModule proxy_cluster_module modules/mod_proxy_cluster.so
LoadModule advertise_module modules/mod_advertise.so

<VirtualHost 192.168.3.11:80>

        <Directory />
                Order deny,allow
                Allow from all
        </Directory>

        KeepAliveTimeout 60
        MaxKeepAliveRequests 0

       AdvertiseFrequency 5

       <Location /mod_cluster-manager>
           SetHandler mod_cluster-manager

           Order deny,allow
           Deny from all
           Allow from 127.0.0.1
       </Location>


</VirtualHost>

Powyższy plik jest minimalnym plikiem, który pozwala nam uruchomić klaster. Jeżeli serwer Apache uruchomił się bez problemów, można uznać do za sukces i przystąpić do dalszych kroków.

Definicja serwera wirtualnego jest standardowa, poza następującymi elementami:

  • AdvertiseFrequency – czas jaki musi upłynąć pomiędzy próbą wykrycia adresów IP oraz portu, domyślna wartość to 10 sekund
  • SetHandler – pozwala na wyświetlanie informacji o tym, jakie węzły klastra są widoczne przez moduł mod_cluster

Problemy ze startem serwera Apache

W przypadku problemów trzeba jest najpierw rozwiązać. Ja spotkałem się z nastepującymi problemami:

  • Cannot load /etc/httpd/modules/mod_slotmem.so into server: /etc/httpd/modules/mod_slotmem.so: cannot open shared object file: No such file or directory – brak możliwości otworzenia podanego pliku. Może to oznaczać:
    • brak pliku w podanej lokalizacji, czyli błędnie skopiowany plik
    • błędne uprawnienia na plik (biblioteka powinna mieć ustawiony bity do odczytu i wykonywalności)
    • próba wczytania biblioteki o złej architekturze (to przytrafiło się mi 🙂 ), można to sprawdzić w prosty sposób, wynik tego polecenia powinien zwrócić takie same informacje (poniżej są inne):
      file /etc/httpd/modules/mod_slotmem.so /etc/httpd/modules/mod_alias.so
      /etc/httpd/modules/mod_slotmem.so: ELF 64-bit LSB shared object, IA-64, version 1 (SYSV), not stripped
      /etc/httpd/modules/mod_alias.so:   ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped
  • Module mod_proxy_balancer is loaded it must be removed  in order for mod_proxy_cluster to function properly – komunikat pojawi się w w pliku error.log. Aby rozwiązać problem, należy usunąć ładowanie modułu mod_proxy_balancer. Można to zrobić edytując plik /etc/httpd/conf/httpd.conf i zakomentować linię:
    189
    #LoadModule proxy_balancer_module modules/mod_proxy_balancer.so

Instalacja modułu w serwerze aplikacji

Pierwszym krokiem jest skopiowanie aplikacji mod_cluster.sar do katalogu deploy danego serwera:

cp -a mod_cluster.sar $JBOSS_HOME/server/node1/deploy

Teraz należy odpowiednio skonfigurować serwer aplikacji. Konfiguracja będzie dotyczyła aplikacji jbossweb.sar znajdującej się w katalogu deploy danej konfiguracji serwera. W pliku tym należy dodać następujący element (pod istniejącymi elementami Listener):

9
10
11
<Listener
 className="org.jboss.web.tomcat.service.deployers.MicrocontainerIntegrationLifecycleListener"
 delegateBeanName="ModClusterService"/>

Drugą modyfikacją jest dodanie zmiennej jvmRoute do sekcji Engine:

36
<Engine name="jboss.web" defaultHost="localhost" jvmRoute="node1">

Na podstawie tej wartości dany węzeł będzie identyfikowany przez serwer Apache, wartość ta powinna być unikalna w ramach klastra.

Kolejnym plikiem który trzeb otworzyć jest deploy/jbossweb.sar/META-INF/jboss-beans.xml. Do pliku tego należy dodać następujący w ramach definicji ziarna WebServer następującą zależność:

17
<depends>ModClusterService</depends>

I to wszystko, teraz należy wystartować serwery Apache oraz JBoss i jeżeli nie wystąpią jakieś błędy to powinniśmy mieć już skonfigurowany load balancer. Można otworzyć lokalizację mod_cluster-manager na serwerze WWW i sprawdzić, czy mod_cluster poprawnie wykrył klaster.

Pozostaje jeszcze skonfigurować pozostałe węzły klastra i również je uruchomić.

Źródła

Tags: , , , ,

Konfiguracja klastra oparta o moduł mod_cluster – kompilacja modułów

Maj 17

Posted by Łukasz Stelmach in JBoss AS | Comments off

Moduł mod_cluster jest dostępny dla kliku architektur, ale na pewno nie dal wszystkich. W moim przypadku wersja pobrana ze stron JBossa nie chciała działać z serwerem Apache. Nie pozostało więc nic innego, jak skompilować odpowiednie moduły ze źródeł. Na szczęście nie jest to trudne :).

Oto wpisy poświęcone konfiguracji modułowi mod_cluster:

  1. Konfiguracja klastra oparta o moduł mod_cluster — wprowadzenie
  2. Konfiguracja klastra oparta o moduł mod_cluster — kompilacja modułów
  3. Konfiguracja klastra oparta o moduł mod_cluster – konfiguracja

Krok 1: instalacja potrzebnych pakietów

Pierwszym krokiem jest rozstrzygnięcie, czy chcemy korzystać z wersji udostępnionej na stronie w postaci źródeł czy też pobrać najnowszą wersję modułów z systemu kontroli wersji. W pierwszym przypadku trzeba udać się na stronę pozwalająca ściągnąć źródła w odpowiedniej wersji.

W przypadku drugim należy zainstalować (jeżeli nie mamy) narzędzie Subversion. W moim przypadku komenda instalująca pakiet była następująca (musiałem wybrać wersję architektury, aby zainstalowała się odpowiednia wersja pakietu, prawdopodobnie nie jest to potrzebne w większości przypadków):

yum install subversion.x86_64

Kolejnym elementem jest instalacja dwóch pakietów:

  • autoconf – narzędzia potrzebne do konfiguracji kompilacji
  • httpd-devel – narzędzia i biblioteki potrzebne do budowania modułów dla serwera Apache
yum install autoconf
yum install httpd-devel-2.2.14-1.2.6.jdk6.ep5.el5.x86_64

I tutaj również musiałem bardzo szczegółowo podać wersję pakietu httpd-devel. Być może będziesz potrzebować innych pakietów więc w razie problemów w dalszych krokach będzie trzeba te braki uzupełnić.

Krok 2: pobranie źródeł

W celu pobrania źródeł pakietu z systemu kontroli wersji należy wydać następujące poleceni:

svn co http://anonsvn.jboss.org/repos/mod_cluster/trunk/ mod_cluster

Utworzy ono katalog mod_cluster i w nim zapisze pobrane źródła.

Można także pobrać źródła modułu ze strony Downloads.

Ja pobrałem aktualne źródła z repozytorium, w wersji o numerze 271.

Krok 3: kompilacja i instalacja modułów

Odpowiednie moduły skompilują poniższy zestaw instrukcji (powinny one zostać wykonane w katalogu mod_cluster/native:

1
2
3
4
5
6
7
8
9
for DIR in advertise mod_manager mod_proxy_cluster mod_slotmem
do
    cd $DIR
    sh buildconf
    ./configure --with-apxs=/usr/sbin/apxs
    make
    cp *.so /etc/httpd/modules/
    cd ..
done

Przed uruchomieniem powyższego skryptu proszę zwrócić uwagę na ścieżki dostępu, zarówno do narzędzia apxs jak i miejscu gdzie znajdują się moduły Apacha. Powyższy także kopiuje moduły do katalogu z modułami.

Jeżeli kompilacja przebiegła bez problemów, to odpowiednie moduły powinny już znaleźć się w katalogu z modułami Apache i można je używać.

Źródła

  • Building mod_cluster from sources

Tags: , , , , ,

Konfiguracja klastra oparta o moduł mod_cluster – wprowadzenie

Maj 16

Posted by Łukasz Stelmach in JBoss AS | Comments off

Wpisem tym rozpoczynam serię poświęconą modułowi pozwalającemu na budowę łącza pomiędzy serwerem WWW Apache a serwerem aplikacji JBoss w wersji 5. Postaram się opisać sposób instalacji, kompilacji, konfiguracji, przygotowania do działania.

Oto wpisy poświęcone konfiguracji modułowi mod_cluster:

  1. Konfiguracja klastra oparta o moduł mod_cluster — wprowadzenie
  2. Konfiguracja klastra oparta o moduł mod_cluster — kompilacja modułów
  3. Konfiguracja klastra oparta o moduł mod_cluster – konfiguracja

Istnieją dwa główne sposoby na które można można udostępnić aplikację webową działającą na JBossie (lub też Tomcacie) w Internecie:

  • udostępnić bezpośredni dostęp do serwera aplikacji na którym jest zainstalowana aplikacja
  • wykorzystanie odpowiedniego pośrednika, który będzie pośredniczył pomiędzy wywołaniami z Internetu a serwerem aplikacji

Pierwszy sposób jest łatwy do realizacji, ale posiada kilka wad, takich jak:

  • brak wsparcia balansowania ruchem (w przypadku konfiguracji z klastrem)
  • brak optymalizacji wydajności (np. serwowanie statycznej treści z innych źródeł, bardziej wydajnych niż serwer aplikacji)
  • mniejsze bezpieczeństwo (trudniej zabezpieczyć serwer aplikacji z powodu dużej ilości działających usług)

Drugim sposobem jest udostępnienie odpowiednich usług poprzez pośrednika, który będzie przekierowywał połączenia przychodzące do aplikacji na serwerze JBoss. Rozwiązanie takie charakteryzuje się:

  • trudniejszą konfiguracją (trzeb skonfigurować zarówno pośrednika jak i serwer aplikacji)
  • wsparciem dla balansowania ruchem i failover
  • zwiększa bezpieczeństwo (udostępniamy tylko te aplikacje, na jakich nam zależy)
  • może zwiększyć wydajność rozwiązania (serwowanie statycznych fragmentów strony z innych źródeł niż serwer aplikacji)

Najczęściej używanym pośrednikiem w przypadku łączenia z JBossem lub Tomcatem jest serwer WWW Apache. W jego przypadku mamy możliwość skorzystania z trzech różnych modułów pozwalających na łączenie się z serwerem aplikacji:

  • mod_proxy – szybki i łatwy sposób konfiguracji, ale gorsze wsparcie klastrowania
  • mod_jk – zaawansowany moduł z dobrą obsługa klastrów, skomplikowany w konfiguracji
  • mod_cluster – nowo rozwijany moduł pozwalający na połączenie z serwerem aplikacji

Każdy z tych modułów konfiguruje się inaczej, mają także inne właściwości. Poniżej postaram się przedstawić sposób konfiguracji połączenie pomiędzy serwera Apacha z modułem mod_cluster a serwerem aplikacji JBoss.

Wymagania minimalne

Moduł mod_cluster posiada określone wymagania zarówno odnośnie serwera Apache jak JBoss:

  • serwer WWW Apache w wersji co najmniej 2.2.8
  • serwer JBoss w wersji co najmniej 5.0

Konfiguracja z której ja będę korzystał jest następująca:

  • system operacyjny: Red Hat Enterprise Linux 5.5 64bit
  • serwer WWW: Apache w wersji 2.2.14 – standardowe jest dostępna wersja 2.2.3, nowszą wersję serwera można pobrać z kanału JBoss EWS for 5Server x86_64
  • Java: wersja 1.6.20
  • serwer aplikacji JBoss EAP 5 – aby przetestować działanie klastra zostanie utworzony klaster składający się z trzech węzłów
  • moduł mod_cluster, wersja 1.1.0.CR2

Czym jest moduł mod_cluster

Moduł mod_cluster odpowiada za przeprowadzenia balansowanie ruchem bazującym o protokół HTTP. Pozwala on na przekierowanie żądań przychodzących do serwera WWW do jednego z węzłów klastra.

W przeciwieństwie do dwóch pozostałych modułów (mod_jk oraz mod_proxy) tworzy on dodatkowe połączenie pomiędzy poszczególnymi węzłami klastra a serwerem WWW. Poprzez do połączenie odpowiednia aplikacja po stronie serwera aplikacji informuje moduł mod_cluster o swojej sytuacji. Wykorzystuje w tym celu zestaw metod, zwanych Mod-Cluster Management Protocol (MCMP). Te dodatkowe informacje pozwalają na duże lepszą integrację serwera WWW z klastrem oraz lepsze zarządzanie przekazywanymi połączeniami.

Zalety mod_cluster

Najważniejsze zalety w stosunku do innych aplikacji odpowiedzialnych za balansowanie ruchem HTTP:

  • dynamiczna konfiguracja połączeń z węzłami klastra
  • obliczanie współczynników balansowania ruchem po stronie serwera
  • kontrola na cyklem życia aplikacji zainstalowanej na klastrze
  • opcjonalne użycie protokołu AJP

W następnych częściach przedstawię, w jaki sposób skonfigurować moduł mod_cluster do pracy z klastrem serwerów JBoss.

Źródła

Tags: , , , ,

Polecenie twiddle: operacje na zasobach serwera

Maj 15

Posted by Łukasz Stelmach in JBoss AS | Comments off

Polecenie twiddle pozwala na wykonywanie różnych operacji na serwerze aplikacji JBoss.

List wszystkich wpisów z tej serii:

  1. Polecenie twiddle: jak połączyć się z serwerem aplikacji JBoss AS
  2. Polecenie twiddle: jak znaleźć informacje o ziarnach i metodach
  3. Polecenie twiddle: operacje na na zasobach serwera

Pobranie informacji o wartości atrybutu: get

Przy użyciu polecenia twiddle można uzyskać informacje o wartości różnych atrybutów poszczególnych ziaren przy użycia komendy get. Konstrukcja polecenia jest następująca:

$ twiddle.sh -H get
Help for command: 'get'

Get the values of one or more MBean attributes

usage: get [options] <name> [<attr>+]
  If no attribute names are given all readable attributes are retrieved
options:
    --noprefix    Do not display attribute name prefixes
    --            Stop processing options

Jak widać, aby poznać wartość wybranego ziarna należy odwołać się do ziarna oraz podać listę atrybutów, których wartości nas interesują. Przykładowe wywołanie, sprawdzające czy serwer wystartował:

$ twiddle.sh get "jboss.system:type=Server" Started
Started=false

Jak widać, serwer jeszcze nie działa, polecenie zostało wykonane w trakcie jego startu. Wydanie go już po pomyślnym starcie serwera zwraca następujący wynik:

$ twiddle get --noprefix "jboss.system:type=Server" Started
true

Widać tutaj także jak wpływa na wynik działania użycie opcji --noprefix, zostanie wyświetlona tylko wartość podanego atrybutu, bez jego nazwy.

A oto jak działa pobranie wartości więcej niż jednego atrybutu (w tym przypadku minimalnej i maksymalnej ilości otwartych połączeń w danej puli):

$ twiddle.sh get jboss.jca:name=DefaultDS,service=ManagedConnectionPool MinSize MaxSize
MinSize=5
MaxSize=20

To samo polecenie, ale bez nazw atrybutów:

$ twiddle.sh get --noprefix jboss.jca:name=DefaultDS,service=ManagedConnectionPool MinSize MaxSize
5
20

Ustawienie wartości atrybutów: set i setattrs

Do ustawienia wartości pojedynczego atrybutu można użyć komendy set:

$ twiddle.sh -H set
Help for command: 'set'

Set the value of one MBean attribute

usage: set [options] <name> <attr> <val>
options:
    --noprefix    Do not display attribute name prefixes
    --            Stop processing options

Do zmiany wartości atrybutu potrzeba jest wiedza o nazwie ziarna oraz nazwie atrybutu. Przykładowe wywołanie, zmieniające minimalną ilość otwartych połączeń w puli:

$ twiddle.sh set jboss.jca:name=DefaultDS,service=ManagedConnectionPool MinSize 10
MinSize=10

Ustawia wartość otwartych połączeń na 10.

Do jednoczesnej zmiany wartości więcej niż jednego atrybutu w danym ziarnie można użyć komendy setattrs:

$ twiddle.sh -H setattrs
Help for command: 'setattrs'

Set the values of one or more MBean attributes

usage: setattrs [options] <name> [<attr value>+]
options:
    --noprefix    Do not display attribute name prefixes
    --            Stop processing options

Struktura polecenia jest taka sama jak polecenia set, pozwala jednak na podanie większej ilości atrybutów. Przykładowe wywołanie zmieniające minimalną i maksymalną ilość połączeń w puli:

$ twiddle.sh setattrs jboss.jca:name=DefaultDS,service=ManagedConnectionPool MinSize 5 MaxSize 30
The following attributes were set successfuly:
MinSize=5
MaxSize=30

Warto zauważyć, że w wyniku działania tego polecenia albo zostaną ustawione wszystkie wartości wybranych atrybutów (jeżeli nie wystąpi żaden błąd w trakcie działania polecenia) lub też żadne zmiany nie zostaną wprowadzone (w przypadku wystąpienia jakiegoś błędu):

$ twiddle.sh setattrs jboss.jca:name=DefaultDS,service=ManagedConnectionPool MinSize 1 MaxSize pięć
11:52:02,550 ERROR [Twiddle] Exec failed
java.lang.NumberFormatException: For input string: "pięć"
        at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
        at java.lang.Integer.parseInt(Integer.java:449)
        at java.lang.Integer.valueOf(Integer.java:554)
        at sun.beans.editors.IntEditor.setAsText(IntEditor.java:21)
        at org.jboss.console.twiddle.command.SetAttrsCommand.execute(SetAttrsCommand.java:174)
        at org.jboss.console.twiddle.Twiddle.main(Twiddle.java:306)

Pobranie informacji o ziarnach zwróci następujące wartości:

$ twiddle.sh get jboss.jca:name=DefaultDS,service=ManagedConnectionPool MinSize MaxSize
MinSize=5
MaxSize=30

Wywołanie akcji na ziarnie: invoke

Za wywołania konkretnych metod na wybranym ziarnie odpowiada komenda invoke:

$ twiddle -H invoke
Help for command: 'invoke'

Invoke an operation on an MBean

usage: invoke [options] <query> <operation> (<arg>)*

options:
    -q, --query-type[=<type>]    Treat object name as a query
    --                           Stop processing options

query type:
    f[irst]    Only invoke on the first matching name [default]
    a[ll]      Invoke on all matching names

Jako argumenty przyjmuje ona nazwę ziarna na którym ma zostać wykonana dana akcja, nazwę metody do wywołania jej parametry (jeżeli są potrzebne). Wywołania drzewa JNDI:

$ twiddle invoke jboss:service=JNDIView list true
...
<h1>java: Namespace</h1>
<pre>
  +- securityManagement (class: org.jboss.security.integration.JNDIBasedSecurityManagement)
  +- comp (class: javax.namingMain.Context)
  +- XAConnectionFactory (class: org.jboss.jms.client.JBossConnectionFactory)
  +- JBossCorbaInterfaceRepositoryPOA (class: org.omg.PortableServer.POA)
...

Ponieważ polecenie to pozwala na bezpośrednie wywoływania różnych akcji na danym serwerze, istotne jest zabezpieczenie dostępu do konsoli JMX poprzez ustawienie odpowiedniego użytkownika oraz mocnego hasła.

Tags: , , , , , , , , ,

Typy aplikacji jakie można zainstalować w serwerze aplikacji JBoss

Maj 4

Posted by Łukasz Stelmach in JBoss AS | Comments off

Każda aplikacja, która ma działać w ramach danego serwera JBoss musi zostać najpierw zainstalowana przez niego zainstalowana. Jest to możliwe na kilka sposobów:

  • można umieścić aplikację w katalogu deploy serwera;
  • można zainstalować aplikację przy użyciu polecenia twiddle;
  • można użyć konsoli administracyjnej;

Więcej informacji na temat instalacji aplikacji znajduje się w tym wpisie: Zarządzanie instalacją aplikacji w JBoss AS.

Formaty pakietów z aplikacjami

Instalowana aplikacja może zarówno być w formie archiwum jak i jak katalogu z plikami zapisanymi w odpowiedniej strukturze (archiwum to nic innego jak ten sam katalog skompresowany przy użyciu algorytmu ZIP). Każda z form ma swoje wady i zalety, ale nie różnią się one efektem. Zarówno w jednym jak i drugim przypadku pozwalają na instalację aplikacji.

W przypadku skompresowanego archiwum mamy do czynienia z pojedynczym plikiem, które dużo łatwiej przesłać czy też skopiować. W przypadku jego rozkompresowanej formy mamy do czynienia z setkami czy też często tysiącami plików. Trudniej w takim przypadku zarządzać taką aplikacją (nie można np. zainstalować jej przy pomocy konsoli administracyjnej), za istnieje możliwość modyfikacji pojedynczych plików (np. strony JSP) i następnie łatwe wymuszenie restartu aplikacji.

Odpowiedni wątek monitorujący pojawienia się (lub też usuniecie) aplikacji w katalogu deploy monitoruje czasy modyfikacji odpowiednich plików w archiwum. I tak, jeżeli zmienimy odpowiedni plik (w zależności od rodzaju aplikacji) to nastąpi automatyczne odinstalowanie wybranej aplikacji i jej ponowna instalacja.

Podstawowe deskryptory aplikacji
Typ aplikacji Plik deskryptora
WAR WEB-INF/web.xml
EAR META-INF/application.xml
SAR META-INF/jboss-service.xml
JAR META-INF/ejb-jar.xml
RAR META-INF/ra.xml

Typy aplikacji instalowanych przez JBossa

JBoss rozróżnia poszczególne typy aplikacji na podstawie końcówek ich nazw (uwaga, często jest to więcej niż rozszerzenie). Ponieważ każdy typ aplikacji spełnia inne funkcje w ramach infrastruktury, którą zapewnia serwer aplikacji istotne jest zachowanie odpowiedniej kolejności startowania tych aplikacji. I tak różnego rodzaje aplikacje usługowe musza zostać uruchomione przed aplikacjami biznesowymi, które mają z nich korzystać. Tak samo najpierw należy odpowiednio skonfigurować połączenia z bazą danych, zanim zaczną działać aplikacje z nich korzystające.

W poniżej tabeli znajdują się typy poszczególnych aplikacji wraz z ich krótkim omówieniem. Jednocześnie pozycja występowania na tej liście mówi o kolejności startu danej aplikacji.,

Końcówka nazwy Typ aplikacjia
.deployer
-deployer-beans.xml		 Aplikacje, które pozwalają na instalację innych rodzajów aplikacji. W przypadku JBossa 5.1 znajdują się one w katalogu $JBOSS_HOME/server/PROFIL/deployers
aop
-aop.xml		 Definicja aspektów stosowany do klas lub rozszerzenie czy też dodanie nowych funkcji do tych klas
.sar
-service.xml		 Różnego rodzaju aplikacje usługowe, rozszerzające możliwości serwera aplikacji
-jboss-beans.xml Definicja obiektów POJO mikrokontenera
.rar Konfiguracja różnych zasobów
-ds.xml Definicja źródeł danych, używanych potem przez aplikacje w celu uzyskania dostępu do bazy danych
.har Definicja archiwum Hibernate, używanego do do dostępu do bazy danych przy użyciu Hibernate
.jar Zbiór komponentów EJB lub też po prostu biblioteka klas
.zip Serwer aplikacji sprawdzi zawartość archiwum i postara się rozpoznań typ aplikacji jaki się w nim znajduje. Potem zostanie ona zainstalowana jak aplikacja o odpowiednim typie.
.war Archiwum z aplikację webową, dostarczająca interfejs dostępny przez przeglądarkę lub też web service
.wsr Archiwum specyficzne dla JBossa, zawiera web service. Używany jeżeli dana aplikacja ma zostać zainstalowana po wszystkich archiwach WAR.
.ear Aplikacja Java EE, zawiera EJB, aplikacja WAR oraz inne biblioteki klas
.bsh Definicja usługi przy użyciu powłoki bean shell
.last Tak oznaczone aplikacje będą instalowane jako ostatnie w ramach swojego typu

Aplikacje same w sobie mogą byc zagnieżdżone. I tak aplikacja typu EAR najczęściej składa się z szeregu plików JAR z logiką biznesową, z warstwy prezentacji WAR oraz różnych innych deskryptorów. W takim przypadku JBoss stara się odnaleźć te różne aplikacji i je w ramach głównej aplikacji zainstalować. Tutaj również ma zastosowanie taka sama kolejność instalacji aplikacji jak w tabeli powyżej.

Źródła

Tags: , , , ,