 |
 |
Hi Jeremy, What was wrong with the old logger that it required such a drastic change? Also, shouldn't you have let us know you were going to do this before you went ahead and made the change? I agree with Nathan, this needs to be changed so we don't need to use the wrapper script. On Wed, Oct 7, 2015 at 12:42 PM, Nathan Baltzell <[log in to unmask]> wrote: > Will you make it so the old command line still works? > > > > On Oct 7, 2015, at 15:29, McCormick, Jeremy I. <[log in to unmask]> > wrote: > > > Yes, you should change it by adding the new Java property.... > > > > java > -Djava.util.logging.config.class=org.hps.logging.config.DefaultLogging -jar > hps-distribution-bin.jar org.hps.evio.EvioToLcio [args] > > > > Or if trunk/distribution is available run it from the generated script > which does this automatically. > > > > -----Original Message----- > > From: Nathan Baltzell [mailto:[log in to unmask]] > > Sent: Wednesday, October 07, 2015 12:25 PM > > To: McCormick, Jeremy I. > > Cc: Hansson Adrian, Per Ola; hps-software > > Subject: Re: cleanup of logging in hps-java > > > > This does not require changing the command line used for EvioToLcio, > right? > > > > > > > > > > On Oct 7, 2015, at 15:21, McCormick, Jeremy I. < > [log in to unmask]> wrote: > > > >> The level on the logger is null here because it was never set. Loggers > that are created with getLogger() don't actually have a "default" level (it > is null by default) and the global level will get used instead in this case. > >> > >> So you have to load the new default config explicitly for all the > package loggers to be assigned levels. > >> > >> java > >> -Djava.util.logging.config.class=org.hps.logging.config.DefaultLogging > >> Config -jar [etc.] > >> > >> Or you can instead run the wrapper script for EvioToLcio that's > generated when you 'mvn' distribituion. > >> > >> distribution/target/appassembler/bin/evio2lcio.sh > >> > >> This script includes that bit of setup automatically, so that's > probably the preferred option now for running EvioToLcio. > >> > >> -----Original Message----- > >> From: Hansson Adrian, Per Ola > >> Sent: Wednesday, October 07, 2015 12:13 PM > >> To: McCormick, Jeremy I. > >> Subject: Re: cleanup of logging in hps-java > >> > >> EvioToLcio run: > >> > >> > >> Oct 07, 2015 12:05:07 PM org.hps.evio.LCSimEngRunEventBuilder > >> makeLCSimEvent > >> SEVERE: General error making SVT hits. > >> java.lang.NullPointerException > >> at > >> org.hps.evio.SvtEventHeaderChecker.checkSvtHeaders(SvtEventHeaderCheck > >> er.java:89) at > >> org.hps.evio.AugmentedSvtEvioReader.processSvtHeaders(AugmentedSvtEvio > >> Reader.java:35) at > >> org.hps.evio.AbstractSvtEvioReader.makeHits(AbstractSvtEvioReader.java > >> :286) at > >> org.hps.evio.LCSimEngRunEventBuilder.makeLCSimEvent(LCSimEngRunEventBu > >> ilder.java:157) at org.hps.evio.EvioToLcio.run(EvioToLcio.java:572) > >> at org.hps.evio.EvioToLcio.main(EvioToLcio.java:94) > >> > >> > >> Actually the error happens on line 87 and not 89 (I added a debug to > check exactly what did it). > >> > >> /Pelle > >> > >> On Oct 7, 2015, at 12:10 PM, McCormick, Jeremy I. < > [log in to unmask]> wrote: > >> > >> > >> Yeah, I tested it. Where are you seeing this? > >> > >> -----Original Message----- > >> From: Hansson Adrian, Per Ola > >> Sent: Wednesday, October 07, 2015 12:04 PM > >> To: McCormick, Jeremy I. > >> Subject: Re: cleanup of logging in hps-java > >> > >> > >> Did you try running after updating? I get null pointer exceptions > everywhere this is called? > >> > >> LOGGER.getLevel().intValue() > >> > >> > >> On Oct 7, 2015, at 11:57 AM, McCormick, Jeremy I. < > [log in to unmask]> wrote: > >> > >> > >> I moved all the rest of the tracking detector classs to lcsim too, > so > >> you should probably be more worried about that. :) > >> > >> -----Original Message----- > >> From: Hansson Adrian, Per Ola > >> Sent: Wednesday, October 07, 2015 11:56 AM > >> To: McCormick, Jeremy I. > >> Subject: Re: cleanup of logging in hps-java > >> > >> > >> oh man... > >> > >> On Oct 6, 2015, at 6:56 PM, McCormick, Jeremy I. < > [log in to unmask]> wrote: > >> > >> > >> > >> Hi, > >> > >> I cleaned up how we are using the Java logging API in HPS Java > today by doing the following.... > >> > >> 1) Usage of the the LogUtil class from lcsim was replaced by the > Logger.getLogger() method. > >> > >> 2) Naming of static Logger objects was standardized to "LOGGER" > across all classes. > >> > >> 3) Classes will now create or use a logger that is named for their > package rather than their class name e.g. > >> > >> private static final Logger LOGGER = > >> Logger.getLogger(MyClass.class.getPackage().getName()); > >> > >> instead of > >> > >> Logger.getLogger(MyClass.class.getName()); > >> > >> This makes it much easier to configure the logging output for sets > of related classes by their package rather than needing to set levels for > every class. > >> > >> 4) A new logging module was added to the build, with a global > logging > >> configuration file under > >> > >> > logging/src/main/resources/org/hps/logging/config/logging.properties > >> > >> which contains default log levels for all hps-java packages. > >> > >> 5) A default log setup class was added under > >> > >> > >> logging/src/main/java/org/hps/logging/config/DefaultLoggingConfig.java > >> > >> which loads the classpath resource from #4 that provides global > defaults. > >> > >> This will be automatically activated for all test cases, and it > will also be setup automatically by the wrapper scripts generated from the > distribution build (under target/appengine/bin). > >> > >> 6) The methods for setting the log level on the > DatabaseConditionsManager were removed in favor of using the standard > logging API. > >> > >> 7) Custom log level settings on various classes were mostly > removed in favor of using the levels defined in the logging.properties > classpath resource. > >> > >> 8) There are no longer individual "handler" classes created for > each logger. There should be just one global console handler now, so the > messages from different loggers should always show up in order. > >> > >> 9) Related to #8, all of the calls to > "logger.getHandlers[0]().flush()" were removed as they should no longer be > needed. The console output should be flushed predictably and automatically > now. > >> > >> 10) The default message format was changed so that the entire log > record appears on a single line instead of two like before. > >> > >> For instance, here is a sample message > >> > >> INFO: I am enabled [Tue Oct 06 18:47:39 PDT 2015] > org.hps.detector.svt.SvtDetectorSetup conditionsChanged > >> > >> The format is basically now: > >> > >> LEVEL: MESSAGE [DATE] SOURCE > >> > >> We can change this easily in the properties file if a different > format is desired (date printed first perhaps?). > >> > >> -- > >> > >> That covers most of the changes that I made to the trunk. > >> > >> If you want to customize the logging behavior from jobs that are > run with the "java -jar" command, there are two different settings that can > be used. > >> > >> You can activate the default classpath resource as follows: > >> > >> java > >> > -Djava.util.logging.config.class=org.hps.logging.config.DefaultLogging > >> Config [args] > >> > >> Or you can provide your own customized logging properties file: > >> > >> java > >> > -Djava.util.logging.config.class=org.hps.logging.config.file=mylogging > >> .properties [args] > >> > >> There are more details about how this all works at the following > URLs: > >> > >> includes details on setting the logging properties from the command > >> line > >> > http://docs.oracle.com/javase/7/docs/api/java/util/logging/LogManager. > >> html > >> > >> how to provide a custom formatting string for the mssages > >> > http://docs.oracle.com/javase/7/docs/api/java/util/logging/SimpleForma > >> tter.html#format%28java.util.logging.LogRecord%29 > >> > >> example of configuring logging via a properties file > >> http://tutorials.jenkov.com/java-logging/configuration.html > >> > >> Overall, the logging should now be much better organized and > easier to configure, and it is more in line with how logging configuration > is supposed to be done in Java applications, e.g. using the standard > logging API and customizing the behavior via a properties file. > >> > >> You should definitely 'svn up' the hps-java trunk immediately to > get these changes, as many files were changed and there is the possibility > of (minor) conflicts having been created in your local copy. > >> > >> If you have any questions about these changes or need help/advice, > then please let me know! > >> > >> --Jeremy > >> > >> > ###################################################################### > >> ## > >> Use REPLY-ALL to reply to list > >> > >> To unsubscribe from the HPS-SOFTWARE list, click the following > link: > >> > https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1 > >> > >> > >> > >> > >> > >> > >> ###################################################################### > >> ## > >> Use REPLY-ALL to reply to list > >> > >> To unsubscribe from the HPS-SOFTWARE list, click the following link: > >> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1 > > > > ######################################################################## > Use REPLY-ALL to reply to list > > To unsubscribe from the HPS-SOFTWARE list, click the following link: > https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1 > ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the HPS-SOFTWARE list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1