Archive for Marzec, 2010

Brak uzupełniania kodu podczas edycji strony JSF w Eclipse

Mar 14

Posted by Łukasz Stelmach in Eclipse | Comments off

Czasami zdarza się, że brakuje autouzpełniania kodu (np. beanów) podczas edycji stron JSF (lub XHTML) w Eclipsie. Podczas otwierania takiej strony pojawia się następujące ostrzeżenie:

Brak właściwości JSF

Brak właściwości JSF

Informuje ono, że nie zostały włączone właściwości związane z JSF. Od razu także kieruje na stronę JBosstoolsVisualEditorFAQ, gdzie można znaleźć opis problemu i jego rozwiązanie. Niestety, w moim przypadku rozwiązanie nie zadziałało do końca ;), więc poniżej szczegółowa recepta co zrobić, aby włączyć obsługę autouzupełniania kodu na stronach JSF

Pierwszym krokiem jest taka konfiguracja projektu, aby Eclipse wiedział, że używamy JSF. Należy zaznaczyć projekt w widoku Project Explorer, wywoałć menu przy użyciu prawego klawisza myszy, wybrać pozycję Configure, i na końcu Add JSF Capabilities.

Dodanie możliwości związane z JSF

Dodanie możliwości związane z JSF

Zostanie uruchomiony kreator, w którym należy zdefiniować podstawowe informacje o projekcie.

W pierwszym kroku należy podać nazwę projektu, oraz wskazać lokalizację pliku web.xml danego projektu. W moim przypadku obie wartości były zdefiniowane poprawnie.

Kreator dodania właściwości JSF, strona 1

Kreator dodania właściwości JSF, strona 1

W drugim kroku należy zdefiniować trochę więcej parametrów:

  • Web Root – ścieżka dostępu do zasobów WWW
  • Source Folder – ścieżka dostępu do plików źródłowych
  • Classes Folder – ścieżka dostępu do skompilowanych plików źródłowych
  • Lib Folder
  • Servlet Version
  • Context Path
  • Runtime – serwer, na którym będzie publikowana aplikacja

W moim przypadku musiałem skonfigurować dwa parametry ręcznie:

  • Classes Folder – został błędnie wykryty przez kreator, trzeba było zmienić ścieżka do katalogu build/classes
  • Runtime – podać właściwy serwer, który ma być używany do uruchamiania aplikacji
Kreator dodania właściwości JSF, strona 2

Kreator dodania właściwości JSF, strona 2

Po tych modyfikacjach powinno już działać autouzpełnianie beanów zarówno na strona JSF jak i XHTML.

Tags: , , , , , ,

Poziom izolacji transakcji w JDBC

Mar 12

Posted by Łukasz Stelmach in Java | 2 komentarze

Dostępny interfejs dostępu do baz danych w Javie (JDBC) udostępnia kilka różnych poziomów izolacji poszczególnych transakcji. Pozwala na określenie, jak bardzo poszczególne transakcje mają być oddzielone od siebie. Niezależnie od poziomu izolacji transakcji, operacje takie jak wstawianie (INSERT), usuwanie (DELETE) oraz modyfikowanie (UPDATE) rekordów zachowują się zawsze tak samo, jedynie zachowanie operacji pobierającej (SELECT) dane z tabeli może być rożne.

Poziom transakcji jest ustawiany w ramach pojedynczego połączenia z bazą danych. Można go ustawia się go przy użyciu metody Connection.setTransactionIsolation(). Im wyższy poziom izolacji transakcji tym generalnie mniejsza wydajność operacji na bazie danych oraz większe prawdopodobieństwo wystąpienia blokad w dostępie do bazy danych.

Anomalie występujące w transakcjach

Poniżej znajduje się zestawienie anomalii, jakie mogą wystąpić w transakcjach:

Anomalie występujące w transakcjach
Nazwa anomalii Przykład działania anomalii
Dirty Reads

Mamy z nią do czynienia wtedy, gdy następuje w danej transakcji A odczyt zmodyfikowanych w transakcji B danych, a transakcja ta (B) nie została jeszcze zatwierdzona.

Transakcja A rozpoczyna się, i wywołuje:

SELECT * FROM zamowienia

