Category Archives: Eclipse

Działający przykład JEE w akcji

Jakoś tak się złożyło, że poza servletami i JPA niespecjalnie miałem w życiu pobawić się w EJB i insze wynalazki. Fakt, że pojawił się kiedyś dawno Spring skutecznie zniechęcał do posiłkowania się JEE w codziennym developmencie. Jednakże sytuacja zmieniła się wraz z wydaniem wersji 6 Javy EE.

Szukając w sieci materiałów dla przygotowań do certyfikatu Java Persistence API Developer Certified Expert (tak tak, pierwsze wpisy z przygotowań już niedługo) znalazłem dość ciekawy tutorial, który umożliwia postawienie w pełni funkcjonalnej aplikacji, na której możnaby przećwiczyć mniej i bardziej zaawansowane tematy związane z tą certyfikacją.

JBoss to nazwa budząca respekt. Jako firma oferuje szeroki wachlarz produktów – począwszy od serwera aplikacyjnego skończywszy na IDE. Oferuje również strasznie fajny tutorial znajdujący się  dokładnie pod tym adresem. Obejmuje on instalację dedykowanego IDE oraz przedstawia JEE w akcji – mamy i usługi sieciowe, mamy JSF, mamy też podpięte Hibernate jako ORM. Nic tylko brać i działać. Jeśli ktoś potrzebuje zobaczyć jak może wyglądać sensowna appka bez miliona zależności w POMie to powyższy adres jest świetnym punktem wyjścia.

SVN w Debianie bo ile można nosić kod ze sobą

Posiadanie własnego serwera daje szereg możliwości. Jedną z nich jest jedno miejsce ze wszystkimi usługami, do którego możemy dostać się zewsząd. W przypadku programisty to chyba jego kod jest najbardziej pożądanym dobrem – zatem jego dostępność jest sprawą nie do przecenienia.

By nie komplikować za bardzo postanowiłem postawić repozytorium SVN – bardzo popularnego systemu kontroli wersji, dobrze obsługiwanego zarówno pod Windowsem jak i linuxem. W związku z tym, iż pracuję na tych dwóch systemach możliwość łatwej obsługi jest dla mnie szczególnie istotna. Zatem w konsoli klepiemy:

sudo apt-get install subversion

I po chwili możemy cieszyć się naszym systemem kontroli wersji. Dostęp do niego zapewnimy sobie przez natywny protokół SVN. Teraz musimy umieścić gdzieś nowe zupełnie repozytorium, a także nadać prawa do korzystania z niego. W sumie jestem jedynym użytkownikiem serwera, zatem mógłbym zainstalować repozytorium w swoim katalogu domowym. Jednakże nie jest to dobre rozwiązanie – bezpieczniej byłoby stworzyć oddzielnego użytkownika tylko dla dostępu do repozytorium. Bezpieczniej i w sumie wygodniej. Lecimy zatem:

adduser svn

Automatycznie jest tworzony użytkownik oraz grupa o takiej samej nazwie. Repozytorium zainstalujemy w katalogu domowym usera svn, jednakże to za chwilkę. Należy zastanowić się nad dość istotną rzeczą. Otóż póki co zamierzamy wysłać do repozytorium kod źródłowy, który znajduje się na razie na moim dysku twardym. Czyli nie jest to plik WAR, ani nawet rozpakowane na serwerze pliki – muskmy wrzucić całość projektu Netbeans, który mamy u nas na serwerze. Zasadniczo byłoby najwygodniej po prostu przekopiować zawartość katalogu z projektem na serwer, ale trochę to takie… nieeleganckie 🙂 Zresztą jak się okazuje, nasze IDE z taką sytuacją upora się dość szybko i łatwo.

W katalogu usera svn tworzymy katalog, w którym będziemy trzymać nasz kod.


mkdir repos
cd repos
mkdir programbash
svnadmin create /home/svn/repos/programbash

Rzecz jasna najlepiej tego typu zabiegi dokonywać kiedy jesteśmy zalogowani jako użytkownik user. W przeciwnym razie czeka nas rekursywne nadanie uprawnień do katalogu repos/programbash właśnie temu użytkownikowi. Kiedy mamy katalog, który docelowo ma trzymać nasze (tutaj konkretne dla projektu) repozytorium należałoby je skonfigurować. Przechodzimy do naszego utworzonego repozytorium i zaglądamy do katalogu conf. Należy poddać edycji plik conf/svnserver.conf:

