one more confusion over bean things

[Prashant Neginahal]

In stateful session beans ejbActivate/ejbPssivate mathod, since there is client security context, bean can access 'other resource managers and other beans'. But even in afterCompletion method, there is client security context, but bean CANNOT access 'other resource managers and other beans'. Why?

Thanks,
Prashant

[sawan parihar]

since there is client security context, bean can access 'other resource managers and other beans'

Is this true ? Because of security context the bean can access other ejbs.

[Amos Coats]

Could it be because the afterCompletion method, unlike the others, runs in a unspecified transaction context?

[Miki Muzsi]

Prashant,

You are very right this seems to be an inconsistency in the spec. The spec says:

Accessing resource managers and enterprise beans is disallowed in the session bean methods for which the container does not have a meaningful transaction context or client security context.

So since afterCompletion() does have client security context, accessing resource managers and enterprise beans should be allowed, but is not. I'm afraid you will just need to remember it for the exam :-).

See also the debate about the same issue.

Miki

[KasiMurugan Ramasamy]

Hi Guys

The intention of that method is to retain the bean state to before calling the transaction (If the transaction is failed). So that i think, they are disallowing to access the other EJB/Resource Manager.

[chowdary Thammineedi]

Hey Ranchers

At the bottom of page 79 in the spec it says that

If a session bean instance attempts to access a resource manager or an enterprise bean, and that access is
not allowed in Table 2, the behavior is undefined by the EJB architecture.

So, you can go ahead and access the resource manager and beans you want. But, the behavior you expect is not guaranteed.

By the way, "disallowed" does not mean NOT Allowed. It means to 'reject as improper'. My mother tounge is not English though, and I interpreted it as not allowed until I saw this post.
[ June 20, 2005: Message edited by: chowdary Thammineedi ]

[KasiMurugan Ramasamy]

Hi Chowdary,

Yes, your absoultely correct.

Regards
Kasimurugan R.

[Aravind Kumar]

Originally posted by Miki Muzsi:
Prashant,

You are very right this seems to be an inconsistency in the spec. The spec says:

So since afterCompletion() does have client security context, accessing resource managers and enterprise beans should be allowed, but is not. I'm afraid you will just need to remember it for the exam :-).

See also the debate about the same issue.

Miki

Its a stateful session bean. So the client's identity will be accessible in all the methods spanning from ejbCreate until the end of ejbRemove. Though afterCompletion() runs in unspecified transaction, it runs for the same client.

Aravind

[Miki Muzsi]

Aravind,

The point is:
afterCompletion()
- does have client info
- does run in an UTC and
but can NOT access 'other resource managers and other beans',

while ejbCreate() is in a similar situation:
- does have client info
- does run in an UTC
and CAN access 'other resource managers and other beans",

And the spec always motivates accessing resource managers or other ejb beans by:
QUOTE] Accessing resource managers and enterprise beans is disallowed in the session bean methods for which the container does not have a meaningful transaction context or client security context.

That is why I say is a bit of inconsistency in the spec...

Miki