Well, since Tomcat (for instance) runs the JVM you install then you get the logging and exception stuff as soon as you install 1.4,
You do NOT get it within the tomcat code, but you do within your own code. i.e. if their stuff fails then you won't see it. But if your stuff fails, or logs then you get it as soon as you use JDK1.4 (I have yet to use it in anger, I must admit - probably for the reason you just stated :) Jonathan ============================ Want to write your code as if you used EJB, but you don't? Visit: http://www.faraway.co.uk/tallsoft/lowroad/ ---------------------------------------- Message History ---------------------------------------- From: "Mark Galbreath" <[EMAIL PROTECTED]> on 28/01/2002 09:52 EST Please respond to "Struts Users Mailing List" <[EMAIL PROTECTED]> To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]> cc: Subject: RE: RES: handling exceptions That's all very good (and I especially like the inclusion of the RegExp class in 1.4) but when will we have servlet and app containers that can support with 1.4? Mark -----Original Message----- From: Jonathan Gibbons [mailto:[EMAIL PROTECTED]] Sent: Monday, January 28, 2002 8:30 AM To: Struts Users Mailing List Subject: Re: RES: handling exceptions Hi, JDK1.4 is at final release candidate stage. They include nested exceptions (including all remote exceptions) and a logging framework. Use these, and not any other version (eg log4j), you will be future proofing your CV and code. Jonathan =================== For EJB and Struts code generators see: http://www.faraway.co.uk/tallsoft/lowroad/ ---------------------------------------- Message History ---------------------------------------- From: Chuck Cavaness <[EMAIL PROTECTED]> on 28/01/2002 08:22 EST Please respond to "Struts Users Mailing List" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> cc: Subject: Re: RES: handling exceptions Unfortunately no because I think it contains some really nice features for Struts. This is a commerical product that I'm working on. However, I have received permission to discuss the exception framework in the Struts book that I'm working on for OReilly right now. Search the mailing list archives for the thread "OReilly Struts Book". Chuck At 11:02 AM 1/28/2002 -0200, you wrote: >Thanks. >I want to know if your framework of handling exception will be opensource, >like struts. > > >-----Mensagem original----- >De: Chuck Cavaness [mailto:[EMAIL PROTECTED]] >Enviada em: segunda-feira, 28 de janeiro de 2002 10:27 >Para: Struts Users Mailing List >Assunto: Re: handling exceptions > > >We've developed a pretty eloborate exception handling framework on my >current project. We're using EJB on the backend, so >we must also deal with remote type exceptions. First we catorgize >exceptions into those that the user can recover from and those that they >can't. Sort of like fatal and non-fatal. You also need to divide exceptions >into system and application exceptions. System exceptions are ones like >remote exception, or maybe some type of datastore exception. Application >exceptions for us are ones like required fields were missing or duplicate >values for a unique column. In our world, the same exception framework has >to work for ERP systems, so it's not just the web container. > >Anyway, for those exceptions that the user can recover from like "required >fields missing", we catch those type of exceptions, create an ActionError >with a message from the bundle specifically for that exception, and then >forward back to the input page. This gives the user a chance to fix the >problem and resubmit. For the more severe exceptions, we also catch those >and forward to a "system-error" type page since there's probably nothing >you can do about it anyway. We use an abstract base action that all of our >actions extend. We have all of this behavior in the base action and none of >the action classes have to worry about catching these exceptions. The >abstract base action implements the perform and has an abstract doWork type >method. The doWork method is wrapped with the try catch blocks. Each >concreate action class implements the doWork and doesn't have to worry >about the try catch. > >I hope that gives you some ideas. > >chuck > >p.s. Regarding your other post about using System.out in your action >classes; I wouldn't recommend that approach. Use log4j instead. That way, >you can shut off the debug logging externally by just editing the >log4j.properties file. > >At 09:50 AM 1/28/2002 -0200, you wrote: > >Could somebody help me ? > > > >I have to many problems with handling exception of the Struts. > >what do you suggest to handling exception of the deployment applications? > > > >-- > >To unsubscribe, e-mail: ><mailto:[EMAIL PROTECTED]> > >For additional commands, e-mail: ><mailto:[EMAIL PROTECTED]> > > >-- >To unsubscribe, e-mail: ><mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: ><mailto:[EMAIL PROTECTED]> > > > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
