M2_REPO

Od paru dni używam Eclipse'a Galileo. Po zainstalowaniu nowego środowiska lokalne repozytorium Mavena nie było widoczne przez Eclipse, dlatego należało ustawić zmienną środowiskową M2_REPO, która będzie wskazywała na fizyczną lokalizację repozytorium. W tym celu postanowiłem zmodyfikować plik .bashrc i dodać w nim M2_REPO, aby nie mieć problemów przy instalowaniu nowej wersji IDE. Zrobiłem restart Ubuntu (który okazało się, że nie był konieczny) i uruchomiłem ponownie Eclipse'a. Niestety IDE wciąż nie widziało bibliotek wskazanych w pom.xml czyli wynikało z tego, że zmienna M2_REPO nie jest widoczna. Trochę się zdziwiłem wykonałem w terminalu komendę printenv, która jawnie wskazywała, że zmienna została utworzona. Nie chciałem już więcej się zastanawiać i stworzyłem zmienną M2_REPO pod Eclipse. Wszystko zaczęło działać poprawnie. Nie mam jednak pojęcia dlaczego Eclipse zignorował zmienną z .bashrc? Czyżby plik ten był wyłącznie uruchamiany kiedy odpalam konsolę? To też nie ma dla mnie sensu, bo Eclipse uruchamiam ręcznie z terminala.

Tomcat, Maven i problem z aktualizacją CSS

Ostatnio zdarzało mi się popełniać krótsze posty. Mam nadzieję, że w niedługim czasie ulegnie to zmianie. Póki co za oknem pada deszcz i trzaskają pioruny. Mam nadzieję, że po tym pogodowym katharsis powietrze będzie rześkie.
No ale wróćmy do tematu... Moją ostatnią aplikację webową deployuję pod Tomcata za pomocą Mavena i ogólnie sobie to chwalę, gdyby jeszcze nie fakt, że deployment w Javie trochę trwa. Przy mojej aplikacji i na moim sprzęcie średnio trwa to około minutę. Zauważyłem też dziwną rzecz. Dwukrotnie zdarzyło mi się, że po redeploymencie (mvn clean tomcat:redeploy) zminay w CSS nie były aktualizowane. Można to było łatwo sprawdzić za pomocą Firebuga i sprawdzenie treści pliku css. Wszelkie próby restartu kontenera servletów nie pomagały. Wiedziałem, że od strony aplikacji wszystko wygląda ok, ale problem wciąż pozostawał. Metodą prób i błędów udało mi się znaleźć pewne rozwiązanie, a wygląda ono następująco:

1. Uruchom Tomcata
2. Undeployuj aplikację: mvn tomcat:undeploy
3. Zamknij Tomcata
4. Uruchom ponownie Tomcata
5. Ponownie zdeployuj aplikację mvn clean tomcat:deploy

Teraz powinno wszystko poprawnie działać. Nie wiem czy wina leży tu po stronie Tomcata czy może plugin dla Mavena ma jakiś błąd. W każdym razie ta sekwencja czynności powoduje, że wszystko znowu poprawnie działa.

To na dzisiaj byłoby tyle. Czeka mnie jeszcze wieczorem podróż do Chojnic. Czas odwiedzić rodzinne strony. Bywajcie ;)

Żart branżowy

Nie mogłem się powstrzymać: PATRZEĆ TUTAJ!

ICEfaces i iframe

W celu użycia komponentu iframe wraz z ICEfaces należy w pliku konfiguracyjnym web.xml ustawić właściwość com.icesoft.faces.concurrentDOMViews wartością true.

Filtry, nulle i godziny przed komputerem

I żeby nie było niedomówień (tzn., żebym już nie zapomniał). Filtr jest zawsze wywoływany przed Faces Servletem. Dlatego próba wywołania z filtra metody FacesContext.getCurrentInstance(); zwróci nulla.

Problem z Modelowaniem Bazy Danych

Parę dni temu pobrałem sobie plugin do Eclipse'a UML2 Tools. Niestety narzędzie to nie posiada możliwości modelowania schematu bazy danych, dlatego postanowiłem zrobić to trochę naokoło i wykorzystać diagram klas (moja aplikacja używa Hibernate). Niestety po tygodniowej przerwie po wczytaniu diagramu okazało się, że część danych wyparowała (atrybuty, nazwy klas, etc.) i postanowiłemn zmienić narzędzie. Stąd moje pytanie czy ktoś z Was ma doświadczenie z jakimś darmowym narzędziem pod Linuxa do modelowania schematu bazy danych. Pisząc darmowym, mam tu na myśli zastosowania komercyjne.

