EJB Environment related questions

[Dhanesh Kothari]

1> In Question #5 and 7.
Q5:
When programming a session bean class which techniques should always be avoided to ensure bean portability across all EJB containers
A. Using java.net.Socket class
B. Using inner classes
C. Using the final modifier for the fields
D. Passing this as the argument
CORRECT ANSWER GIVEN IS "D"
Q7:
When programming EJBs which declarations should be avoided to ensure bean portability across all EJB containers
A. final int x;
B. static int x;
C. final static int x;
D. final transient int x;
CORRECT ANSWER GIVEN IS "B"
In any case, according to section 25.1.2 of specs, final should not be used at all.
So the correct answer must be
Q5: C
Q7: A, B, D
2> Question# 16:
Whats true about a legal ejb-jar file?
A. It must contain both a home and component interface
B. The DD is optional
C. It must contain J2EE classes used by the bean
D. The enterprise bean class is optional
The answer given is A.
(B, C and D are incorrect for sure)
Assuming we develop only MDBs and no other beans at all. In such a case, there is no home and remote component interfaces required.
Considering this, even A may be incorrect.
Pls clarify.

[David Harrigan]

Hi,
Using the EJB 2.0 spec.
Q5
Paraphrasing page 495 it states that thhe EJB architecture allows a bean instance to be a network socket client (so it can create a connection) so using Socket is allowable and portable.
Using Inner classes is just a Java feature that has no bearance on whether the bean is portable or not (unless you're dealing with Java 1.0 )
Final modifiers are recommended (see answer to Q7 below)
Using "this" is a no-no, see Page 496 on this, instead the bean should use getEJBOBject, etc.. instead.
So answer D is correct.
Q7.
Pages 494 and 538 state:

An enterprise Bean must not use read/write static fields. Using read-only static fields is allowed. Therefore, it is recommended that all static fields in the enterprise bean class be declared final.

So B is correct.
Q16
Good point. But, the question has to be understood correctly. The question is asking what, given the options below, constitutes a legal ejb-jar file? Now, the only correct one is A as you rightly point out. It does not ask anything about MDB's and we *know* it's a legal ejb-jar file since that is what the question is asking.
However, your point is well taken. According to the spec, if you *only* include a MDB in the ejb-jar AND you don't reference (or include) any other enterprise bean classes, home or component interfaces or a primary key class then it's not a valid ejb jar.
-=david=-
[ January 07, 2004: Message edited by: David Harrigan ]
[ January 07, 2004: Message edited by: David Harrigan ]

[Dhanesh Kothari]

Thanks for the reply.
I was going thru the specs to find out the rules for valid or legal ejb-jar file. But could not find any explicit rule(s) for MDBs.
So I guess we need to take it as it is.
So if I'm an Application Assembler or Deployer and I receive ejb-jar packaged only with MDBs. I'll say "according to specs these files are invalid, but I'll still go ahead and take it".
Regards,
- Dhanesh

[David Harrigan]

Actually, I've just thought about this again.
Having a ejb-jar that just contains a the MDB is a valid ejb-jar, since a MDB is still an Enterprise Bean, so it meets requirement 1 of what constitutes a valid ejb-jar file. I guess what isn't clear that you don't need the home or component interfaces in this case in the jar
(just like it points out that the primary key class is not required if the enterprise bean isn't an entity bean).
-=david=-

[Dhanesh Kothari]

Thats exaclt what my point is.
I'm not sure if Kathy has looked at this post already. If someone can inform her or tell me where to reach her.
Do we need a change in the specs then ?
-Dhanesh