Transakcja B w tym samym czasie wykonuje:

UPDATE zamowienie
SET wartosc_zamowienia=100
WHERE nr_zamowienia=123

Istnieje możliwość, że w transakcji A zostanie odczytana nowa wartość pola wartosc_zamowienia, nawet jeżeli nie zostanie to zapytanie zatwierdzone.

Non-Repeatable Reads

Ze zdarzeniem takim mamy do czynienia wtedy, gdy zapytania A wykonane w różnych momentach jednej transakcji może zwrócić inne wyniki (to samo zapytanie nie daje tego samego rezultatu). Zdarzyć się tak może, gdy w trakcie działania transakcji dane zostaną zmodyfikowane przez inną operacje na bazie danych.

Transakcja A rozpoczyna się, i wywołuje:

SELECT * FROM zamowienia
WHERE nr_zamowienia=123

Transakcja B w tym samym czasie wykonuje:

UPDATE zamowienie
SET wartosc_zamowienia=100
WHERE nr_zamowienia=123;

COMMIT;

Wykonanie ponowne zapytania w transakcji A spowoduje, że zostanie tym razem zwrócony zmodyfikowany rekord.

Phantom Reads

Z taką sytuacją mamy do czynienia wtedy, gdy transakcja A odczytuje dane z bazy danych, w trakcie jej trwanie transakcja B umieści w bazie danych rekord, który spełnia warunki zapytania z transakcji A. Jeżeli teraz w transakcji ponownie zostanie wykonane zapytanie, nowy rekord także zostanie zwrócony, co powoduje niezgodność wyniku działania dwóch zapytań w ramach tej samej transakcji.

Transakcja A odczytuje dane:

SELECT * FROM zamowienia
WHERE nr_zamowienia > 123

Transakcja B wstawia nowy wiersz do tabeli:

INSERT INTO zamowienia
(nr_zamowienia, nazwa)
VALUES ('140', 'Babol złapany');

COMMIT;

Jeżeli teraz w transakcji A ponownie wykonamy zapytanie, to nowy rekord także zostanie pobrany.

Poziomy transakcji

Rozróżniane są następujące poziomy transakcji:

  • TRANSACTION_READ_UNCOMMITTED

    Brak izolacji. Wszelkie zmiany, także te które nie są zatwierdzone jeszcze, są widoczne dla wszystkich zapytań w bazie danych.

  • TRANSACTION_READ_COMMITTED

    Minimalna izolacja, transakcje widzą tylko takie dane, które już są zatwierdzone i zapisane w bazie danych.

  • TRANSACTION_REPEATABLE_READ

    Poziom ten zapewnia powtarzalność odczytu danych. Jeżeli jakiś rekord zostanie odczytany, to nawet jego zatwierdzona modyfikacja w innej transakcji nie zmieni jego wartości przy ponownym odczycie.

  • TRANSACTION_SERIALIZABLE

    Najwyższy poziom transakcji, zwany szeregowym. Zapewnia on najlepszą izolację poszczególnych transakcji, które nie widzą swoich wzajemnych działań i nie wpływają na siebie. W momencie rozpoczęcia transakcji, stan bazy danych jest „zamrażany” i tylko na takim stanie transakcja może działać.

Lista anomalii jakie występują przy określonych typach transakcji, w zależności od sposobu blokowania danych:
Nazwa transakcji Blokada tabeli Blokada wiersza Wydajność
TRANSACTION_READ_UNCOMMITTED Możliwe: dirty reads, non-repeatable reads, phantom reads Możliwe: dirty reads, non-repeatable reads, phantom reads najszybsza
TRANSACTION_READ_COMMITTED Możliwe: non-repeatable reads i phantom reads Możliwe: non-repeatable reads i phantom reads szybka
TRANSACTION_REPEATABLE_READ Ponieważ blokowana jest cała tabela, to phantom reads nie są możliwe Możliwe są phantom reads średnia
TRANSACTION_SERIALIZABLE Brak anomalii Brak anomalii wolna

Źródła

Tags: , , , ,

Wielkość liter w nazwach tabel w MySQL

Mar 11

Posted by Łukasz Stelmach in Bazy danych | 1 Comment