Po Democampie

Jak pewnie wiecie w zeszły weekend wybrałem się na Democamp do Poznania. Początkowo planowałem wybrać się na całe dwa dni, ale doszedłem do wniosku, że najciekawsze dla mnie rzeczy będą w niedzielę. Chciałem się dokładnie dowiedzieć jaka jest formuła tego wydarzenia, a dokładniej chodziło mi o poznanie formy prezentacji poszczególnych startupów.

W tym roku obsada jury była międzynarodowa. W gronie oceniających pojawili się przedstawiciele firm typu Venture Capitals pragnących ewentualnie zainwestować w jakiś dobrze rokujący projekt.
Prezentacje startupów odbywały się w języku angielskim. Trwały one po 7 minut. Następnie jury zadawało pytania związane z planem biznesowym, aktualną dochodowością projektu i planach jego rozwoju. Możliwość zadawania pytań mieli również widzowie. Odbywało się to za pomocą Flakera. Powinienem również wspomnieć, że festiwal startupów ( ??? ) można było oglądać w czasie rzeczywistym poprzez Internet. Co się tyczy samych startupów, to były one dość zróżnicowane. Jest jednak pewna tendencja do powielania zachodnich pomysłów. BTW czy Polakom brakuje kreatywności?

Zdaniem jury jak i widzów zwycięzcą został projekt Erasumuse zaadresowany do studentów pragnących skorzystać z programu Socrates-Erasmus. W zamierzeniach ma on być jeśli dobrze rozumiem platformą (portalem społecznościowym) umożliwiającą zebranie wszystkich informacji przed planowanym wyjazdem na stypendium. Początkowo sceptycznie podchodziłem do tego pomysłu, ale jak się dłużej zastanowić to jeśli z portalu tego mieliby korzystać studenci z całej Europy to ma on predyspozycje do tego, aby odnieść sukces. Listę pozostałych nagrodzonych można zobaczyć na blogu Antyweb. Natomiast realcja w formie video znajduje się na blogu Mediafun Cafe

Jadę na Democamp

Właśnie zrobiłem rezerwacje na sobotnio-niedzielny Democamp odbywający się w Poznaniu. Tematyka startupów stała mi się ostatnio dość bliska, gdyż sam aktualnie pracuję nad jednym autorskim projektem. Kto wie, może któregoś dnia sam znajdę się po stronie prezentujących swój pomysł, więc póki co warto zobaczyć jak to robią inni zanim samemu przyjdzie stanąć przed publicznością. Jeśli kogoś ten temat zainteresował to polecam blog Antyweba oraz serwis Techcrunch. W przypadku, gdy samemu chce się śledzić pojawiające się polskie startupy to zapraszam na Startups.pl Informacje na temat prezentowanych witryn biorących udział w Democampie można znaleźć tutaj.

Spring Framework 3.0.0.M3 i Maven

Ostatnio zdarza mi się częściej używać Mavena, co jest generalnie ciekawym doświadczeniem, aczkolwiek czasami frustrującym. To ostatnie dopadło mnie przy próbie integracji ze Spring Framework. Na stronie projektu pokazany jest przykład integracji Springa z Mavenem. Repozytoria, z których można pobrać Springa są następujące:

  
   springsource-milestone
   http://repository.springsource.com/maven/bundles/milestone
  
  
   springsource-release
   http://repository.springsource.com/maven/bundles/release
  
  
   springsource-external
   http://repository.springsource.com/maven/bundles/snapshot
  

Przeglądać repozytoria można pod tym adresem. Teraz przyszedł czas, żeby zdefiniować zależności wskazujące na biblioteki jakich chcemy użyć w naszym projekcie. Tutaj mała wzmianka. Nazewnictwo artefaktów uległo zmianie w stosunku do poprzednich wydań Springa, więc migracja ze starszych wersji dla projektów używających Mavena może okazać się kłopotliwa.

    
        org.springframework
        org.springframework.core
        3.0.0.M3
  

Wydawać by się mogło, iż to już wystarczy. Niestety nie. Przy próbie ściągnięcia bibliotek okazuje się, że w repozytorium Springa nie ma wszystkich bibliotek, z których korzysta Spring. Prawdę mówiąc na tym etapie utknąłem. Na szczęście, ktoś wcześniej miał podobny problem i zasugerował dodanie repozytorium Atlassiana.

    
        atlassian-m2-repository
        https://m2proxy.atlassian.com/repository/public
    

