aspose file tools*
The moose likes EJB Certification (SCBCD/OCPJBCD) and the fly likes one more confusion over bean things Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » EJB Certification (SCBCD/OCPJBCD)
Bookmark "one more confusion over bean things" Watch "one more confusion over bean things" New topic
Author

one more confusion over bean things

Prashant Neginahal
Ranch Hand

Joined: Sep 14, 2002
Posts: 77
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


Thanks, <br />Prashant<br />SCJP, SCBCD
sawan parihar
Ranch Hand

Joined: Aug 24, 2004
Posts: 250
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.




Sawan<br />SCJP,SCWCD,SCBCD<br /> <br />Every exit is an entry somewhere.
Amos Coats
Greenhorn

Joined: Oct 11, 2004
Posts: 9
Could it be because the afterCompletion method, unlike the others, runs in a unspecified transaction context?


SCBCD SJP
Miki Muzsi
Ranch Hand

Joined: Jun 23, 2003
Posts: 120
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


Miki<br /> <br />SCJP 1.4, SCBCD 1.3
KasiMurugan Ramasamy
Ranch Hand

Joined: Jan 30, 2005
Posts: 125
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.


Thanks & Regards
Kasimurugan (SCJP1.4, SCBCD1.3), Preparing SCWCD1.4
chowdary Thammineedi
Ranch Hand

Joined: Aug 16, 2004
Posts: 126
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
Ranch Hand

Joined: Jan 30, 2005
Posts: 125
Hi Chowdary,

Yes, your absoultely correct.

Regards
Kasimurugan R.
Aravind Kumar
Ranch Hand

Joined: Nov 03, 2003
Posts: 39
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
Ranch Hand

Joined: Jun 23, 2003
Posts: 120
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
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: one more confusion over bean things