Baza danych MySQL na Linuksach jest wrażliwa na wielkość znaków w nazwach tabel. Czyli dwa takie zapytania:

1
2
3
SELECT FROM tabela;

SELECT FROM TABELA;

Może się okazać, że wykonanie jednego z nich spowoduje wyrzucenie komunikatu, mówiącego że podana tabela nie istnieje.

Co można zrobić w takiej sytuacji:

  1. Zmodyfikować aplikację, tak aby odwoływała się do tabel tak, jak są nazywane w bazie danych.
    Fajne, ale raz dużo pracy, dwa nie zawsze mamy kody źródłowe, trzy nie chcemy nikomu za to płacić.
  2. Zmodyfikować konfigurację serwera bazy danych oraz bazę danych
    Łatwiejsze niż modyfikacja kodu źródłowego, ale dotyczyć będzie wszystkich baz danych oraz aplikacji z niej korzystających.

Jak zmodyfikować konfigurację serwera aby nie było problemów z wielkością znaków w tabelach?

  1. Zmiana wielkości znaków w tabelach
    Pierwszym krokiem jest zmiana wielkości znaków nazw tabel we wszystkich bazach danych na małe litery. Pomocny może być ten skrypt, produkujący odpowiednie zapytania, które należy następnie wykonać (autor Anders Eriksson):

    SELECT CONCAT('rename table ', TABLE_NAME, ' to ' , LOWER(TABLE_NAME) , ';')
    FROM information_schema.`tables`
    WHERE table_schema = 'nazwa_bazy_danych';

    Wynik zapytania należy wykonać na bazie danych, spowoduje to zmianę nazw tabel na pisane tylko małymi znakami.

    Małe ostrzeżenie: Jeżeli w bazie danych istnieją dwie tak samo nazywające się tabele ale zapisane różną wielkością znaków, to MySQL zgłosi błąd podczas wykonywania powyższej operacji.

  2. Modyfikacja pliku konfiguracyjnego /etc/mysql/my.cnf
    Ostatnim krokiem jest odpowiednia konfiguracji bazy danych, tak aby zawsze już były używane małe litery do oznaczania tabel. Należy do pliku /etc/mysql/my.cnf, w sekcji mysqld dodać linię z parametrem lower_case_table_names

    31
    32
    [mysqld]
    lower_case_table_names=1

Od tej pory nie powinno już być problemów z różną wielkością znaków na nazwach tabel. Więcej informacji na temat tej opcji konfiguracyjnej można znaleźć na stronach MySQL.

Źródła

Tags: ,

Dodanie kolejnego lokalnego interfejsu sieciowego w Ubuntu/Debianie

Mar 8

Posted by Łukasz Stelmach in Debian/Ubuntu | Comments off

Dodanie kolejnego, lokalnego sieciowego w dystrybucjach wywodzących się z Debiana polega na modyfikacji pliku /etc/network/interfaces. Do pliku tego po prostu należy dodać wpisy opisujące kolejne interfejsy lokalne. Może to wyglądać tak:

1
2
3
4
5
6
7
8
# The loopback network interface
auto lo
iface lo inet loopback

auto lo:1
iface lo:1 inet static
        address 10.2.2.1
        netmask 255.255.255.0

W powyższym przykładzie w linii 5 następuje definicja nowego interfejsu sieciowego, o podanych adresach. Teraz wystarczy tylko wydać polecenie fup -a i nie zgłoszą się żadne błędy, powinien być dostępny kolejny interfejs sieciowy.

Tags: , , ,

Czym jest JBoss Operations Network (JON lub Jopr)?

Mar 8

Posted by Łukasz Stelmach in RHQ/JON | Comments off

JBoss Operations Network (JON) lub Jopr jest platformą, która dostarcza scentralizowany system pozwalający zarządzać produktami dostarczanymi w JBoss Enterprise Middleware. JON pozwala na następujące rzeczy:

  • Obsługa pełnego cyklu życia aplikacji, źródeł danych oraz usług powiadamiania.
  • Prezentacje wspólnego interfejsu pozwalającego przeglądać rożne komponenty całego środowiska (zarówno od strony sprzętowej jak i programistycznej).
  • Pozwala poprawić efektywność i niezawodność zarządzania i poprzez wpływa na dostępność oraz wydajność systemów produkcyjnych.
  • Pozwala na konfigurowanie i instalację nowych aplikacji w serwerze JBoss przy użyciu pojedynczego narzędzia.

