Adam Tkaczyk

JEE servers use Proxy mechanisms to obtain references on EJB objects through business interface. With proxy, container can react on some properties thirled to business methods like @TransactionAttribute or @RolesAllowed.

Even if you return reference on Bar interface it will not be business interface connected to EJB object, so probably you get an exception when you invoke some method from it. That is why answer A) is wrong. Try java.lang.reflect.Proxy for more details. It is great fun.

C) and E) are wrong because lookup method will return reference to the new EJB object, not the same used for method invocation.

C is wrong because of generated primary key. In this case only integral types (byte, short, int and long) will be portable.

For further information see JSR 220 - Java Persistence API, page 22, passage 2.1.4

C) should be as follows
SELECT r, AVG(r.chairs) FROM Room r group by r having r.chairs > AVG(r.chairs)
You can't have aggregate function inside "where" clause

It is very simple.
When you call business method which have interceptor only interceptor is called (from client view) and some informations about this method is given in InvocationContext object.

If you want to return value from business method you should write following code in your interceptor method

@Aroundlnvoke
public Object intercept(lnvocationContext ctx) {
try{
return ctx.proceed();
}catch(Exception e){...}
return null;
}
or another way

@Aroundlnvoke
public Object intercept(lnvocationContext ctx) {
try{
return ctx.getMethod().invoke(ctx.getTarget(),ctx.getParameters());
}catch(java.lang.reflect.InvocationTargetException e){...}
return null;
}

I don't catch the problem.
There are 3 ways to get entered text from h:inputSecret

1) From the value of this component. If you bind value to the managed-bean property you can read it very easy.

2) From the binding of this component. If you bind all component to managed-bean property, you can invoke getValue() method from InputSecret and read entered text.

3) From the JavaScript

Facts
1) There is 250+ databases that have the same schema
2) user and password are needed to logon

I sugest to write ConnectionFactory (singleton) class that has access to credentials and can create JDBC connection (or connection pool).

After that we can write collection of classes that will service business operations (common for every schema). Those classes can take ConnectionFactory instance as constructors or methods argument and use this instance to obtain JDBC connection and perform their jobs.

This solution is some kind of "Strategy" design pattern.

If you have already an appointment and passed almost every Whizlabs exams then you are ready to take SCJP. I have passed all Whizlabs exams. After that I have started to review every question again. After SCJP (86%) I have realized that I spent to much time to accomplish this task, so if you had good overall score in Whizlabs you should go on exam without doubts and fears.
Good luck!

Example:

@Stateless
@Local({One.class})
class OneBean implements One{
public void doSmth(){...}
}

@Stateless
@Local({Two.class})
class TwoBean implements Two{

@EJB
private One oneBeanInstance;
public void doSmth2(){...}
}

You have to refer to OneBean class through business interface.
Container will inject implementation of that interface after bean creation and before every invocation of business method.

There is not such think as entity bean in new 3.0 specification. Since JEE 5 there are entities that are POJO. Container use PersistenceProvider API to manage them. You can use old fashion entity beans in JEE5 environment if you want. There are still available only for backward compatibility but there are deprecated. I hope I have answered your question.

That is not true. Those methods trown TransactionRequiredException only when no transaction is available. The default transaction attribute for container managed ejb beans is REQUIRED. If you use merge, persist within transaction everything will be fine. Maybe you have set transaction attribute on business method wich invoke merge, persist to : NEVER , NOT_SUPPORTED or SUPPORTS. In this case container will not create transaction context and exception may be thrown.

I suggest you to read JSR 220 specification for further informations.
"EJB Core Contracts and Requirements" pages from 343 to 345

JSR 220 explains this very clearly.

A persistence unit is a logical grouping that includes:
� An entity manager factory and its entity managers, together with their configuration information.
� The set of managed classes included in the persistence unit and managed by the entity managers
of the entity manager factory.
� Mapping metadata (in the form of metadata annotations and/or XML metadata) that specifies the mapping of the classes to the database.

I think the good answer is
'303-___-____'

_ means one character
% means zero, one or more characters
so
A. WHERE addr.phone LIKE '303_' - bad answer, matching numbers 3031, 3030, ...
B. WHERE addr.phone LIKE '303%' - bad answer, matching numbers 3031,303-156-1, 303anything_more
C. WHERE addr.phone LIKE '303-_-_' - bad answer, matching numbers 303-1-1, 303-5-6 but not 303-456-7890
D. WHERE addr.phone LIKE '303-%-%' - the best answer from those listed but it is also wrong because it doesn't control size of number, it will match also 303-123456789-45648465564
E. WHERE addr.phone LIKE '303-- - bad answer - this is meaningless
F. WHERE addr.phone LIKE '303-%%%-%%%%' - bad answer, it doesn't control size of number also

Answer C is ok.
Here http://java.sun.com/javaee/5/docs/api/javax/annotation/PostConstruct.html
is explanation why.

A is not good because entity is in "new" state after statement
EntityClass object = new EntityClass();
so it can have no state available (no persistence identity also)

B is not good because "detached" state means that entity is no longer available in persistence context, but it was before, so it has persistence identity

C is not good because "removed" entity is still associated with persistence context because the persistence context has to make database operations to physically remove db row from database.

If all your databases have the same schema I think the best solution is to write some sort of common contract for all business operations. The only think that would change is datasource. That approach reduce bad redundancy and makes your code more flexible