-----Original Message----- From: Sven E. van �t Veer [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 24, 2002 11:05 AM To: Juan Pablo Lorandi Subject: RE: Is Exec() allowed in EJB
> > 3) Prohibiting launching threads instead of forcing EJB-Container > implementors to elliminate the possibility makes it easier to build > EJB-Servers. I think that here you are right on target, it�s more or less what the spec sais about this 'These functions (...) decrease the ability of the container�s ability to properly manage the runtime environment' I think this is a lot of bla-bla to make it easier to develop ejb container. It�s the other part of the 'why' in the spec that I think is funny; how can threads compromise security ?? > I've launched threads on my applications, in fact, you may do so from > Servlets/JSPs (_that_ spec doesn't prohibit it). There are some > maintenance tasks that I perform asychronously from threads; I think I > could probably have coded some kind of client that continually hits a > web page to perform them, but that would also had sprung other problems, > mostly post-delivery. My point is there are such times in which > spawining a thread IS the optimal solution. I hope this provides more > information to identify which ARE and AREN'T the times when you should > venture. Well, the spec may prohibit the enterprise bean to spawn a thread, but it tells nothing about the enterprise bean calling another class that spawns a thread. Same goes for the java.io package. No IO, no logging right .. 'an enterprise bean must not etc.' now can I use logging (log4J for example) or not .. The explanation is even more ridiculous : 'The file system api are not well-suited for business components to access data. Business components should use a resource manager API such as JDBC, to store data.' I can think of a lot of things I might want to do with a simple call to a file system where i don�t want or need the overhead of transactions. Besides, some information I might need might only exist on the file system, or, one of my business needs might simply be the creation of a flat file in some pre-defined format, to send to my bank to make payments or whatever. This is a legitimate business need to be implemented in enterprise applications. I really do not understand the why behind this. > > My 2c, > > Juan Pablo Lorandi > Chief Software Architect > Code Foundry Ltd. > [EMAIL PROTECTED] > > Barberstown, Straffan, Co. Kildare, Ireland. > Tel: +353-1-6012050 Fax: +353-1-6012051 > Mobile: +353-86-2157900 > www.codefoundry.com > > > > -----Original Message----- > > From: A mailing list for Enterprise JavaBeans development > > [mailto:[EMAIL PROTECTED]] On Behalf Of Tim Endres > > Sent: Tuesday, July 23, 2002 2:56 PM > > To: [EMAIL PROTECTED] > > Subject: Re: Is Exec() allowed in EJB > > > > > > You should never spawn threads. Ergo, you should not call exec(). tim. > > > > > Thanks for the reply. On the same lines, do you think it is ok to > > > spawn java threads in helper classes that are used by the > > EJB? Please > > > note that the helper classes are part of the same "jar" > > that contains > > > the EJB. > > > > > > To re-state, what I want to know is this: The spec doesn't allow > > > spawning threads from the bean classes, but is is it okay to use > > > "synchronization" primitive and to spawn threads from the helper > > > classes that are used by the beans? > > > > > > Thanks. > > > > > > Venki > > > > > > ----- Original Message ----- > > > From: "Sven E. van ?t Veer" <[EMAIL PROTECTED]> > > > To: "Venki" <[EMAIL PROTECTED]> > > > Sent: Tuesday, July 23, 2002 8:35 AM > > > Subject: RE: Is Exec() allowed in EJB > > > > > > > > > > FAIK, The ERB spec does not allow this. I see no reason > > however that > > > helper > > > > classes cannot do this. > > > > > > > > -----Original Message----- > > > > From: A mailing list for Enterprise JavaBeans development > > > > [mailto:[EMAIL PROTECTED]]On Behalf Of Venki > > > > Sent: Tuesday, July 23, 2002 9:05 AM > > > > To: [EMAIL PROTECTED] > > > > Subject: Fwd: Is Exec() allowed in EJB > > > > > > > > > > > > I am resending the message as I the email that I sent earlier > > > > bounced back. I apologize for any inconvenience. > > > > > > > > ==========================Forwarded > > > > message========================== > > > > > > > > > > > > Hi, > > > > I have implemented a stateless session bean that calls a helper > > > > class. I am spawn a process from a method in the helper > > class using > > > > runtime.exec(). > > > > Given that spawning threads is not allowed in the EJB server > > > environment. > > > > Is spawning processes okay? Is it not equivalent to > > spawning threads > > > > which are nothing but light weight processes? > > > > I need answers quite urgently. If anybody has > > experience in this > > > > pls do let me know. Thanks. > > > > > > > > Venki > > > > > > > > ----- End forwarded message ----- > > > > > > > > > > > > > ====================================================================== > > > ===== > > > > 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". > > > > --- > > > > Incoming mail is certified Virus Free. > > > > Checked by AVG anti-virus system (http://www.grisoft.com). > > > > Version: 6.0.377 / Virus Database: 211 - Release Date: 15/7/2002 > > > > > > > > --- > > > > Outgoing mail is certified Virus Free. > > > > Checked by AVG anti-virus system (http://www.grisoft.com). > > > > Version: 6.0.377 / Virus Database: 211 - Release Date: 15/7/2002 > > > > > > > > > > > > ====================================================================== > > > ===== > > > 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". > > > > ================================================================== > ========= > 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". > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.377 / Virus Database: 211 - Release Date: 15/7/2002 > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.377 / Virus Database: 211 - Release Date: 15/7/2002 =========================================================================== 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".
