Miesięczne archiwum: Lipiec 2012

Posłuchajcie nas na Security BSides

Miło nam poinformować, że w dniach 12-14 października w Warszawie odbędzie się polska edycja konferencji Security BSides. Redakcja javablog.eu będzie aktywnie uczestniczyć w tym wydarzeniu. Piotr Łaskawiec będzie jednym z prelegentów i opowie o bezpieczeństwie systemów bazujących na wirtualnej maszynie Javy.

Bezpieczeństwo Javy jest ostatnio często poruszanym tematem. Popularność tego języka programowania nieustannie skupia na nim uwagę specjalistów ds. bezpieczeństwa. Ostatnie błędy w systemach Mac OS tylko zwiększyły zainteresowanie istnieniem potencjalnych luk. Co więcej, ogromna ilość frameworków, bibliotek oraz narzędzi bazujących na JVM gwarantuje praktycznie niewyczerpaną liczbę wektorów ataku. Prelekcja zatytułowana „Bezpieczeństwo aplikacji opartych o Java Virtual Machine” ma na celu przybliżenie istniejących zagrożeń, najciekawszych przypadków oraz metod ochrony przed złośliwym kodem. Będzie technicznie, praktycznie i ciekawie.

Mamy nadzieję, że zobaczymy się w Warszawie!

Zdaj OCEEJBD – pytanie 4

Jaki będzie efekt wykonania metody test?

@Stateless
@LocalBean
@Interceptors({FirstInterceptor.class, SecondInterceptor.class})
public class TestBean {
	
	public int test() {
		return 1;
	}
}

@Interceptor
class FirstInterceptor {
    @AroundInvoke
    public Object around(InvocationContext ic) throws Exception
    {
       return 2;
    }
}

@Interceptor
class SecondInterceptor {
    @AroundInvoke
    public Object around(InvocationContext ic) throws Exception
    {
       return 3;
    }
}

 

  1. Metoda zwróci wartość 1.
  2. Metoda zwróci wartość 2.
  3. Metoda zwróci wartość 3.
  4. Powyższy kod jest niepoprawny i nie skompiluje się.

 

Pokaż odpowiedź »

Poprawna jest odpowiedź nr 2.
Dla klasy TestBean zdefiniowane są dwa interceptory – FirstInterceptor oraz SecondInterceptor. Odpowiedzialne są one za przechwytywanie wykonania metod i „opakowywanie” ich w dodatkową logikę. Warto zauważyć, że żaden z interceptorów nie wykonuje metody proceed() na instancji klasy InvocationContext, która to odpowiedzialna jest za przekazanie sterowania do następnych interceptorów oraz do właściwej metody naszego ziarna EJB. Powoduje to, że uruchomiony zostanie jedynie pierwszy zdefiniowany interceptor (FirstInterceptor), który zwróci wartość 2.

Eclipse 4.2 Juno – co nowego?

Minęło już 8 lat od ostatniej dużej premiery Eclipse’a. Wtedy to zaprezentowany został Eclipse 3. Dziś, po tak długim okresie czekania, dostępna jest wersja 4.2, która niesie ze sobą wiele zmian. Część z nich zauważymy zaraz po włączeniu aplikacji, innych natomiast doświadczymy w bardziej pośredni sposób. Dla ułatwienia postanowiłem zebrać i krótko scharakteryzować większe z nich.

Czytaj dalej

Zdaj OCEEJBD – pytanie 3

Jaki atrybut transakcji przyjmie metoda test3?

TestBean:

@Stateless
@LocalBean
@TransactionManagement(TransactionManagementType.CONTAINER)
public class TestBean {
	
	@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
	public void test1() {
		// test1 logic
	}
	
	@TransactionAttribute(TransactionAttributeType.NEVER)
	public void test2() {
		// test2 logic
	}
	
	public void test3() {
		// test3 logic
	}
}

 

  1. Powyższy kod jest niepoprawny i nie skompiluje się.
  2. Nie można definiować atrybutów dla transakcji zarządzanych przez kontener.
  3. Metoda test3 jest niejawnie oznaczona atrybutem REQUIRED.
  4. Metoda test3 jest niejawnie oznaczona atrybutem NEVER.
  5. Metoda test3 jest niejawnie oznaczona atrybutem REQUIRES_NEW.

 

Pokaż odpowiedź »

Poprawna jest odpowiedź nr 3.
Dla transakcji zarządzanych przez kontener, domyślnym atrybutem jest TransactionAttributeType.REQUIRED. Każda metoda, która nie posiada jawnie zdefiniowanego atrybutu transakcji będzie przyjmować jako jego wartość REQUIRED. Atrybut ten powoduje, że wykonywana metoda wykorzysta istniejącą transakcję lub automatycznie stworzy nową, w przypadku gdy jej wywołanie zostało wykonane poza transakcją.

Etapy Code Review

Code Review jest szeroko stosowanym, i co najważniejsze przynoszącym wymierne korzyści procesem. Przeglądając grupowo fragmenty kodu odpowiadające za zaimplementowaną funkcjonalność istnieje bardzo duże prawdopodobieństwo znalezienia drobnych (choć nie zawsze) elementów, które przeoczyła osoba ten kod tworząca. Często pojawia się jednak problem: na co zwrócić uwagę? Na to pytanie postarał się odpowiedzieć Jake Goulding we wpisie na swoim blogu. Odniósł się do swoich doświadczeń związanych z projektem pisanym w języku C, dlatego też nie wszystkie etapy będą poprawne w odniesieniu do Javy. Mimo wszystko jednak lektura ta powinna znacznie pomóc w usystematyzowaniu Code Review i zmaksymalizowaniu zysków z niego płynących. Jak zwykle zapraszam do lektury!

 

Update:

Polska blogosfera programistyczna wcale nie zostaje w tyle, i jak się okazuje, możemy poczytać przemyślenia naszych rodzimych developerów na temat przeglądów kodu. Serdecznie zapraszam więc do zapoznania się z artykułem Michała, za którego podesłanie bardzo dziękuję.

Cool Code – wideo

Jeżeli przypominacie sobie naszą relację z drugiego dnia GeeCONu, to zapewne wiecie, że największe wrażenie wywarł na mnie wykład kończący konferencję, zatytułowany Cool Code. Miło mi poinformować, że kompletny zapis wideo z prezentacji, którą poprowadził Kevlin Henney jest już dostępny na GeeCONowym Vimeo. Gorąco polecam. Czeka Was godzina dobrej zabawy :)