I'm actually thinking that this should be removed entirely; do we really want to pollute logs with gadget parsing failures?
On Feb 4, 2008 3:22 PM, Brian McCallister <[EMAIL PROTECTED]> wrote: > For what it's worth, I wonder if a SEVERE level log message for this makes > sense. I left the SEVER in place for now, but, umh... :-) > > On 2/4/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > Author: brianm > > Date: Mon Feb 4 15:15:57 2008 > > New Revision: 618488 > > > > URL: http://svn.apache.org/viewvc?rev=618488&view=rev > > Log: > > On gadget exception log the exception as well as the message. > > Now that exception is logged, don't print stacktrace to stderr. > > > > Modified: > > > > > incubator/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/GadgetServer.java > > > > Modified: > > > incubator/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/GadgetServer.java > > URL: > > > http://svn.apache.org/viewvc/incubator/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/GadgetServer.java?rev=618488&r1=618487&r2=618488&view=diff > > > > > ============================================================================== > > --- > > > incubator/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/GadgetServer.java > > (original) > > +++ > > > incubator/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/GadgetServer.java > > Mon Feb 4 15:15:57 2008 > > @@ -36,6 +36,7 @@ > > import java.util.concurrent.ExecutorCompletionService; > > import java.util.concurrent.Future; > > import java.util.logging.Logger; > > +import java.util.logging.Level; > > > > public class GadgetServer { > > private final GadgetServerConfig config; > > @@ -241,8 +242,8 @@ > > } > > > > if (gadgetException != null) { > > - logger.severe(gadgetException.getCode().toString()); > > - gadgetException.printStackTrace(); > > + logger.log(Level.SEVERE, gadgetException.getCode().toString(), > > gadgetException); > > + > > // Add to list of all exceptions caught, clear jobs, and > continue > > // to aggressively catch as many exceptions as possible. Since > > // tasks are running anyway, we may as well get their results > in > > > > > > >
