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

Sprawdzanie pisowni w edytorze tekstu Vim

W edytorze tekstu Vim istnieje możliwość sprawdzania pisowni w języku polskim.

Włączenie tej funkcji nie jest trudne, w trybie command należy wydać następujące polecenie:

:setlocal spell spelllang=pl

Spowoduje ono włączenie polskiego słownika i automatyczne kolorowanie błędnych znaków.

Jeżeli jest to pierwsze uruchomienie tego polecenia, to należy jeszcze odpowiedzieć na kilka pytań dotyczących pobrania odpowiedniego słownika. Poniższe przykłady pochodzą z wersji edytora okienkowego (czyli z gVima), w przypadku Vima pytania są takie same, ale podawane są odpowiednio w linii poleceń. Podczas testu używałem Vima w wersji 7.2.330.

Pierwsze pytanie dotyczy prośby o wyrażenie zgody na utworzenie katalogu ~/.vim/spell. W katalogu tym będę trzymane odpowiednie słowniki dla używanych języków.

gVim: Utworzenie katalogu dla słownika

gVim: Utworzenie katalogu dla słownika

Oczywiście, podczas pierwszego uruchomienie słownik dla języka polskiego nie jest dostępny. Vim oferuje, że pobierze odpowiedni plik słownika.

gVim: Pobranie pliku ze słownikiem

gVim: Pobranie pliku ze słownikiem

Jeżeli słownik zostanie pomyślnie pobrany, to należy umieścić go w odpowiednim katalogu:

gVim: Zapisanie pliku ze słownikiem

gVim: Zapisanie pliku ze słownikiem

Po tych krokach sprawdzanie pisowni powinno działać. Istniej jeszcze możliwość pobrania pliku o rozszerzeniu sug. Vim także oferuje, że pobierze go samodzielnie. Niestety, przynajmniej w moim przypadku to nie zadziałało (ale sprawdzenie pisowni działa)

gVim: Pobranie pliku z rozszerzeniem sug

gVim: Pobranie pliku z rozszerzeniem sug

Użycie polecenia setlocal w powyższy sposób ma wpływ tylko na aktualnie otwarty dokument. Aby sprawdzenia pisowni działało w każdym otwieranym dokumencie, należy poniższą linię do pliku konfiguracyjnego Vima ~/.vimrc:

setlocal spell spelllang=pl

ja jednak chcę, aby sprawdzanie pisowni (i to w języku polskim) dotyczyło tylko i wyłącznie pików z rozszerzeniem tex. Można to zrobić, definiując odpowiednią komendę, wykonywaną podczas otwierania pliku o odpowiednim typie. Poniższy wpis należy umieścić w pliku ~/.vimrc:

au BufReadPost *.tex setlocal spell spelllang=pl

