Steven Young

Congratulations Uchana,

A pass is a pass. It all means the same thing - you're now a Certified Business Component Developer. Well done and best of luck for your next goal !

Steve
SCJP 5
OMG UML Advanced
Hope to add SCBCD5 soon.

Hi Max,

I'm using EJB3 Persistence Version 3.0 Final Release May 2, 2006. I'm pretty sure I got it from this link which is the same as the SCBCD link:

http://jcp.org/aboutJava/communityprocess/final/jsr220/index.html

Are you sure you're referencing the Java Persistence API PDF file ? I notice the EJB Code Specs PDF file only has appendices A1 - A3.

A quick search on the EJB specifications has this statement in EJB Persistence spec:

A.4 Changes since public draft:
Renamed EmbeddableSuperclass as MappedSuperclass.

I'd take this to mean that the EmbeddableSuperclass annotation is no longer available in Final specification, so you'll only need to know MappedSuperclass.

Congratualations Beno�t,

Much deserved ! And many thanks for posting your answers to many questions posted on this forum. Very helpful.

What's next ? SCEA ?

Steven,
OMG UML Advanced
SCJP5

I believe in this situation, the first database statement will be rolled back if the second database statement fails and causes a transaction rollback. The first statement is still past of the same container-managed transaction.

I have not been able to find a definitive statement on this in the specification, but page 329 of the EJBCore specification provides an example of a bean-managed transaction that spans several methods and opens and closes a database connection. The spec states:

"It is possible for an enterprise bean to open and close a database connection in each business method (rather than hold the connection open until the end of transaction)."

I don't see why the rule would be any different for CMT. The point is that opening and closing a database connection does not change the status of the transaction.

Hi Paven,

EJB Core Spec (page 307) says
"If a lifecycle callback interceptor method is overriden by another method (regardless of whether that method is itself a lifecycle interceptor callback interceptor method (of same or different type) ), it will not be invoked"

This is how I think this statement should be interpreted:

Let's say you created a ParentInterceptor class with @PostConstruct method init(), and a ChildInterceptor class that extends ParentInterceptor which is listed in the Interceptors annotation in a stateless session bean called MyBean:

@Stateless
@Interceptors(ChildInterceptor.class)
public class MyBean{
}

If the ChildInterceptor class does not override the init() method, then the ParentInterceptor.init() method would be invoked when stateless session bean MyBean is instantiated.

If you created method "@PostConstruct init()" in ChildInterceptor.class, than the ParentInterceptor.init() method would not be invoked and the ChildInterceptor.init() method would run when MyBean is instantiated.

If you created method init() without the @PostConstruct annotation in ChildInterceptor, then neither init() method would be invoked when MyBean is instantiated.

Remember, if you have defined a @PostConstruct method in MyBean, that method would still be invoked when you instantiate a MyBean, because it is unaffected by the overriding rules in your Interceptor class hierarchies.

This stuff gets complicated and messy when you try to think through all the permutations.

You can have several interceptor classes, each containing the same callback method. The limit refers to having the same callback method in the same class. Spec says

"a given class may not have more than one lifecycle callback interceptor method for the same lifecycle event"

However, you can have several interceptor classes as in the Pavan's post. A long as each interceptor class only defines the lifecycle callback (e.g @PostConstruct) once within a class.

The spec alludes to multiple interceptor methods containing lifecycle callbacks in the statement:
"Lifecycle callback interceptor methods may be defined on superclasses of the bean class or interceptor classes" - note the use of plurals.

This is also backed up by EJB3 In Action which has the statement:
"Note that a bean can have the same lifecycle callbacks both in the bean itself as well as in one or more interceptors."

So in Paven's example, you would annotate the session bean with:
@Interceptors( {MyInterceptorOne.class, MyInterceptorTwo.class} )

Hi,

The @PreDestroy annotation, along with the @PostConstruct is a standard lifecycle callback method for all session beans. This includes Stateful and Stateless session beans.

The @Remove annotation is only available to business methods of Stateful session beans so that the container knows when the client has finished the stateful conversation. The container can then destroy the stateful session bean and reclaim system resource. Think of the @Remove callback method as a "marker" so the container knows you have finished with the bean. The container will not destory the bean straight after it completes the @Remove method, it will still run the @PreDestroy callback. How long the stateful bean hangs around before the @PreDestroy method is actually called is up to the EJB Container vendor.

