Skip to content
maj 20 12

GeeCON Day 1 – relacja

przez Piotr Łaskawiec

Po University Day nadszedł czas na bardziej oficjalną część konferencji. Na korytarzach Multikina pojawiły się stoiska sponsorów, a szeregi Geeków zostały zasilone przez setki osób, które nie zdecydowały się na udział w University Day. Nadszedł czas na prawdziwy start GeeCONa… czytaj dalej…

maj 20 12

Awaitility – łatwiejsze testy asynchronicznego kodu?

przez Łukasz Picur

Niedawno opisywałem testowanie asynchronicznego kodu przy wykorzystaniu Mockito. Jeden z naszych Czytelników zwrócił jednak uwagę na to, że istnieją gotowe narzędzia zbudowane po to, by w takich sytuacjach pomagać. Jednym z nich jest Awaitility – mała, ale dość intensywnie rozwijana biblioteka mająca za zadanie uproszenie pisania testów jednostkowych kodu wielowątkowego. Jak spisuje się w praktyce? Na to postaram się odpowiedzieć.

czytaj dalej…

maj 18 12

GeeCON University Day (Day 0) – relacja

przez Piotr Łaskawiec

Po 4Developers nadszedł czas na kolejną konferencję organizowaną w Poznaniu. Tym razem, programistów różnych narodowości przyciągnął do Polski GeeCON, aby wspólnymi siłami „poruszyli Javowy świat”. Konferencja zaplanowana została na trzy dni. Poniżej znajdziecie moje wrażenia z pierwszej części GeeCONa (tzw. „University Day”), która w założeniach miała być poświęcona na szkolenia i warsztaty. czytaj dalej…

maj 17 12

Uwierzytelnianie i autoryzacja za pomocą SiteMindera i SpringSecurity w aplikacji Grailsowej

przez Magdalena Blaschke

W jednym z artykułów opisywaliśmy podstawy implementacji uwierzytelniania przy uzyciu Spring Security w aplikacji webowej. Ale przecież wszyscy wiemy, że w rzeczywistości nie ma tak łatwo ;) Szczególnie, kiedy należy wprowadzić security do odziedziczonego kodu.

Załóżmy, że mamy prostą aplikację webową napisaną w Grailsach. Jej głównym zadaniem jest odpytywanie innych narzędzi i czynienie pomniejszej magii. Nie przechowuje żadnych informacji, w ogóle nie korzysta z bazy danych. Mimo, że ma zastosowanie administratorskie to bezpieczeństwo jest poniekąd pominięte, bo przecież jest ‘wewnętrzna’, schowana na jakiejś maszynce i kto tam o niej wie poza nami…  Pewnego dnia nachodzi nas (ewentualnie naszego menadżera/architekta/kolegę) zacna idea. Przecież można by troszkę dopisać, coś zmienić i udostępnić szerszej publice kawałek aplikacji w celach samoobsługowych (zwalniając przy tym zespól z części zadań administracyjnych, yay!). Sęk w tym, żeby ten ‘kawałek’ pozostał rzeczywiście kawałkiem. I to jest ten moment kiedy zakres dostępu zaczyna nas interesować. To tak tytułem wstępu ;)

czytaj dalej…

maj 3 12

doclava – ładniejsze javadoci od Google

przez Łukasz Picur

Nikogo chyba nie trzeba przekonywać do tego, że domyślne javadoci generowane dla klas Javy wyglądają dość przestarzale. Nawet pomimo niedawnego liftingu wciąż brakuje tak podstawowych funkcjonalności jak możliwość wyszukiwania. Problem ten zauważyło także Google, które to udostępnia niewielki projekt o nazwie doclava. Jest to nic innego jak doclet, którego można użyć, by odrobinę podrasować dokumentację. Prócz wspomnianego już wyszukiwania udostępnia również szereg dodatkowych parametrów i tagów, służących do personalizacji generowanych plików. Mamy też do dyspozycji rozbudowane mechanizmy styli. Niestety nie ma róży bez kolców – brakuje np. obsługi @author i @since, które to są dość szeroko używane. Mimo wszystko zachęcam jednak do zapoznania się z doclava. Więcej poczytać można na oficjalnej stronie projektu. Aby przetestować opisywane narzędzie, należy dodać do standardowego wywołania programu javadoc dodać poniższy fragment:

