Some of posts from this blog has been moved to dywicki.pl. You will be automatically redirected to new blog if you would submit comment.
New posts are published on dywicki.pl, this blog contains old content related to Code-House company.


Niektóre posty z tego bloga zostały przeniesione do dywicki.pl. Zostaniesz automatycznie przekierowany jeśli bedzięsz chciał dodać komentarz.
Nowe posty sa publikowane na dywicki.pl, ten blog zawiera stare treści związane z firmą Code-House.

Wygodne środowisko dla programisty z JRebel

jrebel_biggerOd dłuższego czasu pracuję z następującymi narzędziami: Maven, Eclipse, Jetty. Nigdy nie starałem się na to by moje projekty dobrze współgrały z Eclipse ponieważ wszystko i tak uruchamiam przez Mavena. Korzyścią jest przenośność tego rozwiązania, wadą brak klikalnej wygody, tj zakładki serwerów w Eclipse i aplikacji które są na nich uruchomione.

Tuż przed nowym rokiem udało mi się skonfigurować Mavena i Eclipse oraz JRebel. Teraz po zmianie klasy czy konfiguracji Springa z poziomu Eclipse zmiany widać w Jetty uruchomionym z poziomu Mavena. Nie byłby to sukces sam w sobie gdyby nie fakt, że udało się to zrobić w z wieloma modułami. Oto przykład struktury projektu:

  • domain – model danych oraz encje
  • security – kod związany z zabezpieczeniami oraz ich konfiguracją
  • dataaccess
    • api – interfejsy DAO oraz Fasad
    • jpa -dostęp do danych przy użyciu JPA
    • jdbc – dostęp dod anych z użyciem gołego JDBC
  • web – końcówka webowa – kontrolery itp.
  • distribution – tworzenie dystrybucji do środowiska testowego i produkcyjnego

Ogólnie strukturę tą można coraz bardziej rozdrabniać bądź zbijać tak by odpowiadała ona naszym potrzebom, w tym przypadku pominiemy dywagacje ponieważ nie o tym ten wpis ma być. Problemem przy tego typu strukturze jest to że zmiany w modułach dao są dostępne w module web dopiero po przebudowaniu obydwu, co czasami bywa uciążliwe. Rozwiązaniem byłoby użycie OSGi i serwera który to wspiera, po zmianie robili byśmy deploy bundle który się zmienił – było by to z pewnością wygodniejsze niż dwukrotny mvn install, jest jednak rozwiązanie jeszcze wygodniejsze – JRebel.

Konfiguracja Mavena

Jak już wspomniałem całość zmian nie wymaga nic od Eclipse ze względu na to, że całość deskryptorów jest generowana z poziomu Mavena przy pomocy maven-eclipse-plugin.

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-eclipse-plugin</artifactId>
    <configuration>
        <buildOutputDirectory>target/classes</buildOutputDirectory>
        <projectNameTemplate>[groupId]_[artifactId]</projectNameTemplate>
    </configuration>
</plugin>

Drugi krok to stworzenie bądź modyfikacja zmiennej środowiskowej MAVEN_OPTS:

-noverify -javaagent:E:\tools\jrabel-2.2.1\jrebel.jar -Xdebug -Drebel.log.stdout=true -Drebel.log=true -Xrunjdwp:transport=dt_socket,server=y,address=4000,suspend=n -Xmx768m

Trzeci krok to konfiguracja JRebel. Oczywiście można skorzystać z javarebel-maven-plugin, ale mi nie udało się go poprawnie skonfigurować, dlatego też plik został stworzony ręcznie:

<?xml version="1.0" encoding="UTF-8"?>
<application xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.zeroturnaround.com" xsi:schemaLocation="http://www.zeroturnaround.com/alderaan/rebel-2_0.xsd">

    <classpath>
        <dir name="${basedir}/target/classes" />
        <dir name="${basedir}/../domain/target/classes" />
        <dir name="${basedir}/../security/domain/target/classes" />
        <dir name="${basedir}/../dataaccess/api/target/classes" />
        <dir name="${basedir}/../dataaccess/jpa/target/classes" />
        <dir name="${basedir}/../dataaccess/jdbc/target/classes" />
    </classpath>

    <war dir="${basedir}/webapp" /> <!-- lokalizacja plików JSP itp -->

    <web>
        <link target="/myapp"> <!-- nazwa kontekstu -->
            <dir name="${basedir}/webapp"> 
            </dir>
        </link>
    </web>

</application>

Dodatkowo należy wyłączyć przeładowania Jetty tak by nie kolidowały one z agentem JRebel. Całość w dalszym ciągu działa z poziomu Mavena i jest przenośne. Po tych wszystkich zmianach możemy się cieszyć trialem przez 30 dni bądź kupić licencję za jedyne 149$. :)

 

3 replies


  1. Czemu te nazwy takie długie? W pewnej firmie doszli do etapu gdy nazwy pakietów zajmują ponad 100 znaków, paranoja.
    sec?
    access? da?
    dist?


  2. Nazwy modułów i projektów nie muszą się pokrywać jeden do jednego z nazwami pakietów, jednakże jest to ogólnie dobry zwyczaj. Jeśli nazwy pakietów są zbyt długie zawsze można je skrócić korzystając z Eclipse. :) To tylko kwestia preferencji.


  3. sec? — eee sekunda??
    access? — owszem, kojarzy sie data access, mi na pewno, ale czy wszystkim?
    da? — dam dam, tylko co?
    dist? – jedyny chyba rozpoznwalany skrot

    czy metdy tez nazywasz searUsrWthNm(String n) ? :)

    rozumiem ze 100 znakow to przegiecie, ale ja wole ladnie wiedziec i czytac nazwy modulow

Leave a reply