Yes, I know that the EJB programming restrictions have been discussed frequently in the past. The discussions often end with Rickard �berg's saying that the restrictions only apply to classes loaded with the same classloader as the EJBs.
However this classloader distinction is not explicitly specified in the EJB 2.0 spec's "Programming Restrictions" (sect. 24.1.2). What bothers me is that that use of a different classloader may be more a way of avoiding getting caught by the container's security policy, then a fulfillment of the intentions of the spec writers. Why does this matter? At GroupServe, we are writing code to allow use of Jini services from EJBs. (See jini.groupserve.com). For example, Jini makes frequent use of listener objects, which are prohibited by the EJB restrictions. I need to know where I can put these listeners without violating the restrictions. (The listeners will then use message-driven beans to pass information into the EJB container.) Since the spec was not specific, I'm afraid that what one can do may depend on the specific EJB server implementation. Possibly the only truly safe place for classes that disobey the restrictions is on a separate JVM. Can anyone shed any light on this? =========================================================================== 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".