Platforma dostarcza narzędzia do przeprowadzenia inwentaryzacji, administracji, monitoringu, instalacji oraz aktualizacji aplikacji bazujących na serwerze JBoss poprzez scentralizowany system. Pozwala na kontrolę poszczególnych poziomów dostępu umożliwiających przeglądanie, dostęp, zarządzanie systemami oraz dzielnie się informacjami czy też statystykami poprzez różne zespoły.

Związek pomiędzy JON a RHQ Network

Projekt RHQ jest systemem dostarczającym platformę pod budowę systemu zarządzającego wieloma produktami i platformami, z głównymi cechami takimi jak:

  • monitorowanie oraz wizualizacja wskaźników
  • alarmy wywoływane w przypadku błędów czy też innych warunków
  • zdalna konfiguracja zarządzanych zasobów
  • zdalne wykonywane operacji

RHQ został opublikowany głównie w oparciu o licencję GPL, ale część fragmentu jest indywidualnie licencjonowana na licencjach GPL/LGPL. Projekt ten jest podstawą dla budowy JON czy też Jopr.

Różnica pomiędzy JON a Jopr

W jednym zdaniu: JON to specyficzna wersja Jopra, która została odpowiednio przetestowana, oraz na którą są świadczone usługi wsparcia.

Podstawowe moduły

Inwentaryzacja

Moduł ten pozwala na przeprowadzenie automatycznego wykrywania poszczególnych zasobów oraz pozwala na ich szybką i łatwą konfigurację.Gromadzone są m.in. informacje dotyczące momentu instalacji usługi lub aplikacji, wersji oraz są dostępne informacje o historii danego zasobu. Taki model pozwala na śledzenie poszczególnych maszyn wraz z systemami operacyjnymi, źródeł danych, usług przesyłających wiadomości, procesów uruchomionych na maszynie, takich jak JBoss AS, Apache HTTP Server oraz informacji o poszczególnych aplikacjach uruchomionych w ramach serwera aplikacji JBoss.

Administracja

Aktualna konfiguracja każdego serwera jest przechowywana w centralnej bazie danych. Mogą istnieć konfiguracje w niej także zapisane różne przeszłe konfiguracje pozwalające na prezentowanie danych historycznych. Odpowiedni interfejs webowy pozwala na modyfikowanie parametrów poszczególnych usług, jeżeli posługują się one plikami tekstowymi. Dostępne są podstawowe operacje kontroli poszczególnych usług takie jak możliwość ich uruchomienia, zatrzymania i restartu.

Monitorowanie

Monitorowanie wykonania aplikacji odbywa się na wielu poziomach tak, aby umożliwić zebranie dokładnych statystyk oraz ich zachowań. Rozszerzone statystyki są dostępna dla serwera aplikacji JBoss AS oraz różnych komponentów wchodzących w skład produktów z rodziny JBoss Middleware, m.in. Hibernate, Apache Web Server, rożne systemy operacyjne takie jak Windows, Linux czy Solaris. Mogą zostać zdefiniowane odpowiednie alarmy, które umożliwiają pilnowanie konkretnych zdarzeń mających miejsce w systemie.

Aplikacje

Istnieje zarządca łatek na aplikacji, który umożliwia automatyczne ich przeglądanie instalowanie. Historia wszelkich zmian jest także zapamiętywana i możliwa do przeglądania.

Architektura

Platforma JBoss Operations Network składa się z centralnego systemu zarządzającego oraz ze zdalnych agentów, instalowanych na monitorowanych maszynach. Zadaniem agentów jest dostarczanie pewnych oraz szczegółowych informacji o monitorowanych zasobach. Komunikują się oni z centralnymi serwerami synchronizując zbierane informacje. Jest dostępny otwarty system tworzenia plug-inów, dzięki czemu istnieje możliwość dodania monitoringu nawet do własnościowych czy specyficznych aplikacji.Agenci są w miarę potrzeby samodzielni, potrafią działaś także w monecie, gdy główne serwery nie są dostępne.

Źródła

Tags: , , , ,