Right, right, I see your point. JRun's main() method isn't really be the
main() method when JRun's being embedded, because there can only be one true
main() method in a stand alone Java app. Obviously an embedding app will
(must) have its own main() and should have control over when the JVM exits.
All this is well and good. Like I said originally, it's a reasonable
request; I just wanted some real world example(s) of why allowing JRun to
exit the JVM when it's embedded is a problem. Because obviously it isn't
for everybody. I don't know why OEMs didn't raise this issue before, or
maybe they did and I'm not aware of it.
Scott Stirling
Allaire Corporation
http://www.allaire.com/developer/jrunreferencedesk/
> -----Original Message-----
> From: Paul Fink [mailto:[EMAIL PROTECTED]]
> Sent: Monday, August 28, 2000 11:14 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Another Example of the problem with JRun3.0
> exit() behavior
>
>
> Confusion over the use of the word "main".
>
> JRun's main method is not the main.
> In fact this is my main point.
>
> Scott Stirling wrote:
> >
> > OK, let's step back a sec. JRun does call exit() from its
> main method, OK?
> > And that's the only place. You seem to have implied that
> JRun calls exit()
> > whenever it gets an exception, which is not the case. The original
> > complaint was that a user wanted to be able to shutdown an
> embedded JRun
> > without JRun shutting down the JVM. This is do-able, but
> it will require
> > that the main method in the JRun class be changed so that
> JRun can be
> > stopped and clean up all its resources without calling
> System.exit().
------------------------------------------------------------------------------
Archives: http://www.egroups.com/group/jrun-interest/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/jrun_talk
or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the
body.