Powyższe przygody sprawiają, że ciśnienie Ci wzrasta. Problem z zależnościami jest częstym przeżyciem dla użytkowników Mavena. Nie wiem do końca z czego to wynika? Czy problem leży po stronie twórców Mavena? Czy może ludzie, którzy umieszczają swoje biblioteki w publicznych repozytoriach nie zawsze dbają w należyty sposób o to, aby pobranie bibliotek odbywało się bezproblemowo?

Dołączenie źródeł do Eclipse'a za pomocą Mavena

Ciekawą cechą mavenowego pluginu dla eclipse'a jest możliwość dołączenia dokumentacji do używanych bibliotek. Odbywa się to w bardzo prosty sposób. Mając stworzony projekt przy użyciu Mavena w linii poleceń wpisujemy standardowe polecenie generujące niezbędne pliki potrzebne do rozpoznania naszego projektu przez Eclipse'a, ALE czynność tą popełniamy z dodatkowym parametrem:

mvn eclipse:eclipse -DdownloadSources=true

Prawie gotowe! Jeśli wcześniej mieliśmy otwarty owy projekt w Eclipsie, to wystarczy w Package Explorerze (czy też w Navigatorze) kliknąć na katalog z nazwą projektu i wcisnąć F5 w celu odświeżenia konfiguracji projektu. Od tego momentu cieszymy się możliwością przeglądania dokumentacji używanych bibliotek. Dzieje się tak po najechaniu myszką na nazwę klasy albo metody.

Załapałem się

Uff zdążyłem... Na blogu Grzegorza Dudy dowiedziałem się, że Atlassian zrobił promocję i umożliwił zakup rocznej licencji na JIRA i Confluence (po $5.00 za każdy produkt, co przy ASTRONOMICZNYCH cenach tych produktów wydaje się być okazją). Zakup licencji zawiera roczny maintence. Należy również wspomnieć, iż owa licencja obejmuje możliwość użytkowanie oprogramowania przez pięciu użytkowników, co w moim wypadku w zupełności wystarcza. Przy zakupie była opcja przedłużenia licencji na kolejne dwa lata co również uczyniłem. Szczerze mówiąc, jak zobaczyłem, że termin promocji upływa 24 kwietnia nie wgłębiałem się w warunki licencji tylko szybko zabierałem się za rejestrację, gdyż nie byłem pewien w obrębie jakiej strefy czasowej odbywa się owa promocja, a tu należy wspomnieć, że siedzibą Atlassiana jest Australia. W każdym razie udało się. :)

Pozdrawia szczęśliwy posiadacz JIRA i Confluence

Wielożeństwo czyli integracja Mavena z ICEfaces 1.8.0 i Tomahawk 1.1.8

Niedawno znalazłem się na zielonej trawce, więc jest trochę więcej czasu na rzeczy na które wcześniej go brakowało. Przy okazji pracy przy swoim prywatnym projekcie chciałbym zaprezentować integrację ICEfaces 1.8.0 z Tomahawk 1.1.8 przy użyciu Mavena. Jako kontenera serwletów użyę Tomcata 6.

Tak sie składa, że na dniach wyszła stabilna wersja ICEfaces w wersji 1.8.0. Jednakże o ile się nie mylę, to wciąż brakuje w niej gotowych walidatorów (np. e-maila, czy też porównania dwóch haseł przy ekranie z rejestracją). Te dobrodziejstwa są natomiast dostępne w Tomahawk. Niby są to małe rzeczy, ale po co się nadmiernie meczyć? Więc do roboty...

Ze strony ICEfaces pobieramy specjalną paczkę przeznaczoną dla Mavena i po rozpakowaniu kopiujemy ją do katalogu naszego lokalnego repozytorium. W moim Ubuntu jest to katalog .m2, który znajduje się w moim katalogu domowym natomiast dla systemu Windows będzie to C:\Documents and Settings\twójlogin\.m2\repository

Teraz esencja czyli pom.xml. Plik ten został stworzony na podstawie jednego z tutorialowych przykładów ICEfaces. Niestety nie może być zbyt pieknie. Owy pom trzeba w niektórych miejscach przeedytować, aby wszystko razem zgodnie współpracowało. Odpuszczę sobie zbędne gadulstwo, tylko zamieszczę poniżej końcową jego wersję:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>pl.syllepsa</groupId>
<artifactId>myapp</artifactId>
<packaging>war</packaging>
<version>1.0-SNAPSHOT</version>
<name>myapp Maven Webapp</name>
<url>http://maven.apache.org</url>
<build>
<finalName>myapp</finalName>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>tomcat-maven-plugin</artifactId>
<configuration>
<server>tomcat6</server>
</configuration>
</plugin>
</plugins>
</build>

