Vitaliy Geraymovych

Originally posted by Ajith Kallambella:
Here is my two cents worth...

It all depends on what *your* career aspirations are. If you want to be an expert in WebLogic product suite, you must plan to take product certifications offered by BEA. However, if you want to tout yourself as an Enterprise Java Arcitect, SCEA should be your goal.

Although as you have noted WebSphere and WebLogic dominate today's J2EE implementations, I have seen plenty of job openings calling for skills in a third-party app server( Sun, Pramati, JBoss, OracleAS etc). IMO vendor certifications (obviously) focus more on product specifics whereas SCEA tends to be product agnostic. Specs, best practices, patterns, UML, SDLC process - all these constitute the repertoire of a seasoned architect and *none* of these are specific to product implementations. I am not trying to undercut the importance of "knowing your app server", but as a hiring manager, if I know that you( as a candidate) know core J2EE and all of these things, I will be willing to accept your limited(or lack of) knowledge of a particular app server. After all, how long does it take for one to read a product manual and learn the basics? Therefore, I personally value SCEA more than vendor certifications. Ofcourse, I will certainly prefer somone having both

I absolutely agree and I too prefer certifications that are based on standards. It is just after some conversations with recruiters (i.e. Do you have 5 years of Weblogic/Websphere?) I started thinking may be vendors' certifications are "better" in some sense. But I guess the correct answer would be to do both if time allows and if Weblogic (or whatever is your preference at the moment) is your career choice.

Thanks for responses.
Vitaliy

Hi guys,

I wanted to get your opinion on a subject of vendors' certifications. I am planning to take SCEA but I am also looking on Weblogic 8.1 architect certification. In my opinion certifications that cover industry standards are better (SCEA, SCBCD, SCJP, etc) but after doing some job search I see that people are looking for mostly weblogic or websphere experience.

Wouldn't pursuing vendor specific certifications make more sense? Or is it better to take both of them? What is your take on it?

Thanks in advance for all great opinions.
Vitaliy

Originally posted by Hai Lin:
Vitaliy,
If based on what you said, Bean provider only provide the abstract getter/setter, then why in HFEJB, Page 318, Complete code for the CustomerBeanCMP class, the bean proveider also gave us the concrete implemtation of all the abstract getter/setter?

Waiting for your reply.

Thanks a lot.

Hai

Hai,

Check out page 316 for a good explanation. Look specifically for notes on the right.

Vitaliy

Originally posted by Hai Lin:
Hi All, I got a question about mock question in HFEJB, Page 367,
Question 1:
What's true for a bean provider when creating an entity bean using container-managed persistence? (Choose all that apply).

A. Container-managed persistent fields must be defined in the entity bean class.
B. Container-managed relationship fields must be defined in the entity bean class.
C. When implementing a one-to-many relationship, the java.util.List interface must not be used.
D. Accessor methods for container-managed relationship fields must be exposed in the bean's remote component interface.

The answer given by the book is: C. But why A, B is not right?
(I know as for option C. Only collection or Set can be used, so C is right,
as for option D, should be local component interface, not remote component interface. Why A, B are not right? )


Please help me clarify this question?

Thanks a lot.

Bean provider only defines abstract set/get methods. Container will generate actual implementation that will have CMP/CMR fields definitions. So it is container's responsibility.

Vitaliy

Originally posted by sarah Marsh:
'Remote interface of bean A' could be the correct answer also, right?

From the top of my head CMR can not be exposed as remote interfaces. Return values of the CMR methods are always local interfaces or collections of local interfaces.

Vitaliy

Originally posted by sarah Marsh:
question:
A container-managed persistence (CMP) entity bean A has a one-to-many unidirectional relationship (CMR) to another container-managed persistence (CMP) entity bean B. Which interface can expose the methods related to this relationship?

The answer is 'Only local interface of bean A'.

Why have to be local interface?

Thanks a lot!

The relationship is UNIdirectional, means from A to B. So only A has methods to get values of B. But B got nothing.

Vitaly

Originally posted by Nicholas Cheung:
Congrad!!!

You did a cool job!!!

What's next?

Nick

Hmm, not sure yet
Probably SCWCD and SCEA.

But first a glass of beer

Vitaliy

Passed with 90% after about 2 weeks of preparations. Used HFE book. (It is great.) Referenced to the spec and used Mikalai Zaikin's SCBCD Study Guide as a review source.

Vitaliy

Originally posted by Vishy Anand:
Waiting for the reply on the above question. Any EJB expert out there, reading this?

Not an expert

But result will be true. Spec. page 66.

V.

Originally posted by Valentin Crettaz:
Alex,
I'm glad you made it work

Vitaliy,
Unfortunately, when the spec says that the session bean class has to be public, it really means it and expects that container providers enforce the rule

I guess there is a misunderstanding. I just deployed a quick example into RI server without any problems.

Here is the code:

class AdviceBeanSuper implements SessionBean {
... /* all needed stuff here, callbacks and ejbCreate */
}


public class AdviceBean extends AdviceBeanSuper {
/* actual bean*/
}

As long as I am deploying AdviceBean and not AdviceBeanSuper I am OK. I think all spec rules are correct. AdviceBean is public and implements SessionBean interface. HFE page 186 refers to inheritance in EJB.

Alex, you are not trying to deploy SB1 in your exmaple? Right? Only SB2.

Vitaly

Originally posted by Valentin Crettaz:
Your example does not conform to what the spec mandates in section 7.10.2, namely that session bean classes must be declared public.

I know this does not answer your question, but everything that does not conform to the spec is not worth investigating anyway

In my opinion the example is correct. Here is why.
We are deploying session bean SB2 which is public and implements SessionBean interface indirectly. As long as SB1 class file is accessable to SB2 and they both reside in the same package, container should be fine with it.

Vitaly

I didn't compile you code but I see that you are calling getTotalRepayment but defined getTotalyRepayment.

Vitaliy

Originally posted by Sujatha Kumar:


When a Bean instance is associated with a trasaction, it
cannot be Passivated

My understanding is that entity bean can be passivated as per spec.
Session bean cannot be passivated.

Vitaliy

Hi all,

I think there is an error in HFE on page 432. question 4.
It gives correct answers as A and B. In my opinion B is wrong
because the question states that relationship is unidirectional
from Foo to Bar so the method call from b2.getFoo() is incorrect
because it would mean that relationship is bidirectional.
I checked with the spec (p. 138) and I think I am correct.

There is also a posibility that this is a editing error.

This particular question has several mispellings:
1. E. and D. in the none of the above (already reported in the errata)
2. Answer C in has b1.getBar() on page 426 and has b1.getFoo() on page 432
3. Possibly answer B is mispelled also. If we can change it to f2.getBar() it will be correct.

What do you all think?

Vitaliy

Originally posted by mini mehta:
Hi

Sorry it should SessionContext Object.

But amazingly answers given at the SCBCD revising site are 2, 3 , 5.

Mini

HFE 203. Passivation rule

"the bean's special JNDI context, or any of its suncontexts"

However, I am not sure it means the same as in question 4. I guess 4 could mean access to the root context of JNDI or may be by environment it means beans' environment which is bean's special JNDI context.

Vitaliy

BTW. where is "SCBD revising site"?