Best way to halt Java process?
in [Java Programming]
|
Prev: encrypted javamail MimeMultipart
Next: Urgent DIRECT CLIENT Openings: 1.Websphere Portal - Developer, 2.ITIM-TAM Analyst, 3. IT Project Coordinator / Project Analyst
From: Arne Vajhøj on 11 Jun 2010 19:13 On 11-06-2010 01:52, ClassCastException wrote: > On Thu, 10 Jun 2010 20:38:23 -0700, Mike Schilling wrote: >> But even without that, there's no need for anything but a private field >> used by the (single) instance of the servlet class. > Global variables by any other name ... *sigh* No. public static is a global variable - private not-static is not. Arne
From: Arne Vajhøj on 11 Jun 2010 19:17 On 10-06-2010 23:38, Mike Schilling wrote: > "ClassCastException" <zjkg3d9gj56(a)gmail.invalid> wrote in message >> Does the servlet<->container API/protocol/whatever not include an >> explicit way for a servlet to signal a fatal error to the container? Let >> alone to perform just-once initialization, prior to handling requests, >> which can fail? > > Yeah, that you can do. There's an init() method, and if it throws an > exception the servlet is never enabled (at least, in containers I know > of. Not sure if that's part of the spec.) The servlet specs say: <quote> During initialization, the servlet instance can throw an UnavailableException or a ServletException. In this case, the servlet must not be placed into active service and must be released by the servlet container. The destroy method is not called as it is considered unsuccessful initialization. </quote> so if the exception thrown is a ServletException, then there are no servlet available. Arne
From: Mike Schilling on 11 Jun 2010 21:50 "Arne Vajhøj" <arne(a)vajhoej.dk> wrote in message news:4c12c41f$0$280$14726298(a)news.sunsite.dk... > On 10-06-2010 23:38, Mike Schilling wrote: >> "ClassCastException" <zjkg3d9gj56(a)gmail.invalid> wrote in message >>> Does the servlet<->container API/protocol/whatever not include an >>> explicit way for a servlet to signal a fatal error to the container? Let >>> alone to perform just-once initialization, prior to handling requests, >>> which can fail? >> >> Yeah, that you can do. There's an init() method, and if it throws an >> exception the servlet is never enabled (at least, in containers I know >> of. Not sure if that's part of the spec.) > > The servlet specs say: > > <quote> > During initialization, the servlet instance can throw an > UnavailableException or a > ServletException. In this case, the servlet must not be placed into active > service > and must be released by the servlet container. The destroy method is not > called as it > is considered unsuccessful initialization. > </quote> > > so if the exception thrown is a ServletException, then there > are no servlet available. Cool. I'd be surprised if, say, Tomcat enabled servlets for a web app whose init() method threw a RuntimeException either.
From: Arne Vajhøj on 11 Jun 2010 22:09 On 11-06-2010 21:50, Mike Schilling wrote: > "Arne Vajhøj" <arne(a)vajhoej.dk> wrote in message > news:4c12c41f$0$280$14726298(a)news.sunsite.dk... >> On 10-06-2010 23:38, Mike Schilling wrote: >>> "ClassCastException" <zjkg3d9gj56(a)gmail.invalid> wrote in message >>>> Does the servlet<->container API/protocol/whatever not include an >>>> explicit way for a servlet to signal a fatal error to the container? >>>> Let >>>> alone to perform just-once initialization, prior to handling requests, >>>> which can fail? >>> >>> Yeah, that you can do. There's an init() method, and if it throws an >>> exception the servlet is never enabled (at least, in containers I know >>> of. Not sure if that's part of the spec.) >> >> The servlet specs say: >> >> <quote> >> During initialization, the servlet instance can throw an >> UnavailableException or a >> ServletException. In this case, the servlet must not be placed into >> active service >> and must be released by the servlet container. The destroy method is >> not called as it >> is considered unsuccessful initialization. >> </quote> >> >> so if the exception thrown is a ServletException, then there >> are no servlet available. > > Cool. I'd be surprised if, say, Tomcat enabled servlets for a web app > whose init() method threw a RuntimeException either. Me too. But give the specs, then I would consider it worth catching and throwing a ServletException just be 100% compliant. Arne
From: ClassCastException on 11 Jun 2010 23:41
On Thu, 10 Jun 2010 22:55:59 -0700, Mike Schilling wrote: > "ClassCastException" <zjkg3d9gj56(a)gmail.invalid> wrote in message > news:husivb$hsb$3(a)news.eternal-september.org... >> On Thu, 10 Jun 2010 20:38:23 -0700, Mike Schilling wrote: >> >>> "ClassCastException" <zjkg3d9gj56(a)gmail.invalid> wrote in message >>> news:hus9o8$g1n$6(a)news.eternal-september.org... >>>> On Thu, 10 Jun 2010 19:54:51 -0700, Mike Schilling wrote: >>>> >>>>> "ClassCastException" <zjkg3d9gj56(a)gmail.invalid> wrote in message >>>>> news:hus76c$g1n$2(a)news.eternal-september.org... >>>>>> I think the usual situation will be that a) you don't catch Error >>>>>> and b) servlet containers etc. run servlets etc. in separate >>>>>> threads and deal with it gracefully if any of these threads abends. >>>>>> If you have multiple threads, provide some interrupt mechanism that >>>>>> can be triggered. >>>>> >>>>> A servlet container will handle each request in a separate thread, >>>>> and direct that thread to the servlet that should handle it. One >>>>> request's thread erroring horribly doesn't prevent further requests >>>>> from being processed by that same servlet. Preventing any further >>>>> processing would require some management operation that disables the >>>>> servlet, or more likely its containing web application. >>>> >>>> Euuww. That means you need to tell the servlet container to >>>> unregister you, or else set a public static mutable error flag that >>>> makes all subsequent instances prompt-fail, or something. Global >>>> variables. Ick! >>>> >>>> Does the servlet<->container API/protocol/whatever not include an >>>> explicit way for a servlet to signal a fatal error to the container? >>>> Let alone to perform just-once initialization, prior to handling >>>> requests, which can fail? >>> >>> Yeah, that you can do. There's an init() method, and if it throws an >>> exception the servlet is never enabled (at least, in containers I know >>> of. Not sure if that's part of the spec.) >> >> Ah, then Todd should probably be doing these checks in the init() >> method and throwing an exception if they fail. >> >>> But even without that, there's no need for anything but a private >>> field used by the (single) instance of the servlet class. Multiple >>> threads -- single instance. >> >> Global variables by any other name ... *sigh* > > A private instance field is a global variable? Not normally, but in this case it's sort-of one in disguise. I guess most of the evil goes away since you can at least instantiate more than one of the servlet without them stepping on each other's toes. Still leaves a bit of a bad taste in my mouth. It would be nicer if the servlet container better handled this. |