<repositories>
<repository>
<id>jboss-maven-repository</id>
<url>http://repository.jboss.com/maven2</url>
</repository>
</repositories>


<dependencies>
<dependency>
<groupId>org.apache.myfaces.tomahawk</groupId>
<artifactId>tomahawk</artifactId>
<version>1.1.8</version>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.icefaces</groupId>
<artifactId>icefaces-comps</artifactId>
<version>1.8.0</version>
<scope>compile</scope>
<exclusions>
<exclusion>
<groupId>javax.el</groupId>
<artifactId>el-api</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.icefaces</groupId>
<artifactId>icefaces-facelets</artifactId>
<version>1.8.0</version>
<scope>compile</scope>
<exclusions>
<exclusion>
<groupId>javax.el</groupId>
<artifactId>el-api</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.icefaces</groupId>
<artifactId>icefaces</artifactId>
<version>1.8.0</version>
<scope>compile</scope>
<exclusions>
<exclusion>
<groupId>javax.el</groupId>
<artifactId>el-api</artifactId>
</exclusion>
<exclusion>
<artifactId>commons-logging-api</artifactId>
<groupId>commons-logging</groupId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
<profiles>
<profile>
<id>tomcat6</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<dependencies>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.5</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>javax.servlet.jsp</groupId>
<artifactId>jsp-api</artifactId>
<version>2.1</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>javax.faces</groupId>
<artifactId>jsf-api</artifactId>
<version>${jsf-version}</version>
</dependency>
<dependency>
<groupId>javax.faces</groupId>
<artifactId>jsf-impl</artifactId>
<version>${jsf-version}</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>javax.el</groupId>
<artifactId>el-api</artifactId>
<version>1.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>commons-el</groupId>
<artifactId>commons-el</artifactId>
<version>1.0</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>commons-discovery</groupId>
<artifactId>commons-discovery</artifactId>
<version>0.4</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>jstl</artifactId>
<version>1.1.2</version>
<scope>runtime</scope>
</dependency>
</dependencies>
</profile>
</profiles>
<properties>
<!--
since no more versions of jsf1.1 are being developed, just
jsf-version property for jsf1.2
-->
<!-- <jsf-version>1.2-b19</jsf-version>-->
<jsf-version>1.2_12</jsf-version>
</properties>
</project>

W przykładzie Timezone7 z tutoriala ICEfaces prezentujacego integrację z Mavenem (przykład jest na miejscowym forum) wszystko wygląda pięknie, ale nie działa. Należy jeszcze poddać edycji plik web.xml i ustawić na wartość false parametry:

1. com.sun.faces.validateXml
2. com.sun.faces.verifyObjects

Na koniec w konsoli wpisujemy: mvn tomcat:deploy Przy założeniu, że macie stworzony jakiś przykładowy widok. Zakładam również, że skonfigurowany jest dostę do tomcata z poziomu mavena. Niejaki Pan Koziołek opisał to kiedyś dokładnie.

To chyba tyle. Powinno śmigać.

Korzystając z okazji życzę Wam owocnego przeżywania Świąt Wielkiej Nocy, a po Świętach uczestnictwa w wielu ciekawych projektach.

Mariusz

Spring BlazeDS

Wczoraj niezmiernie ucieszyła mnie informacja na InfoQ o tym, że SpringSource połaczył swe siły z Adobe w projekcie Spring BlazeDS. Na początku powinienem wspomnieć coś na temat samego projektu BlazeDS.
Otóż BlazeDS jest technologią uruchamianą po stronie serwera umożliwiającą komunikację pomiędzy Javą a technologią Adobe Flex i Adobe AIR, które pełnią funkcję widoku. Komunikacja odbywa się za pomocą protokołu AMF lub SOAP. Jakiś rok temu testowałem przykładowy kod korzystając zarówno z AMF jak i SOAP i pewnie nikogo to nie zdziwi, ale komunikacja przez AMF postępowała bardziej chyżo.
Co natomiast daje nam Spring BlazeDS ? Ano to, że mamy teraz dostęp do BlazeDS MessageBrokera jako do beana Springa. Dokładniej mówiąc oddzielnie trzymana jest (raczej niezmienna) konfiguracja BlazeDS, która zawiera definicję właściwości kanału AMF i oddzielnie konfigurowane jest źródło danych znane powszechnie z aplikacji Springowych.

Wydaje mi się, że wciąż konieczne jest używanie skrypletów w Action Scripcie dla akcji wysyłających dane do serwera. Może kiedyś będzie to rozwiązane przez projekt opakowujący komponenty Flexa w JSF. Wiem, że takowy już istnieje, ale go już dawno nie śledziłem.

