Rickard said:
> That is incorrect. As long as it is not the EJB doing the actual new
> Thread() call the restriction can be worked around (by doing it in the JMS
> implementation, and giving the JMS implementation the proper permissions).
If the EJBean tries to create a new JMS Session, you are going to
have trouble with the process. It will all depend on how the JMS
Provider implemented the starting of the JMS thread. It is likely that
you would have to create sessions outside of the beans....and have the
beans ask for them using some other mechanism.
The problem is that the current JMS implementations likely do not do it
in a way that is "easy" to integrate with EJB. My point is that it is
likely better to wait for the integrated EJB/JMS spec rather than
struggle to get it working now, only to have your work obsoleted in a
couple of months.
> The only times the restrictions are "hard" is when it is the actual
> beans that are doing the actual calls requiring the restricted
> permissions.
It is also very possible that a JMS publish() method could internally do
a thread wait() internally, depending on how the JMS Provider has
implemented their internal stuff. So it is possible that even a publish
(assuming that the bean could get a JMS Session from elsewhere)
might fail. All depends....
> The acquired JMS session is itself a kind of a proxy, so no surrounding
> abstraction is needed.
Not necessarily. Depends on how the Session is implemented
internally as noted above.
Andrzej Jan Taramina
Chaeron Consulting Corporation
Chaeron: - http://www.chaeron.com
===========================================================================
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".
