George, I think you hit the nail on the head when you said to use "separate JVM". The problem in using listeners in EJB is that there is no where to attach them. In other words, you can create a listener, but you cannot attach it to an EJB.
There is nothing wrong in using a separate JVM to host the listeners, and then when an event occurs, post a message using JMS or make a call onto an appropriate EJB. The separate JVM can be a client application which is started at the same time as the server. -AP_ www: http://www.alexparansky.com -----Original Message----- From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]]On Behalf Of George Pearson Sent: Friday, December 14, 2001 12:30 PM To: [EMAIL PROTECTED] Subject: EJB restrictions redux 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". =========================================================================== 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".