Odnośniki:

http://www.infoq.com/news/2009/01/spring-adobe-blazeds
http://opensource.adobe.com/wiki/display/blazeds/BlazeDS/
http://blog.springsource.com/2008/12/17/using-spring-blazeds-integration-m1/

Dlaczego nie warto trzymać transakcji w metodach klasy DAO

Wzorzec Data Access Object zwany w skrócie DAO jest wzorcem projektowym związanym z warstwą integracji. Klasa DAO zawiera metody odwołujące się do tzw. data storage, którym jest zazwyczaj baza danych. Wyobraźmy sobie sytuację, że musimy dokonać podmiany danych użytkownika, gdyż zmienił się jego adres zamieszkania. Procedura działania jest następująca:
1. Odszukanie użytkownika na podstawie jakiegoś identyfikatora
2. Pobranie adresu użytkownika
3. Ustawienie nowego adresu i zapisanie zmian do bazy danych
Każdy z tych punktów możemy traktować jako wywołanie pojedynczej metody obiektu (lub tez obiektów DAO). W standardowych przypadkach byłoby nierozsądnym otwieranie i zamykanie transakcji dla każdej z tych metod z osobna, gdyż niepotrzebnie zwiększałoby to wykorzystanie zasobów. Dodatkowo niepowodzenie jednego z trzech punktów powinno spowodować powrót bazy do stanu przed rozpoczęciem procesu uaktualniania adresu użytkownika. Rozwiązaniem nowej klasy zawierającej metodę w ramach, której wywoływane są poszczególne metody obiektu DAO. Dopiero tutaj, na początku tejże nowej metody otwieramy transakcję, która zamykana jest po wywołaniu ostatniej metody obiektu DAO. Czyli metody zapisującej nowy adres do bazy danych. W ten oto sposób popełniliśmy niechcąco wzorzec Application Service.

Moje prywatne żale

Dzisiaj nie będę oryginalny. Takie lamenty przewijają się co jakiś czas na forach internetowych związanych z Javą...

Od dłuższego czasu zabieram się za poznanie języka Ruby. W tym celu nabyłem nawet stosowną książkę, a tu się nagle okazuje, że jest coś takiego jak Scala, że niby to jest lepsze i z Javą powiązane. To ja się pytam kiedy na to wszystko znaleźć czas?

Moje wrażenia podczas obcowania z EMF, GMF, GEF

Ostatnio jestem zaangażowany w projekt zbudowany z niezależnych pluginów Eclipse’a. Taki system pozwalający na tworzenie modeli w oparciu o zdefiniowany, własny DSL. Dla osób nie siedzących w tym temacie dodam, iż wygląda to trochę jak edytor UML. Technologie użyte przy budowie systemu to EMF, GMF, GEF. Muszę przyznać, że czas wejścia w te technologie jest stosunkowo długi (przynajmniej jak dla mnie). Jednak, gdy już posiądzie się „tajemną” wiedzę tworzenie kompleksowych aplikacji staje się dużo prostsze. Kontakt ze stosunkowo prostą aplikacją zbudowaną o wspomniane frameworki powoduje, iż użytkownik końcowy ma wrażenie, że jest ona graficznie i funkcjonalnie dopieszczona. Nie trzeba zajmować się wieloma aspektami wymaganymi przy tworzeniu standardowych aplikacji takimi jak np. standardowe menu, integracja z repozytorium, przechwytywanie zmian w modelu od ostatniego zapisu, lokalizacja itp. Dużo rzeczy programowana jest poprzez model deklaratywny na podstawie, którego automatycznie generowany jest kod. W temacie EMF, GMF, GEF wciąż raczkuję. Może dlatego, iż rdzeń aplikacji tworzony jest przez mojego przełożonego, który dość długo siedzi w tym temacie, a moja rola ogranicza się głównie do poprawy zgłaszanych błędów. Jednakże jest to ciekawe dla mnie doświadczenie, gdyż sam widzę jak w przeciągu ostatnich dziesięciu lat zmienia się sposób pisania kodu i tworzenia systemów informatycznych.

Pętle i etykiety

Witam po dłuższej przerwie, ale do rzeczy. Czasami zdarza się (szczególnie w pracy), iż ktoś zagląda na mój kod. Często w takich momentach widzę zdziwienie na twarzy podglądacza, gdy zauważa, że używam etykiet dla zagnieżdżonych pętli. Wydaje mi się, że często pomija się to dobrodziejstwo, a szkoda.

loop: for (Connection connection : outcomingConnections) {
...
}