anon-access = none # tylko zalogowani userzy moga laczyc sie z repo
auth-access = write # userzy moga szalec
password-db = passwd # czyli dostep dla par user-haslo

Zgodnie z ostatnim zapisem w tym pliku poddajemy teraz edycji plik passwd w tym samym katalogu:

[svn] = [nasze_tajne_haslo]

I tyle konfiguracji. Należy omówić teraz budowę repozytorium – głównym jego katalogiem jest trunk, gdzie leży główna część naszego kodu. Do tego elementami repozytorium SVN są katalogi branches oraz tags. Przynajmniej taką strukturę zaleca nam dokumentacja SVNa i akurat tutaj zgódźmy się na takie rozwiązanie. Jednakże katalogi te nie są tworzone automatycznie przez SVNa zatem musimy dodać je sami. By to osiągnąć należy przejść do katalogu /tmp (wybrałem go tylko dlatego, że na pewno jest tam dostęp i potem będziemy mogli jego zawartość wyczyścić) i wydać takie polecenie:

svn co file:///home/svn/repos/programbash

I powinniśmy otrzymać następujący komunikat:

Checked out revision 0.

Konkretnie w tej chwili stworzyliśmy obraz repozytorium w wybranej przez nas lokalizacji. Dzięki temu na spokojnie dodamy wskazane katalogi:

mkdir trunk
mkdir tags
mkdir branches
svn add trunk
svn add tags
svn add branches

W ten sposób utworzone katalogi zostały wybrane do włączenia ich do systemu kontroli wersji. Teraz wypadałoby je do niego wysłać:

svn commit -m "Pierwszy commit - dodanie katalogow repozytorium"

I możemy sobie obejrzeć efekt:

Adding branches
Adding tags
Adding trunkCommitted revision 1.

Nasz pierwszy commit zakończył się powodzeniem (katalog w /tmp możemy usunąć). W naszym repozytorium istnieje już odpowiednia struktura katalogów i czeka na wypełnienie treścią. By to osiągnąć musimy udostępnić nasze repozytorium na zewnątrz. Istnieje kilka możliwości – udostępnianie poprzez protokół HTTP (do tego potrzebne jest dokonfigurowanie serwera WWW), posługiwanie się protokołem SSH (również konfiguracja), albo też natywnym protokołem dla SVN i to rozwiązanie zastosujemy. Za komunikację po ww. protokole odpowiada demon (program może być uruchomiony jako demon) o nazwie svnserve. Jest on automatycznie instalowany wraz z SVN, zatem nie trzeba instalować nic dodatkowego. Demon ten nasłuchuje domyślnie na porcie 3690. Uruchamiamy go w ten sposób:

svnserve -d -r /home/svn/repos

Wskazujemy, że działamy jako demon (-d), a także wskazujemy na roboczy katalog. Dzięki wskazaniu na repos nasz demon obsłuży wszystkie repozytoria jakie kiedykolwiek przyjdzie nam do głowy dodać. Rzecz jasna przydałoby się dodać uruchamianie tego demona przy starcie systemu poprzez edycję skryptów startowych. Na razie jednakże skupmy się na zaimportowaniu plików do repozytorium. Uruchamiamy Netbeans (zakładam, że pluginy do obsługi SVN zostały zainstalowane) i klikamy prawym przyciskiem myszy na projekcie, który zamierzamy wysłać do repozytorium, po czym wybieramy Versioning -> Import into Subversion repository tak jak poniżej:

W pojawiąjacym się okienku wpisujemy:

svn://chlebik.pl/programbash/trunk