-doclet com.google.doclava.Doclava -docletpath <doclava.jar>

Nie ma także problemu z wykorzystaniem go z poziomu Anta czy Mavena.

P.S. Jeśli komuś wydaje się, że wynik działania doclavy jest łudząco podobny do dokumentacji API Androida, to nie myli się. Jak widać, Google postanowiło wykorzystać stworzony przez siebie projekt.

maj 1 12

Zdaj OCEEJBD – pytanie 2

przez Piotr Łaskawiec

Które metody klasy TestBean będą częścią udostępnianego przez ziarno interfejsu biznesowego?

TestBean:

@Stateless
@LocalBean
public class TestBean extends BaseBean implements TestInterface {
	@PostConstruct
	public void init() {
		// init operations
	}

	@PreDestroy
	private void destroy() {
		// destroy
	}

	@Override
	public void method1() {
		// do something
	}

	@Override
	public String method2() {
		// do something
		return "method2";
	}

	private void privateMethod() {
		// do sth private
	}
}

BaseBean:

public class BaseBean {
	public void publicBaseMethod() {
		// do something
	}

	protected void protectedBaseMethod() {
		// do something
	}
}

TestInterface:

public interface TestInterface {
	public void method1();
	public String method2();
}

 

  1. Przedstawiony kod jest niepoprawny.
  2. Tylko metody interfejsu TestInterface
  3. Wszystkie metody klasy TestBean, niezależnie od wykorzystywanego modyfikatora dostępu.
  4. Wszystkie publiczne metody z wyjątkiem init() oraz destroy().
  5. Wszystkie publiczne metody klasy TestBean.

 

Pokaż odpowiedź »

Poprawna jest odpowiedź nr 5.
W przypadku ziaren EJB oznaczonych jako @LocalBean, interfejs biznesowy będą tworzyć wszystkie publiczne metody dostępne w danej klasie. W ziarnie TestBean będą to następujące metody:

  • init()
  • method1()
  • method2()
  • publicBaseMethod()

Zwróćmy uwagę na fakt, że metoda init() oznaczona jest adnotacją @PostConstruct. Nie jest to błąd, ale metody nasłuchujące na zdarzenia nie powinny być wywoływane bezpośrednio i co za tym idzie, nie powinny mieć publicznego modyfikatora dostępu.

maj 1 12

Zdaj OCEEJBD – pytanie 1

przez Piotr Łaskawiec

Jaki wyjątek należy przechwycić w klauzuli catch(…) podczas wykonywania poniższego fragmentu kodu, odpowiedzialnego za wywołanie metody na ziarnie EJB?

import javax.naming.InitialContext;

public class Main {
	public static void main(String[] args) {
		try {
			InitialContext context = new InitialContext();
			StatefulBeanRemote bean = (StatefulBeanRemote) context.lookup("java:global/EJB1/EJBMODULE/StatefulSessionBeanRemote");
			System.out.println(bean.sayHi("Java Blog"));
		} catch (...) {
			// do sth.
		}
	}
}

StatefulSessionBeanRemote:

@Stateful
public class StatefulSessionBeanRemote implements StatefulSessionRemote {
	public String sayHi(final String name) {
		String msg = "Hi " + name;
		return msg;
	}
}

 

  1. Klauzula catch jest zbędna.
  2. Należy przechwycić wyjątek biznesowy (Business exception).
  3. Należy przechwycić javax.naming.NamingException.
  4. Należy przechwycić javax.ejb.NoSuchEJBException.

 

Pokaż odpowiedź »

Poprawna jest odpowiedź nr 3.

