Optymalizacja pracy – bash

Posted Leave a commentPosted in bash

Pomimo tego, że na codzień korzystam z IntelliJ, to jednak do wykonywania buildów, obsługi GITa i kilku innych czynności używam basha. Jest to dla mnie znacznie wygodniejsze rozwiązanie, szczególnie biorąc pod uwagę moje zamiłowanie do korzystania z samej klawiatury dopóki to jest możliwe. Używanie myszki to osteczność :) Warto poświęcić chwilę, na zdefiniowanie aliasów do czynności, które wykonujemy najczęściej.

Tak więc – jeśli korzystasz z mavena pomocne będą napewno:
alias mci='mvn clean install'
alias mcist='mci -DskipTests'
alias mcp='mvn clean package'
alias mp='mvn package'
alias mvc='mvn clean'
alias mmt='mvn clean package org.pitest:pitest-maven:mutationCoverage'

Ostatnia opcja to odpalenie testów mutacyjnych. A co to są testy mutacyjne? Do czego służą i jak ich używać? O tym wszystkim możesz posłuchać na moim talku, link: http://www.youtube.com/watch?v=gMFNV1zeVmQ. Prezentacja odbyła się w ramach grupy lbn.sc, do której zapraszam.

Kolejne aliasy, zaciekawią wszystkich użytkowników GITa. W mojej ocenie wsparcie IntelliJ dla GITa nieco kuleje. W IJ moja praca GITem ogranicza się do przeglądania historii pliku. Pozostałe komendy wolę wykonywać z basha. Oto gitowe aliasy:
alias gl='git log --graph --pretty=format:"%h - %d %s (%cr) " --abbrev-commit'
alias glg='git log --graph --pretty=format:"%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue reverse)%Creset" --abbrev-commit'
alias gap='git add --patch'
alias gc='git checkout'
alias gs='git status'
alias gp='git pull'

Bardzo często korzystam z glg które w szybki sposób pozwala sprawdzić historię gałęzi:
glg

Mam również zdefiniowane aliasy cc, ci, cj, ce itp, które przenoszą mnie bezpośrednio do katalogu danego projektu. Wtedy zamiast pisac cd dluga/sciezka/do/projektu piszę tylko ci i już jestem w odpowiednim katalogu.

Kolejną rzeczą (i ostatnią na dziś) którą mam zdefiniowanym w swoim ~/.bash_profile jest kolorowanie outputu mavena. Bardzo wygodne, przydatne i do tego świetnie wygląda 😉
# thanks to: http://blog.blindgaenger.net/colorize_maven_output.html
# Colorize Maven Output
alias maven="command mvn"
color_maven() {
maven $* | sed -e 's/Tests run: ([^,]*), Failures: ([^,]*), Errors: ([^,]*), Skipped: ([^,]*)/Tests run: 1, Failures: 2, Errors: 3, Skipped: 4/g'
-e 's/([WARN].*)/1/g'
-e 's/(WARN.*)/1/g'
-e 's/([INFO].*)/1/g'
-e 's/([ERROR].*)/1/g'
-e 's/(BUILD FAILURE.*)/1/g'
-e 's/(FAILURE!.*)/1/g'
-e 's/(BUILD SUCCESS.*)/1/g'
-e 's/(SUCCESS.*)/1/g'

}
alias mvn=color_maven

Nieudany build:
build-fail

Udany build:
build-success

Będąc w temacie optymalizacji pracy koniecznie muszę wspomnieć o wykorzystaniu potęgi skrótów klawiszowych, której wiele osób niedocenia. Ale to dosyć obszerny temat, któremu poświęcony zostanie odrębny wpis :)

Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Krótka historia o GlassFish4 i BeanManager

Posted Leave a commentPosted in java

W aplikacji Java EE6, nad którą pracuję, wykorzystuję CQRS. W związku z tym korzystam z dosyć rozbudowanej floty Commandów i Handlerów. Aplikacja na starcie wyszukuje wszystkie Handlery i zapisuje mapowanie Command na Handler. Aby uzyskać listę wszystkich handlerów korzystam z BeanManagera. Samo pozyskanie instancji BeanManagera odbywa się w następujący sposób:

Gdy mamy już BeanManagera możemy przejść do sedna sprawy. Oto CommandHandler:

Sama rejestracja handlerów wygląda w ten sposób:

Kod bez problemów działał na JBossie oraz Resinie. Po przesiadce na GlassFisha 4 zaczęły się schody – metoda getBeans zaczęła zwracać pusty zbiór. Korzystanie z aplikacji stało się niemożliwe, gdyż nie działało nawet logowanie. Musiałem więc przyjrzeć się temu kodowi bliżej.

Klasa LoginHandler implementuje CommandHandler. Dodatkowo pamiętamy, że początkiem wszystkiego w Javie jest klasa Object, tak więc mamy taką oto hierarchię:

Posiłkując się IntelliJ oraz debugiem za pomocą getBeans(Object.class) uzyskałem dostęp do wszystkich zarejestrowanych beanów. Na tej liście znalazłem także moje problematyczne beany.

Zagłębiając się w problem natrafiłem na to, że metoda getTypes() rzeczonego handlera zwraca 3 wartości:

debug-pt1

Pomimo obecności CommandHandler na pozycji pierwszej, nie jest ona brana pod uwagę podczas wołania beanManager.getBeans(CommandHandler.class). Wynika to z tego, że CommandHandler przyjmuje typy generyczne, a GlassFish4 inaczej niż JBoss i Resin traktuje takie klasy.

Rozwiązanie, które udało mi się znaleźć to wprowadzenie typu nadrzędnego (bez generyków) wobec CommandHandler.

h2

Teraz należało jeszcze zmodyfikować metodę odnajdującą handlery:

I wszystko działa jak należy.

Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail