Couple of questions

[Vipin Mohan]

hello friends
I have a couple of questions bothering me, while preparing for SCBCD. Can someone please help me with these ?
1. If there are no method permissions specified for a method, does it mean that anyone can access the method ? Or does it mean that no one can access it ?
2. Can a remote client send JMS messages to a destination on a remote computer ? If yes, then while getting a reference to the Topic or Queue through a JNDI lookup, do we need to perform PortableRemoteObject.narrow() on it ?
3. When a client calls create() on an entity bean, which action takes place first ? Binding the bean with an EJBObject or ejbCreate() invocation ?
Thanks in advance
Vipin

[Steve Agarwal]

hello friends
I have a couple of questions bothering me, while preparing for SCBCD. Can someone please help me with these ?
1. If there are no method permissions specified for a method, does it mean that anyone can access the method ? Or does it mean that no one can access it ?
2. Can a remote client send JMS messages to a destination on a remote computer ? If yes, then while getting a reference to the Topic or Queue through a JNDI lookup, do we need to perform PortableRemoteObject.narrow() on it ?
3. When a client calls create() on an entity bean, which action takes place first ? Binding the bean with an EJBObject or ejbCreate() invocation ?
Thanks in advance
Vipin
*******************************************************************
My input
1) if no method permission specified then no one can access.
2) Sending message to remote Server using JMS has nothing to do narrow and all. narrow is a RMI concept and it has to do with object location. Where as in JMS we are sending evry thing as Message. So I donw see this portablility issues comming up.
3) I would say seq is like this -- new instance creation, setEntityContext, ejbCreate. So by the end of ejbCreate the bean comes into picture with primary key and RemoteObject reference. all these stages mentioned are responsibility of Container. So ejbCreate is the first to be called.
Please correct me if I am wrong.
steve

[Kathy Sierra]

Howdy -- I just wanted to add a couple of things...
1) Security -- a method needs to be in one of these three conditions:
1) assigned to security roles that can access the method
OR
2) marked as "unchecked"

OR
3) listed in the exclude-list element
It is up to the Deployer to make sure that all methods are specified in one of these ways. What happens if you do not? That's up to your Container. It may fail to deploy your bean (and in fact, it probably *should* refuse to deploy), but of course your deployment tools might take care of the security permissions by simply assigning your method to it's default (such as 'guest') security roles, etc.

2) ejbCreate()
Remember, when the client calls create() on an entity bean, this does NOT cause a new entity bean instance to be created!! So, this would not give you new instance creation, etc.
Usually, it just means that the bean comes out of the pool with an ejbCreate(), and that may be the ONLY method the bean really gets! Remember, there is a difference between *entity* creation and *bean instance* creation.
*Entity* creation is when a new 'entity' is inserted into the underlying database. This happens because the client calls create(), and normally means the bean comes out of the pool with an ejbCreate() call (not ejbActivate()).
*Bean instance* creation happens when the Container decides to put a new bean into the pool (which may, *indirectly*, happen because there was no bean in the pool at the time the client called create(), but these two things are really unrelated).
When a bean instance is created, the Container makes the new instance, calls setEntityContext(), and puts the bean into the pool... without an ejbCreate().
So...
1) Bean instance creation: bean instance is made, and setEntityContext() is called
2) Entity creation: beans comes out of the pool to run the ejbCreate() method
What about the EJB object? The creation of the EJB object is completely separate from *either* of those two situations. All you know for certain is that the EJB object is *assigned* to the bean in one of these two ways:
1) *immediately* following the ejbCreate(), and before the ejbPostCreate(), for a newly-created entity
OR
2) when the bean comes out of the pool via ejbActivate(), when the bean is assigned to *play* a particular entity (say, Fred Smith #42).
The Container can make these EJB objects whenever and however it wants to. They aren't assigned to beans when beans are in the pool. Think of the EJB object as something for the 'client', rather than the bean, but the bean temporarily comes out of the pool and gets 'attached' to one, depending on which entity the bean is supposed to BE at that particular time (Fred Smith, Janet Foo, etc.)
cheers,
Kathy

[Steve Agarwal]

I have a doubt...
Entity beans are persistence objects. And they are there in container once created. And to my understanding they ( entity beans if exists ) need to be shared to the client who is trying to create similar bean with same primary key. So why a entity bean need to go for passivation.
to this lets(passivation proved) say there is no association of client to a entity bean so will that bean get destroyed. As far as I know calling remove on a bean removes data from database. But I dont want to remove data but want to associate a bean to a row in a table( entity bean ) and then drop it( bean -- JVM representation of data in container ) later.
Steve