Gdy piszemy aplikację, która korzysta ze sprawdzonych bibliotek, które do logowania wykorzystują log4j’a, możemy chcieć odpuścić sobie logowanie informacji z klas znajdujących się w wybranych pakietach tychże bibliotek. Poniższy kod przedstawia klasę filtru, który pozwala włączyć lub wyłączyć logowanie informacji z wybranego pakietu i całej jego podrzędnej struktury.

Poniżej zamieszczam kod konfigurujący bibliotekę log4j, który po zamieszczeniu w naszej aplikacji spowoduje, że nie będziemy już potrzebowali pliku konfiguracyjnego log4j.configuration, czy też log4j.xml. Dodatkową korzyścią jest fakt, że po niewielkich zmianach będziemy mogli z poziomu naszej aplikacji dostosowywać na bieżąco mechanizm logowania do aktualnych potrzeb, np: rozszerzając lub zawężając zakres logowanych informacji, czy też dodając nowe lub usuwając aktualnie niepotrzebne appender’y.

Dobry dekompilator, to narzędzie, które docenia zapewne każdy programista, nie tylko Javy. Ważnym tu jednak jest nacisk na słowo kluczowe „dobry”.

Services (ang. usługi) jest to mechanizm wbudowany w środowisko Java, umożliwiający tworzenie aplikacji rozszerzalnych o dodatkowe funkcje dostarczane za pomocą plug-in’ów, zwanych też wtyczkami.

Zanim przejdę do przykładowej implementacji, pozwolę sobie odnieść się do oryginalnego dokumentu, w którym omawiany jest mechanizm działania services, a który możemy znaleźć na stronach Sun’a.

Zdarza się czasem, że przydałoby się wyciągnąć z jar’a jakiejś biblioteki informacje na przykład o numerze jej wersji lub jej dostawcy. O ile dostanie się do pliku manifestu (/META-INF/MANIFEST.MF) z poziomu Javy nie powinno stanowić problemu, to wyciągnięcie jakichkolwiek informacji z poziomu Ant’a nie wydaje się już takie oczywiste.

Gdy ostatecznie zdecydowałem, że to WP będzie platformą, na bazie której zbuduję swoją stronę, wpadło mi do głowy, że poza funkcjonalnością CMS’a, równie ważne jest też jego bezpieczeństwo. Zrobiłem zatem małe rozpoznanie w tym temacie, a wnioski do jakich doszedłem postaram się streścić poniżej. Jednak, aby nie była to czcza paplanina, przedstawię na praktycznym przykładzie, jak można zabezpieczyć (mam nadzieję w miarę skutecznie) instancję WordPress’a już od pierwszych chwil jej życia.

SSL, jak zapewne wiecie (a jeśli nie wiecie, to zapraszam na Google), służy do zabezpieczenia strony internetowej przed podsłuchiwaniem przesyłanych poprzez nią danych, jak również umożliwia ochronę przed oszustami próbującymi podszyć się pod nasz serwis, pod warunkiem, że nasi odwiedzający wiedzą, że strona nasza zabezpieczona jest certyfikatem i za każdym razem, gdy na nią wchodzą, sprawdzają, czy informacje o takim certyfikacie wyświetlają się w okolicach paska adresu przeglądarki internetowej (np: tak jak na stronach banków). Sam korzystam z certyfikatu SSL, do zabezpieczenia strony logowania i panelu administracyjnego tego blog’a.

Zdarzyło się kilka razy, że potrzebowałem takiej właśnie funkcjonalności. Niestety, nie znalazłem nigdzie żadnego sensownego gotowca, więc ostatecznie sam napisałem taką oto prostą klasę narzędziową. Jest ona zależna od biblioteki commons-lang, jednak przy odrobinie chęci można się tejże zależności bez problemu pozbyć.

Programming Mistake Detector jest jednym z wielu proponowanych rozwinięć skrótu PMD, ale według mnie właśnie to rozwinięcie najdokładniej opisuje przeznaczenie opisywanej biblioteki.

PMD jest narzędziem, którego zadaniem jest znajdowanie w kodzie źródłowym potencjalnych błędów, takich jak puste bloki try/catch/finally, niewykorzystywane fragmenty kodu, nieoptymalne wykorzystanie klas String i StringBuffer, niepotrzebne użycie bloków if w pętlach, które można zamienić na pętle while oraz wykrywanie duplikatów bloków kodu.

Poniżej załączam przykłady konfiguracji log4j’a, które wykorzystuje w kilku projektach.

Obfuskacja, jak możemy przeczytać na Wikipedii, to “technika przekształcania programów, która zachowuje ich semantykę, ale znacząco utrudnia zrozumienie.”. Polega ona na takim przetworzeniu kodu lub binariów aplikacji, aby uzyskany po dekompilacji kod był jak najbardziej nieczytelny dla osoby przeprowadzającej analizę działania programu z wykorzystaniem tak zwanej Inżynierii wstecznej.

Bawiąc się Swingiem od samego początku wydawało mi się, że aby prawidłowo zamknąć okno, wystarczy w akcji przycisku Zamknij wywołać:

1
2
3
private void closelButtonActionPerformed(java.awt.event.ActionEvent evt) {
    this.dispose();
}

Okazuje się jednak, że niekoniecznie jest to prawidłowe podejście, ponieważ jeśli wywołamy bezpośrednio dispose(), to nie zostaną poinformowane listenery okna oczekujące na zdarzenie zamykania okna. Co za tym idzie, zachowanie aplikacji będzie inne, niż w przypadku wciśnięcia przycisku X zamykającego okno. Zazwyczaj jednak chcemy zachować spójność działania aplikacji i obsługi zdarzeń.

Odkąd zacząłem pisać w Javie bardziej złożone aplikacje, które musiały na przykład komunikować się z jakimiś webowymi usługami lub wykonywać dłuższe obliczenia, miewałem problemy z zamarzającym GUI. Próbowałem problem ten rozwiązać na wiele sposobów, jednak zawsze znalazło się coś, co nie działało tak jak powinno - jak chociażby labele lub pola tekstowe, które powinny wyświetlać informacje o postępie zadania, a przez cały czas aż do zakończenia zadania pozostawały niezmienione.

No i stało się. W końcu dorobiłem się strony, czy też raczej bloga, na którym będę mógł się co nieco powymądrzać 😉 Wątkiem przewodnim większości tematów będzie zapewne programowanie w Javie i wszystko co się z nim wiąże. Jednak, mam nadzieję, że już w niedalekiej przyszłości pojawią się tu również jakieś tematy poświęcone paralotniarstwu, czy też graniu na gitarze.

Wierzę, że skoro już przeglądasz tę stronę, znajdziesz tu coś interesującego dla siebie.