ejbActivate

[jeff mutonho]

On page 354 HF EJB , the things one can do during activation are listed as :

Can use the EntityContext to:
1)get reference to your home
2)get reference to your EJB object
3)get your primary key.

I dont understand why we cannot use the EntiryContext to "get security infromation about the client".For ejbActivate to be called , its because the client has called a business method on the EJB object , and hence needs the service of the bean.

[Peer Reynders]

Bean Things are confusing!! may shed some light on things.

[jeff mutonho]

Thanks Peer.I appreciate your pointer , but I'll be honest and say the explanation there isn't clear, to me ,that is.I checked what the spec says on page 180 :

� Invoking the getCallerPrincipal and isCallerInRole methods is disallowed in the entity bean methods for which the Container does not have a client security context.

Fine , but then how can the container NOT have a client security context , when it was the client who invoked a business method that resulted in he calling of ejbActivate on the bean.Surely the container should know who caused it to activate the bean.Or am I totally lost here ?

jeff mutonho

[jeff mutonho]

Or is it that the container just doesn't bother with knowing the client security context as it DOES NOT consider the ejbActivate() call a "meaningful transaction context" ?

jeff mutonho

[Peer Reynders]

Originally posted by jeff mutonho:
It was the client who invoked a business method that resulted in he calling of ejbActivate on the bean.

The point that I tried to make in the fifth post of Bean Things are confusing!! is that the specification is giving the server the freedom to complete the ejbActivate before a client invokes a business call in order to serve that future invocation by a client faster - clearly it would only want to do that for entities that in the (recent) past were in high demand - i.e. it is highly likely that there will be a call coming in for that entity "any time now".

In the ejbActivate you can already perform JNDI lookups which can be "slow/expensive". You can get a hold of your component interface which you will return in place of "this", similarly you can get the home interface.
The peculiar one is getPrimaryKey. This is useless if the object-model was designed first because the data model will usually use synthetic keys only - these keys belong in the category of an existence based identity - i.e. the key has no further meaning other than uniquely identifying the entity's existence.
In systems where the data model came before the object-model however you can encounter value based identities - usually a compound key of fields that uniquely identify the entity. These compound keys can include discriminator fields that can be used to configure the entity bean - even before you run ejbLoad.

So again I state that the specification disallows the access to client specific functions in the ejbActivate so that the server may complete the ejbActivate even before a client invokes a business method on that entity bean.
[ October 27, 2005: Message edited by: Peer Reynders ]

[B.Sathish]

Jeff,
There will be a lot of surprises like thisin Bean Things. My advice to you for the exam would be not to look too much into these and just work out a way to remember them for the exam

[jeff mutonho]

So again I state that the specification disallows the access to client specific functions in the ejbActivate so that the server may complete the ejbActivate even before a client invokes a business method on that entity bean.

Makes sense.Thanks guys for your responses