Podczas odwoływania się do zasobów poprzez interfejs JNDI musimy obsłużyć wyjątki typu javax.naming.NamingException. W naszym przypadku wyjątek biznesowy nie zostanie rzucony ponieważ metoda sayHi działa w pełni prawidłowo i nie wykorzystuje żadnych specyficznych wyjątków informujących o wystąpieniu ewentualnej nieprawidłowości. NoSuchEJBException mógłby zostać rzucony jedynie gdyby bean, do którego się odwołujemy, został usunięty. Może się tak stać np. gdy wywołamy metodę oznaczoną jako @Remove.

Dodajmy testową metodę do klasy StatefulSessionBeanRemote (pamiętajmy o uwzględnieniu tej metody w interfejsie).

@Remove
	public void remove() {}

Następnie zmodyfikujmy kod klienta.

public static void main(String[] args) {
		try {
			InitialContext context = new InitialContext();
			StatefulBeanRemote bean = (StatefulBeanRemote) context.lookup("java:global/EJB1/EJBMODULE/StatefulSessionBeanRemote");
			bean.remove();
System.out.println(bean.sayHi("Java Blog"));
		} catch (NamingException e) {
			e.printStackTrace();
		}
	}

Powyższy kod spowoduje rzucenie wyjątku typu javax.ejb.NoSuchEJBException. Pamiętajmy jednak, że wyjątek ten dziedziczy po RuntimeException więc jego obsługa nie jest wymagana.

maj 1 12

Zdaj OCEEJBD

przez Piotr Łaskawiec

Nasz kurs przygotowujący do egzaminu Oracle Certified Professional Java Programmer cieszy się sporym zainteresowaniem. Udostępniliśmy Wam 50 pytań, które poruszają szeroki zakres tematów, na które możecie natrafić podczas prawdziwego egzaminu. Nadszedł jednak czas na zapoczątkowanie serii publikacji mających ułatwić Wam uzyskanie kolejnego certyfikatu – Oracle Certified Expert Enterprise JavaBeans Developer. Tak jak w przypadku kursu OCPJP, będziemy publikować zarówno tradycyjne pytania jak i takie, które nieco wykraczają poza wymagania stawiane pretendentom do tytułu :) Oczywiście nasz kurs nie gwarantuje zdania egzaminu. Powinien być postrzegany jako uzupełnienie standardowej ścieżki nauczania opartej np. o:

kwi 20 12

4Developers – relacja

przez Piotr Łaskawiec

Miesiąc temu miałem okazję uczestniczyć w konferencji 33rd Degree, która tylko utwierdziła mnie w przekonaniu, że warto pojawiać się na imprezach branżowych. Pomijając możliwość wysłuchania ciekawych prezentacji, konferencje pozwalają na poznanie wielu ciekawych ludzi i wymienienie się swoimi poglądami. Zgromadzenie dużej grupy programistów na ograniczonej powierzchni skutkuje niekontrolowanymi wybuchami kreatywności, które są prawdziwą esencją tych imprez. Dlatego też byłem niezwykle ciekaw, jak będzie przebiegać 4Developers, którego tegoroczna edycja odbyła się w Poznaniu…

czytaj dalej…

kwi 13 12

TIOBE – Java na drugiej pozycji

przez Łukasz Picur

W przeciągu ostatnich kilku lat Java niemal nieprzerwanie utrzymywała pierwszą pozycję w rankingu popularności języków programowania TIOBE. Dziś jednak sytuacja się zmieniła – Java spadła na drugie miejsce, a nowym liderem zostało… C. Jak czytamy na oficjalnej stronie rankingu, krzywa trendu spadkowego Javy przecięła w końcu stabilną krzywą C. Specjaliści z TIOBE prognozują, że mimo iż Java nie powinna spaść jeszcze niżej, to C może utrzymać pierwsze miejsce przez najbliższe miesiące. Co ciekawe, przed dalszym spadkiem Jave ma uchronić popularność Androida.