Teraz pozostaje jeszcze do opanowania odpowiednia klawiszologia (polecenia powinny być wydawane w trybie normalnym):

  • ]s – przeniesienie kursora na następne błędne słowo
  • [s – przeniesienie kursora na poprzednie błędne słowo
  • zg – zdefiniowanie słowa pod kursorem jako poprawne, zostanie ono zapisane w specjalnym pliku
  • zG – zdefiniowanie słowa pod kursorem jako poprawne, ale informacja o tym będzie przechowywana tylko w pamięci RAM
  • zw – zdefiniowanie słowa jako błędnego, zapisanie go w odpowiednim pliku słownika
  • zW – jak wyżej, ale informacje o tym będzie przechowywana tylko w pamięci RAM komputera
  • z= – wyświetlenie ponumerowaną listy podpowiedzi, jeżeli jakieś słowo pasuje, to należy podać jego numer

Więcej informacji można uzyskać w pomocy dołączonej do Vima:

:help spell.txt

Źródła

Tags: , ,

Wyświetlanie komunikatów w języku angielskim

W systemie używam na co dzień języka polskiego, ale bywają sytuację, gdy język angielski jest wg mnie dużo lepszym rozwiązaniem. Przynajmniej w dwóch przypadkach jest bardziej użyteczny:

  • wyświetlenie komunikatów o błędach – ułatwia to wyszukiwanie informacji na dany temat;
  • wyświetlanie stron MAN – mam wrażenie, że wersje angielskie są obszerniejsze i bardziej aktualne.

Za konfigurację języka wyświetlanych komunikatów odpowiada zmienna systemowa LC_MESSAGES. Pozostaje teraz tylko ustawienie tej zmiennej. Można to zrobić przynajmniej na dwa sposoby:

  • w pliku ~/.bashrc – jeżeli chcemy parametr ustawić tylko dla jednego użytkownika;
  • utworzyć plik o nazwie /etc/profile.d/angielskie_komunikaty.sh – jeżeli parametr ma zostać ustawiony każdemu użytkownikowi logującemu się do systemu.

Ja wybrałem drugą wersję, ale w każdym przypadku należy dodać do pliku następującą linię:

export LC_MESSAGES=C

Po ponownym zalogowaniu się do systemu zarówno komunikaty jak i strony MAN powinny być wyświetlane po angielski.


Ustawienie zmiennej LC_MESSAGES na język angielski w bashu spowoduje także zmianę języka używanego przez środowisko graficzne (w moim przypadku KDE automatycznie przeszło na język angielski). Jeżeli nam to przeszkadza, to należy poprzestać tylko na następnym punkcie.

Jeżeli jednak chcemy aby były po angielsku wyświetlane tylko strony MAN, to należy utworzyć odpowiedni alias, który zmodyfikuje ustawienia językowe dla polecenia man:

alias man='man -L C'

Druga możliwość zmiany języka, może być użyte w praktyce z każdą aplikacją (przedefiniowanie wartości zmiennej środowiskowej przed wywołaniem wybranego polecenia):

alias man='LC_MESSAGES=C man'

Powyższą linię można umieścić np. w pliku ~/.bashrc.

Tags: , ,

Problemy z siecią wifi po aktualizacji systemu do Ubuntu 10.10

Podkusiło mnie i zaktualizowałem Ubuntu do wersji 10.10 dobry miesiąc przed wydaniem. Generalnie poszło bez jakiś wielkich problemów, ale po restarcie systemu okazało się, że przestała mi poprawnie funkcjonować łączenie z siecią wifi.

Podczas próby nawiązywania połączenie otrzymywałem z aplikacji Wicd komunikat mówiący o podaniu błędnego hasła. Oczywiście, hasło jak najbardziej było poprawne. Po jakiś kombinacjach, restartach połączenie wróciło — ale po kilku sekundach następowało ponowne rozłączenie i próba inicjalizacji sieci, i tak bez przerwy.

Przejrzałem masę różnych forów, błędów i różnych rozwiązań, ale nic nie pomagało. Nawet próba ręcznej konfiguracji sieci czy też reinstalacji Wicd.

Przy kolejnej próbie przypomniałem sobie o pewnym wynalazku o nazwie network-manager, z którym rozstałem się już dawno temu. Sprawdziłem co się z nim dzieje i okazało się to strzałem w dziesiątkę. Usługa ta została podczas aktualizacji zainstalowana, uruchomiona i w najlepsze przeszkadzająca.

Teraz to wszystko graniczyło się do dwóch kroków:

  1. Zatrzymanie usługi:
    $ sudo stop network-manager
  2. Wyłączenie uruchamiania tej usługi podczas startu komputera, czyli należy zmienić plik /etc/init/network-manager.conf. Poniższy skrypt dokona odpowiedniej modyfikacji (zakomentuje linijki odpowiedzialne za start usługi), a oryginalny plik zapisze pod nazwą /etc/init/network-manager.conf.old (plik ten może potem zostać skasowany):
    $ sudo sed -i.old -e '/start/,+1s/^/#/' /etc/init/network-manager.conf

Nauczka dla mnie: jak nie używasz jakiegoś domyślnego rozwiązania, bądź przygotowany na problemy po aktualizacjach.

Tags: , ,