MaxPwr Pow

nowadays, careful what you wish for. One time I had a chance to leave supply chain industry to get into the financial world, I turned it down. Why? Because I won't be traveling anymore. Somehow being on the road for a couple of months a year allows me to get away from programming.
But turning down the offer was the dumbest decision I ever made, until that financial company got into a financial scandal.
I know my reasons don't make sense, but the moral of the story is; be grateful with what you have.

i guess there is no fill-in-the-blanks Q. thanks kathy!

I'm sure Sun will tell the format of the answer for fill-in-the blank question.
Q:
If answer is a method, i.e. ejbCreate, are we supposed to put in the '()' at the end?
thanks

sudhir,
thanks for the answer. I just came across some other articles that 'link' the ejb spec to ClassLoader usage. thanks again

I'm pretty sure it is the application assembler's job to set the transaction attributes of methods, not the deployers'. In addition(don't want to make you confuse), the bean provider MAY do it too.

oppss, here are the answers from ejbcertificate:-
1. The enterprise bean cannot define read and write to static fields.
2. The enterprise bean cannot make use of the Sun JavaMail API.
3. The enterprise bean cannot make use of the Java Swing API.
4. The enterprise bean cannot make use of interfaces to define business methods.
5. The enterprise bean must not attempt to define a class in a package.

I got some leads from ejbcertification but huh?
Question from ejbcertification (check out answer 5)

Identify correct programming restrictions that a Bean provider must follow to ensure that the enterprise bean is portable and can be deployed in any compliant EJB 2.0 Container. [Check all correct answers]
Feedback:
Answer 1, 3 and 5 are correct.
Answer 1 is correct. This rule is required to ensure consistent runtime semantics because while some EJB Containers may use a single JVM to execute all enterprise bean's instances, others may distribute the instances across multiple JVMs.
Answer 3 is correct. Most servers do not allow direct interaction between an application program and a keyboard/display attached to the server system.
Answer 5 is correct. This function is reserved for the EJB Container. Allowing the enterprise bean to perform this function would create a security hole.
Answer 4 is incorrect. It is possible to create an interface and implement the interface to make available in the enterprise bean business method.
Answer 2 is incorrect. The enterprise bean can make use of the JavaMail API.

one of the EJB restriction is
"EJB must not attempt to define a class
in a package". What does this mean?
Does that mean we can't do this:-
package myPackage;
import ...
public class MyBean implements SessionBean{
:
:
}
that doesn't sound right, does it?

yes

>stateful beans can have 0(zero) to many create methods and it's optional for >it to have a create() method(the one that takes no arguments). entity bean is >not required to have create() since create for entity beans means 'a request >to insert an entity into the db"
correction: entity beans can have 0 to many create methods. Stateful beans must have 1 to many create methods and it's optional to have a create() method.

stateful beans can have 0(zero) to many create methods and it's optional for it to have a create() method(the one that takes no arguments). entity bean is not required to have create() since create for entity beans means 'a request to insert an entity into the db"

Actually, I think you want to read the book first time around. then reread it again and do the questions. I agree, some of the questions require knowledge beyond that chapter, but if you look at it from a positive side, it forces you to 'apply' the knowledge from different facets of EJB.
In conjuction with Head First, I also read the EJB spec. I think this is one of the best reading material that you can get knowledge from, in addition to sharing information with people from this group.

>My primary question was...
>1)Can we throw or declare java.rmi.RemoteException inside a business >method of any kind of bean ? lets say Entity bean...
if something goes really bad in your bean, wrap it with EJBException and container will deal with it. No, you cannot throw java.rmi.RemoteException from a business method.
>4)I just need to know why is it mentioned in the HF EJB book that u >should never throw/declare a java.rmi.RemoteException in the Bean Class.
because it is a runtime exception that is so serious that it is futile for you to continue from that point onward.

MDB MessageDrivenBean. With this book, you have to first read the whole thing, do the exercises, and then read it again - if you're new to EJB.