Logback-beagle with config file used for multiple environments
I found the newly released Logback-Beagle to look pretty cool. I want it! However, I see that you need to add the tag <consolePlugin /> to the config file. This makes me worry a little about the implications on this when that same config file is used in test and production. So it looks like if I add the consolePlugin then I'll be having an added appender trying to spit out logs to the local machine (not desired). Basically, I only want the extra appender in development. Is there any other way to do this other than doing it programmatically (by doing a check on which environment it is in).
I think you can put it in logback-test.xml (*Chris*) On Tue, Jul 24, 2012 at 3:31 PM, Noremac <cam@byu.edu> wrote:
I found the newly released Logback-Beagle to look pretty cool. I want it!
However, I see that you need to add the tag <consolePlugin /> to the config file. This makes me worry a little about the implications on this when that same config file is used in test and production.
So it looks like if I add the consolePlugin then I'll be having an added appender trying to spit out logs to the local machine (not desired).
Basically, I only want the extra appender in development. Is there any other way to do this other than doing it programmatically (by doing a check on which environment it is in).
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
Chris Pratt <thechrispratt@...> writes:
I think you can put it in logback-test.xml (*Chris*)
On Tue, Jul 24, 2012 at 3:31 PM, Noremac <cam@byu.edu>
wrote:I found the newly released Logback-Beagle to look pretty cool. I want it!
However, I see that you need to add the tag <consolePlugin /> to the config file. This makes me worry a little about the implications on this when that same config file is used in test and production. So it looks like if I add the consolePlugin then I'll be having an added appender trying to spit out logs to the local machine (not desired). Basically, I only want the extra appender in development. Is there any other way to do this other than doing it programmatically (by doing a check on which environment it is in). _______________________________________________ Logback-user mailing listLogback-user- vdLmLxQ6Fys@public.gmane.orghttp://mailman.qos.ch/mailman/listinfo/logback-user
_______________________________________________ Logback-user mailing list Logback-user@... http://mailman.qos.ch/mailman/listinfo/logback-user
I could put it in the logback-test.xml file, but that won't change anything as only either the logback-test.xml or logback.xml will be used for configuration. I'd still need an external mechanism to put a different file in the class path based on the environment. I want to use the same code for every environment. I have added logic to programmatically set up the SocketAppender and add it to the root logger if the environment is development. It's working well, just not sure this is the best way given my preferences.
Add your logback-test.xml file to a location that is only on the classpath on your development/test machines (almost always outside of the war file itself), then use the Configuration File Inclusion mechanism to include your production logback.xml file [ http://logback.qos.ch/manual/configuration.html#fileInclusion] (*Chris*) On Thu, Jul 26, 2012 at 9:59 AM, Noremac <cam@byu.edu> wrote:
Chris Pratt <thechrispratt@...> writes:
I think you can put it in logback-test.xml (*Chris*)
On Tue, Jul 24, 2012 at 3:31 PM, Noremac <cam@byu.edu>
wrote:I found the newly released Logback-Beagle to look pretty cool. I want it!
However, I see that you need to add the tag <consolePlugin /> to the config file. This makes me worry a little about the implications on this when that same config file is used in test and production. So it looks like if I add the consolePlugin then I'll be having an added appender trying to spit out logs to the local machine (not desired). Basically, I only want the extra appender in development. Is there any other way to do this other than doing it programmatically (by doing a check on which environment it is in). _______________________________________________ Logback-user mailing listLogback-user- vdLmLxQ6Fys@public.gmane.orghttp:// mailman.qos.ch/mailman/listinfo/logback-user
_______________________________________________ Logback-user mailing list Logback-user@... http://mailman.qos.ch/mailman/listinfo/logback-user
I could put it in the logback-test.xml file, but that won't change anything as only either the logback-test.xml or logback.xml will be used for configuration. I'd still need an external mechanism to put a different file in the class path based on the environment. I want to use the same code for every environment.
I have added logic to programmatically set up the SocketAppender and add it to the root logger if the environment is development. It's working well, just not sure this is the best way given my preferences.
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
Due to how our build process is set up and that the only difference we want in the config file is for the plugin, it's not worth changing things around to have different config files. However, that looks like a very viable solution. Thank you for your help.
On 25.07.2012 00:31, Noremac wrote:
I found the newly released Logback-Beagle to look pretty cool. I want it!
However, I see that you need to add the tag <consolePlugin /> to the config file. This makes me worry a little about the implications on this when that same config file is used in test and production.
So it looks like if I add the consolePlugin then I'll be having an added appender trying to spit out logs to the local machine (not desired).
Basically, I only want the extra appender in development. Is there any other way to do this other than doing it programmatically (by doing a check on which environment it is in).
You have several options: 1) use logback-text.xml for eh... testing. 2a) conditional logging. See also the documentation at [1]. Assuming "hulk" is the name of the production machine, you could enable sending events to the console plugin on machines other than hulk as follows: <configuration> <if condition='!property("HOSTNAME").contains("hulk")'/> <consolePlugin/> </if> ..... other configuration directives </configuration> Note that conditional configuration requires Janino. 2b) use some preset system variable, say "deploymentType": <configuration> <if condition='property("deploymentType").equals("development")'> <consolePlugin/> </if> ..... other configuration directives </configuration> 2c) compute the deployment type dynamically. See the docs at [2]. <configuration> <define name="deploymentType" class="a.class.implementing.PropertyDefiner"> </define> <if condition='property("deploymentType").equals("development")'> <consolePlugin/> </if> ..... other configuration directives </configuration> 3) Programmatically enable sending events to the console plugin. Here is the code: import org.slf4j.LoggerFactory; import ch.qos.logback.classic.LoggerContext; import ch.qos.logback.classic.net.SocketAppender; import ch.qos.logback.classic.Logger; import static org.slf4j.Logger.ROOT_LOGGER_NAME; .... String hostname = "localhost"; int port = 4321; SocketAppender socketAppender = new SocketAppender(); socketAppender.setRemoteHost(hostname); socketAppender.setPort(port); socketAppender.setIncludeCallerData(true); socketAppender.setReconnectionDelay(10000); LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory(); socketAppender.setContext(lc); socketAppender.start(); // LoggerFactory return type is org.slf4j.Logger Logger rootLogger = (Logger) LoggerFactory.getLogger(ROOT_LOGGER_NAME); rootLogger.addAppender(socketAppender); HTH, [1] http://logback.qos.ch/manual/configuration.html#conditional [2] http://logback.qos.ch/manual/configuration.html#definingPropsOnTheFly -- Ceki http://tinyurl.com/proLogback
Great Info. Thanks! I'm sure this will help others in the future as well. I have gone with the programmatic setup.
participants (3)
-
ceki -
Chris Pratt -
Noremac