Hi Jian,
Jian Lin wrote:
> When a bean's method is called, access control can be enforced by the container
> according
> to the caller's role. However, if a bean's method is invoked from another
> method within the bean
> itself, then the container is not involved and access control is not checked.
> The question: how
> is it possible to have same container-managed access control policy enforced for
> methods
> invoked within a bean itself?
>
> For session beans, it does not seem possible to force a method call from within
> the bean through
> the container using the bean's remote interface because method calls are
> serialized by the
> container and thus "loopback" call is not allowed.
You right. But there is no need to invoque a business method from within the session
bean.. A session bean may instantiate another session of the same type to invoque
the same or another business method. You can also use this pattern to implement
session bean loop. Wether it is a good design practice depends on your requirements.
>
>
> For entity beans, "loopback" call can be enabled by marking an entity bean
> re-entrant.
> But re-entrant entity beans are not particularly desirable according to the EJB
> spec
> (Section 9.1.12, ejb1.1).
>
> Is the above assessment correct according to the spec? Any suggestions or
> solutions?
Yes.
For entity beans, you can also achieve a loopback using :
eJBContext.getEJBObject().call(...) ;
Regards.
Francis.
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
