Klaus Schultz

Mark Cade wrote:First, anyone can become an architect. I would say that most good architects are also good designers and coders. You are on the right path to work your way to becoming an architect.

Not anyone can become an architect. At work I see two different types of programmers: there are programmers who work only along the examples they got teached, e.g. make always a controller class, and there are programmers who think about their design (upfront or during the coding phase) and make a controller if it's appropriate for the problem.

Krzysztof Koziol wrote:Hi there,

What's wrong in #13? Where do we need an extra @Transient annotation?

Has every not-annotated field type a default mapping? What is the default mapping of a Map<Integer,String> ?

Krzysztof Koziol wrote:

I've got some doubts regarding question #19. In the code snippet we've got:

Book b = (Book) em.createQuery("SELECT b FROM Book b").getSingleResult();

We are not 100% sure that there is only one entry in the Book table (or table has at least one entry at all).
Therefore this query may throw NoResultException or NonUniqueResultException!

Yes, the code may throw an exception, and you should never code this statement in a real program.

But in the exam, you have to answer the questions, which target entity manager in a Java SE environment.

Ross Crockett wrote: using Field-based Access

The fields can be declared even private in case of Field-based Access.

Hi,

>>This code snippets shows that the contains prove if a entity is in a certain context and it does not prove if >>the entity exist in the database.
Sure. To quote the javadoc of the contains method:
"Check if the instance belongs to the current persistence context."
That's a quite clear statement. If you want to know if the entity exists in the database, you must do something like find().

In your example the client is not shown, method b() may have the same transaction as method a()
if they are called from the client with the same transactional context.

If for method b() the container has started a new transaction, the entity manager has a new persistence context, which you query in line 12 with contains(myEntity). You didn't code a find() or something else to populate the persistence context.

Don't fear the specs! The Notes of Mikalai Zaikin (lot of thank to him) are mostly an excerpt of the specs, sometimes I understood better by reading the spec itself.

I don't know the book "EJB3 in Action", sounds good.

You can't do the exam only by reading, you must act with these things.
- Ethuware 5 mock exams helped me a lot
- try things on a EJB 3.0 Container (I used JBoss, because it was already installed, next time I would try Glassfish)

Klaus
passed with 93%

I used for preparation:
- the Notes of Mikalai Zaikin (thank you a lot)
- the original spec, which is sometimes good readable
- Ethuware 5 mock exams , which were worth the money
- a EJB 3.0 Container (I used JBoss, because it was already installed, next time I would try Glassfish)

To add a historical point: Inversion of Control is a general term first used to explain how OO frameworks work. Inversion of Control is often pronounced as the Hollywood principle "don't call us, we will call you". Take for example the design pattern "Template method": your code is called from the framework. This design pattern shows also the big difference in this meaning of IoC versus DI: the Template Method calls your code at a specific point in a sequence of actions done by the framework. DI as I know it is completely static, constructing a net of objects at initialization time and injecting this environment into the components which need it.

DI is clearly a form of IoC but a very special one.

Dhanji, do you agree this? (besides my crude characterization of DI)

Klaus

Q26 - to correct my last post.
I didn't read the post of E Lievaart from Jul 2008.
His quotation of the spec is right, JBoss is wrong.
So the solution should be "doIt, afterBegin, inc".

Q8 - I found in chapter 4.6.6 of the spec the following:
"If bean class implements a single interface, that interface is assumed to be the business
interface of the bean. This business interface will be a local interface unless the
interface is designated as a remote business interface...."

So both methods of the interface will be exposed (locally).

Promod is right about Q26:
"doIt, afterBegin, inc" can never be the right solution.

The method beforeCompletion must be entered to execute ctx.setRollbackOnly();
The method will return with no exception.

In my unterstanding of the API, the method afterCompletion(boolean f) will also be called.
From the method signature with the boolean parameter it is clear that it should also be called
in case of a rollback.

Trying this in JBoss 4.2.3.GA, I get the println of beforeCompletion(), and concerning afterCompletion() I get a
similar WARN from the arjLoggerI18N as Promod. This warning occurs also in case of a normal commit, so I think it's a JBoss problem.

Klaus

Taking beside Seam: in EJB you should differentiate between the concept of a @Remove annotated method of stateful session bean, which will be called by the client, and the concept of a @PreDestroy annotated method, a lifecycle callback method called by the container. I think the Destroy method of Seam resembles the PreDestroy in EJB.

Klaus