Wpisujemy też rzecz jasna użytkownika i hasło po czym klikamy na Next i następuje (powinno 🙂 połączenie z serwerem. Przy naszej strukturze repozytorium (każdy projekt będzie posiadał oddzielny katalog) katalog trunk jest głównym, zatem to właśnie jego wskazujemy jako cel importu. Musimy również wpisać komunikat związany z tym importem i klikamy Next.

Po chwili powinniśmy zobaczyć taki ekran:

I ostatecznie nacisnąć na przycisk Finish. Akurat Programbash trochę waży, zatem w zależności od szybkości łącza internetowego wysłanie wszystkich plików na serwer może trochę potrwać. Ostatecznie w zakładce Output otrzymałem taki komunikat:

Transmitting file data ...
Committed revision 2.
update D:/Java/programbash2 -r HEAD --depth=files --force
At revision 2.
==[IDE]== 2010-02-15 01:14:21 Committing... finished.

Czyli zasadniczo wszystko OK. Sprawdźmy czy wszystko jest na pewno w porządku. Użyłem do tego Eclipse, aby nie mieszać w Netbeans. Odpalamy IDE, tworzymy nowy projekt, wybieramy jako typ SVN -> Checkout project , dodajemy nową lokację repozytorium, podajemy stosowne dane i Eclipse uruchamia kreatora projektu. Zakładam rzecz jasna, że nasz Eclipse posiada plugin do obsługi SVNa – polecam Subclipse. U mnie projekt zaimportował się bez najmniejszych przeszkód i tym samym dowiodłem, że repozytorium działa 🙂

Rzecz na koniec dość istotna – do repozytorium dodałem z premedytacją pliki projektu Netbeans. Standardowo nie robi się tego w ten sposób – jakiekolwiek szczegóły deploymentu aplikacji powinny zostać pominięte w repozytorium. Dzięki temu nie śmiecimy w nim plikami potencjalnie różnymi u każdego programisty. Jednakże zasady tutaj panujące powinny być uzgodnione przez użytkowników repozytorium. W tym przypadku ja będę jedynym, zatem pozwoliłem sobie na taką małą frywolność 🙂

Swinguj z nami czyli piszemy aplikację cz.2

Po kilku miesiącach od pierwszego wydania przyszła kolej na krok dalej – oto druga wersja klienta do gry w Arkadię, opartego na Swingu i mojej niedostatecznej znajomości Javy 🙂

Przyznaję, że wydanie to mogłoby pojawić się wcześniej. Jednakże wpierw mały romans z JEE, a potem wypadki losowe odwlekły ten fakt w czasie. Przez kilkanaście ostatnich dni przysiadłem fałdów i oto jest – druga wersja ChlebikClient. Wiele jeszcze jej brakuje do optymalnego funkcjonowania jako wymarzony klient, jednakże widać już pewne zarysy jak mogłaby wyglądać taka aplikacja, kiedy bierze się za nią newbies. Jednakże postanowiłem, że wydanie drugie będzie również i ostatnim – gdyż kolejne wydania byłyby po prostu dokładaniem bardzo podobnych do obecnych cegiełek. Czyli kolejny JInternalFrame, kolejny plik XMLa i tak dalej – ani to wiele już nie rozwija, a i sensowności dalszej w tym nie ma zbyt wiele.

Popracowałem z NetBeansem używając jego pomocy do tworzenia GUI, mam mniej więcej pojęcie o wątkach aplikacji pisanej w Swingu (choć i tak niewiele jak znam życie), operowanie podstawowe na plikach XML, poszczególne komponenty też obejrzałem sobie z kilku stron. Na dzień dzisiejszy dalsze prace zostają wstrzymane i odłożone na czasy obfitujące w wolny czas (może kiedyś nadejdą). Póki co zapraszam na podstronę projektu, gdzie można przeczytać listę zmian oraz ściągnąć najnowszą wersję.

Co zaś do przyszłości – zmierzam w kierunku JEE. Dla nauki rozpoczynam pisanie aplikacji internetowej. Wstępnie technologie użyte to JSP, Hibernate/JDBC, wszystko zapakowane w Tomcata. Być może tym razem spróbuję użyć do pracy Eclipse’a wraz z jego rozszerzeniem WTP.

W końcu dobra książka

Ano to prawda. Nareszcie w Polsce ukazała się pozycja, która nie jest głębokim opisem języka, ale też nie jest szczegółowym opisem jednej z dostępnych technologii. Mowa o “Eclipse Web Tools Platform”, którą to dziś przez zupełny przypadek znalazłem w Empiku. Zdziwienie moje było tym większe, iż z ofertą wydawnictwa Helion staram się być w miarę na bieżąco, a o tej pozycji jakoś nic nie wiedziałem. Powód mej niewiedzy był prozaiczny – ktoś tę cenną pozycję wrzucił do działu ‘JavaScript’… Pozostawię bez komentarza.

No ale do rzeczy. Książka kosztuje jak typowa pozycja dotycząca Javy, czyli sporo (okrągłe 99 zł). Ale już po pobieżnym przejrzeniu wiedziałem, że na pewno nie będzie to chybiona inwestycja. O czym traktuje ta książeczka? Ano kilka osób tworzących WTP, czyli rozszerzenie Eclipse’a wspomagające budowanie aplikacji webowych i EE, wzięło się za napisanie na ten temat książki. I trafili w dziesiątkę (przynajmniej według mnie), gdyż do tej pory w naszym kraju nie było równie fajnej pozycji, która pokazywałaby proces tworzenia aplikacji tego typu od podstaw i z użyciem konkretnego narzędzia. Co więcej – poruszone są wszystkie zagadnienia szeroko pojętego J2EE – servlety, bazy, XML, webservices. Cud, miód i orzeszki. Wracam do lektury – mam nadzieję, że zaowocuje ona kilkoma wpisami na blogu.

Java Server Pages i servletowe podwórko

Wspomniałem już przy okazji poprzedniego wpisu o serwletach oraz o technologii Java Server Pages. W dużym skrócie – serwlety to po prostu aplikacje Javy wykonywane po stronie serwera, zaś JSP to technologia umożliwiająca dynamiczne generowanie dokumentów (X)HTML poprzez osadzenie w kodzie HTMLa wstawek z języka Java (za Wikipedią). Dodatkowo rzecz z automatu jest realizowana we wzorcu MVC (Model-View-Controller), co można ostatecznie podsumować stwierdzeniem, że mamy bardzo przyjemne narzędzie do tworzenia aplikacji internetowych.

Dlaczego o tym piszę? Albowiem jako programista PHP pracujący nad projektami o bardzo pojemnej nazwie ‘webdevelopment’ automatycznie kieruję się w stronę znanych mi rozwiązań, a za takowe JSP (i potem Java Server Faces – to framework) można uznać. Jednoczesne poznawanie Javy (za pomocą Bruce’a Eckela i jego ‘Thinking in Java’) oraz JSP (książka ‘Head First JSP’) póki co okazało się dość obiecującym rozwiązaniem, gdyż zamiast klepać standardowe do bólu System.out.println i zachwycać się rozbudowaną konwersacją z konsolą, można tworzyć kod wypełniając znany sobie szkielet aplikacji (np. tworząc system blogowy).

Do rozpoczęcia zabawy z JSP potrzebujemy jednej rzeczy – kontenera na serwlety. Rolę tę pełni świetnie Apache, kiedy doinstaluje się do niego odpowiedni moduł, albo też kiedy zainstaluje się Apache Tomcat jako samodzielny serwer (www + jsp w jednym). Zasadniczo wyszedłem od tej koncepcji (czy wspominałem już, że jestem leniwy jeśli chodzi o babranie się z administracją?), a następnie spróbowałem jakoś to wrzucić (pluginem oczywiście) pod Eclipse’a. Po strawieniu 3h nad konfigiem oraz próbą zmuszenia tej aplikacji by w końcu zobaczyła mój plugin do Tomcata dałem za wygraną i postanowiłem ściągnąć NetBeans. Downloaded, zainstaluj, uruchom, ściągnij update i viola!!! Nagle okazało się, że wystarczy stworzyć nowy projekt i nacisnąć ‘Build all’ – wszystko pięknie śmiga. Jako, że była gdzieś 3 nad ranem porzuciłem zabawę, ale wróciłem do niej zaraz następnego dnia.

NetBeans ma to do siebie, że można go ściągnąć w kilku wersjach. Bardzo ważne jest to, że możemy również wybrać wersję niejako ‘out of the box’, gdyż razem z IDE dostarczany jest też Tomcat oraz GlassFish (to serwer aplikacji J2EE firmy Sun). Po zainstalowaniu otrzymujemy (pod Windowsem oczywiście) w pełni skonfigurowane narzędzie. Tutaj właśnie uwaga – opiszę co i jak by skonfigurować pierwszy projekt i uruchomić go. W książce ‘Head First JSP’ przedstawiono podział na 2 środowiska – developerskie oraz aplikacyjne (czyli produkcyjne). Jest to rozwiązanie poniekąd słuszne, jednakże na czas nauki, kiedy człowiek musi przypominać sobie czasem składnię podstawowych funkcji, jakoś nie widzę ku temu sensu.

W NetBeans zatem skonfigurujemy projekt tak, aby dało się w obrębie jednego katalogu jednocześnie posiadać kod źródłowy, jak i widzieć go (po kompilacji oczywiście) z poziomu przeglądarki. Oto co trzeba zrobić:

1. Okienko z projektami -> prawy przycisk myszy i oczywiście New Project
2. Pokazuje się lista do wyboru, nas interesuje Web, a potem Web Application
3. Nadajemy projektowi nazwę, NetBeans automatycznie poda domyślną ścieżkę do niego (czyli katalog webapps w katalogu gdzie zainstalowano Tomcata).
4. Pojawią się informacje o używanej wersji serwera i takich tam – wybieramy oczywiście to, co zainstalowane (najprawdopodobniej Tomcat 6.0, Java EE 5).
5. W następnym kroku mamy możliwość wyboru używanego frameworka. Jako, że nic takiego na razie nie ma miejsca, to klikamy Finish i mamy gotowy szkielet projektu.

By przetestować działanie całości należy prawym przyciskiem myszy kliknąć na nasz projekt (w okienku projektów) i wybrać Build. NetBeans nam pokompiluje co trzeba i następnie znowu pod prawym przyciskiem wybieramy Run i po paru sekundach mielenia otwiera się nam przeglądarka i pojawia się śliczne ‘Hello wordl!’ (adres to http://localhost:8084/TWOJANAZWAAPLIKACJI/).

Teraz kiedy już mamy działający projekt trzeba objaśnić trochę strukturę katalogów. Różni się ona od przyjętej w ‘Head First’, zatem dla jasności napiszę co i gdzie. Struktura katalogów w folderze naszej aplikacji wygląda tak:

1. Katalog nbproject to internalsy NetBeans i nie należy tego na razie dotykać.
2. Podobnie rzecz ma się ze znajdującym się w katalogu aplikacji plikiem build.xml oraz katalogiem dist – to informacje na temat sposobu budowania projektu, a w katalogu z kolei umieszcza się ostatecznie przygotowaną paczkę z kodem (w formie pliku *.war).
3. Katalog test służy zgodnie z nazwą do testów (testów jednostkowych opartych na JUnit)
4. W katalogu build zgodnie z nazwą budowany jest cała aplikacja
5. W katalog src znajduje się nasz kod źródłowy
6. I na sam koniec w folderze web znajdują się nasze pliki *.jsp i *.html (wraz z plikiem web.xml).

Oczywiście normalnie nikt nie będzie grzebał bezpośrednio w plikach w tym folderze – od tego jest IDE. Jednakże dobrze wiedzieć co i z czym, zwłaszcza dla początkujących informacja ta może być dość istotna. Nasz projekt póki co nie zawiera kodu Javy, ale jest w pełni gotowy na jego przyjęcie. Na razie rzut oka na okienko IDE:

Aplikacja na razie jest dla nas interesująca w dwóch miejscach. Pierwszym z nich jest katalog Source Packages. Tutaj należy dodawać kolejne pakiety, a w nich klasy (np. com.wordpress.chlebik.TestowaKlasa.java). Umieszczone tutaj zostaną w procesie budowania projektu skompilowane i przerobione na postać strawną dla serwera. Drugim ważnym katalogiem jest katalog web, gdzie znajduje się cały HTMLowy lub JSPowy kod. Dla przykładu – znajdź w tymże folderze plik index.jsp i zmień jego nazwę na np. index2.jsp. Teraz w przeglądarkę wrzuć adres http://localhost:8084/WebApplication1/. I co? Ano nic, błąd. Ale z kolei wpisanie http://localhost:8084/WebApplication1/index2.jsp już jak najbardziej działa. Na prostym przykładzie widać, co gdzie i z czym jeśli chodzi o HTML i JSP. W katalogu tym można również odnaleźć podkatalog WEB-INF gdzie znajduje się plik web.xml, który służy do (powiedzmy uogólniając) kierowania routingiem w naszej aplikacji. Jednakże to uczący się JSP już raczej wiedzą i nie potrzeba tego tematu rozwijać.

Mam nadzieję, że to krótkie i pewnie trochę chaotyczne wypociny jednakże komuś pomogą, a i może skłonią do sięgnięcia po NetBeans.