Print

Print


​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