So, although it appears that the 2 callback methods do the same thing, the @PreDestroy callback method is standard for all session beans (stateful or stateless) and should be used specifically to close and release any resources such as JDBC connections.

I'd have to agree with Reddy.

I'm taking the test in a few weeks time. I've not felt comfortable with my performance in mock tests and Sun's prep test. Once I started reading the specs, I've felt a lot more comfortable.

MZ's notes are based on the specs, but I think it's well worth reading the specs carefully first, making sure you understand them fully and then using MZs notes as a refresher.

I've found EJB3 In Action to be an excellent book for learning EJB3. Once you have grasped the concepts, then the specs are actually not too bad to read. The specs will fill in all the gaps - very comprehensive.

I have needed to use Apress Pro EJB for its fantastic coverage on Transactions and Persistence Context. I've found that area so confusing and fustrating. So many different permutations of bean vs contrainer transaction demarcation, JTA vs Resource Local transactions, whether or not persistence context is propagated, when to use JoinTransaction(), what happens when you encounter application vs system exceptions ... aagggh. It's still not 100% clear to me, I expect to get the odd question wrong in this section.

Since I'm a Business Analyst and not a programmer, it's more important that I understand the general concepts. I'm happy just for a pass, and I know my development team will appreciate my efforts to better understand their world (they better ... it's been really hard work !)

Steven
OCUP Advanced
SCJP5

Congratulations on a fine effort.
Good to see the result of your hard work.

Best of luck for your next endeavour. (SCEA Maybe ?)

Steven
SCJP5
OCUP Advanced

Congrats on an excellent score.

You'll need a whole page on your CV dedicated to listing your certifications !

I'm no Java guru, but I'll contribute my opinion:

(1) Because entities are now POJOs, you can add business logic if you choose to. However, the recommendation is not to add business logic, stick to using just getter & setter methods.

(2) If you need to transport your entity across the network, I think you must implement Serializable. If you are just using your entity locally and passing it around within the same JVM, you don't need to implement Serializable. Unlike in earlier versions of EJB, where your only choice of transporting entity beans was using RMI, even if it was just a local pass.

That's my theory anyway. Anyone, please feel free to correct.

I also found the following book to be excellent for UML 2 Certification preparation:

UML 2.0 in a Nutshell - (O'Reilly))
http://www.amazon.com/UML-2-0-Nutshell-OReilly/dp/0596007957/ref=pd_bbs_sr_1/102-6425095-6800966?ie=UTF8&s=books&qid=1187787940&sr=8-1

I found the Fundamental exam tested you more on the notational side of UML2 and the semantics of each UML element, rather than your knowledge of the UML Metamodel class hierarchies.

You must still read the relevent sections of the UML Superstructure Specification to pick up the finer semantic points of each UML element. I also used the "UML 2 Certification Guide: Fundamental & Intermediate Exams" book, but found better explanations of the semantics and understanding for each UML diagram in the "UML 2.0 in a Nutshell" book and the Superstructure Specifications.

You may have to base your study on the UML Superstructure in conjunction with several other material sources to clarify the advanced concepts.

I'd recommend "The Unified Modeling Language Reference Manual, Second Edition" written by Rumbaugh, Jacobson and Booch. It's written in dictionary format, so not suitable for reading from cover to cover. However, it does explain the concepts really well and at times in depth (e.g. Association Class). Certainly better than just reading the Superstructure. It doesn't have very good coverage of OCL though.

Schaum's Outlines UML second edition by Simon Bennett, John Skelton & Ken Lunn has fairly good coverage of OCL. However, there are other areas of the OCUP Advanced syllabus that it doesn't cover.

I've come up with the conclusion that I'll need to study materials from several sources for the UML OCUP Advanced. However, in my case, I haven't decided whether I'll need to take the OCUP Advanced level because it's not really relevent to my business analysis work. Intermediate level is more than sufficient, especially when working in an agile environment. For example, why use OCL when plain English does the job ?

Anyway, that's my 2 cents. Good luck on your studies.

Congratulations, that's score is simply "sublime".

Don't just put SCJP5 on your CV, put SCJP5 95% !!