Archiwa kategorii: Zdaj OCEEJBD

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.

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ą.

Zdaj OCEEJBD – pytanie 2

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.

Zdaj OCEEJBD – pytanie 1

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.

Zdaj OCEEJBD

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: