JMS is defined in 1.1 as being one of the resources under the EJB
container's control (like JDBC). That means that:
1. JMS codebase runs in a similar security policy to that of the EJB
server (i.e. all or most permissions).
2. JSM codebase can create a new thread if it needs to, even if the Bean
does not have such permission, using a PrivilegedAction.
3. The EJB server is responsible for managing the JMS resource
associated with the bean, e.g. automatically terminating it if an
exception occured while talking to the bean.
I haven't delved into the JMS specs yet, but I believe it was said to
support XAResource, making it easy to manage through the TM.
arkin
"Rickard �berg" wrote:
>
> Hi!
>
> Andrzej Jan Taramina wrote:
> > Actually I do not believe you are correct in this.....to be a JMS
> > Message producer you need to have an open JMS Session. Session's
> > implement Runnable and usually start a separate thread for their JMS
> > operations when you create one. This means that an EJB cannot
> > create a JMS Session...and without one you cannot do any message
> > production.
>
> 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).
>
> The only times the restrictions are "hard" is when it is the actual
> beans that are doing the actual calls requiring the restricted
> permissions.
>
> This is what I have been saying from the beginning. Do you believe this
> to be incorrect? If so, why?
>
> > Just like with message consumers, I belive you would have to build
> > external proxies for both message sending and production because of
> > this.
>
> The acquired JMS session is itself a kind of a proxy, so no surrounding
> abstraction is needed.
>
> > Not worth the effort since the next EJB spec will integrate JMS
> > functionality and allow EJBeans to be both message producers and
> > consumers. I believe the current thinking on the integration is that the
> > container would supply the "proxies" to the core JMS functionality on
> > behalf of the beans, so the restriction on use of threads in EJBeans will
> > not be restricted.
>
> Providing proxies to the JMS implementation seems unnecessary, as there
> are no restrictions on the actions available to the underlying JMS
> implementation. Can you outline why they are needed?
>
> /Rickard
>
> --
> Rickard �berg
>
> @home: +46 13 177937
> Email: [EMAIL PROTECTED]
> Homepage: http://www-und.ida.liu.se/~ricob684
>
> ===========================================================================
> 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".
--
____________________________________________________________
Assaf Arkin [EMAIL PROTECTED]
CTO http://www.exoffice.com
Exoffice, The ExoLab Company tel: (650) 259-9796
===========================================================================
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".
