Is there any way to customize logging on Neo4j 3+? Something like logback.xml where I can define log pattern, output files, levels, rolling policy and so on.
If you're talking about using Neo4j Server, then the logging configuration is available in the neo4j.conf file, with options prefixed by dbms.logs.: https://neo4j.com/docs/operations-manual/current/reference/configuration-settings/
These options include log level, output files, rotation policy, etc.
If you're using Neo4j embedded in another application (which you probably shouldn't), then you can use the setUserLogProvider(...) of the GraphDatabaseFactory. If you want to route user logging to another framework, there is a Slf4jLogProvider in the neo4j-logging jar, which can be used to send logs to slf4j and onto wherever you like.
Related
I am trying to migrate from log4j1 to logj2.
I have a WLS server with two ear files. Ear1.ear and Ear2.ear. Both have similar code and for logging, they use the same logger name. In log4j1, there were two different config files loggingconfigEar1.xml and loggingconfigEar2.xml writing to ear1.log and ear2.log respectively.
I am trying to implement the same in log4j2, but not able to find an easy way out. Is it possible to have two different ears with same logger name have its own individual log files. Right now, I am initialising the config file through the System Property log4j.configurationFile and it does not work.
The only other option that I can think of is, have separate logger names for the two ears. But that would involve code change in quite a few places and I want to have it as a last resort option.
FYI, there was a lot of customisation done for log4j1 which I have avoided in the migration either by scrapping the functionality or by rewriting code. I am not sure how exactly this separate logging was achieved in log4j1.
change a config.properties file in a jar / war file in runtime and hotdeploy the changes ?
my requirement is something as follows, we have a "config.properties" in a jar/war file , i have to open the file through a webpage and after the user has made necessary changes to it, i have to update the "config.properties" in jar/war file and hot deploy it. can we achieve this feat ? if so can you please point me to relevant sites/documents so that i can jumpstart on this.
I will strongly recommend your architecht rethink this solution. What you describe should be done through JNDI or a similar technique, not through reloading properties.
Deployments should be considered static - that any given web container allows for magic trickery should not be depended on, and WILL break some day (most likely at the most inconvenient time).
You've got a couple of problems off the top of my head:
ensuring that nothing is holding static references to a java.util.Properties that has previously loaded your config.properties file.
most servlet engines will unpack your war to a working directory so the properties file you load won't be the one in the war, it will be the unpacked one. This means your changes
will be overwritten when you restart the servlet engine because this is typically one of the points the war is unpacked.
While these problems aren't insurmountable I've always found it much easier to implement this sort of behavior by storing the properties in JNDI (as Thorbjørn suggests) or a database (while being careful about the static references I mentioned in point 1).
The JNDI/database solution has the nice side effect of easing deployment into multiple environments because each typically has it's own registry/database.
Even that I agree with the comments explained before, I could suggest one solution:
Apache Commons Configuration extension gives you the posibility to do something like:
config.setReloadingStrategy(new FileChangedReloadingStrategy());
That could make the trick to change the configuration file on a runtime basis with no code at all.
However, like JNDI and other methods of web application configuration, the security is a concern. Be careful on which parameters you can/must be able to configure.
We are trying to switch completely from log4net to Serilog. However, this part of functionality seems to be missing. What I need is to be able to get location of log-files Inside a library class. This is important for our Desktop Click-Once application because that location is different on different OSes and for different users. When user needs access to the logs we can direct him to the proper folder.
Very similar question was asked here:
Read current Serilog's configuration
But I can't believe that there is no way to get this information from Serilog. I don't need to change that configuration - just read it. In log4net we could do:
log4net.LogManager.GetAllRepositories()
and then
repository.Root.Appenders.OfType<FileAppender>
Please tell me that there is some kind back-door to the current LoggerConfiguration or if there is some alternative way to get file-path of the current File-Sink.
Serilog does not expose the list of Sinks that have been configured, so your only option at the moment would be to use Reflection if you really want to get this information from the live Serilog configuration.
You can see an example on this answer:
Unit test Serilog configuration
That said, given all you want to do is to know the path where log files are being written, that's something you can easily store at the start of the application at the moment you set up your Serilog logging pipeline.
If you configure the file path in code, you can store that information in a static property somewhere your entire app can access. If you get your folder path from the appSettings.json or App.config, you can read the information from there.
If you have environment variables in your configuration you can get the same values that Serilog gets by expanding these environment variables e.g. Environment.ExpandEnvironmentVariables("%LogPath%\\AppName.log")
I'm looking for ways to configure/reconfigure log4j after it may, or may not have been initialized. This should work running standalone or in a web container.
The configuration may be represented by a configuration file at a particular arbitrary URI. The knowledge of the URI comes from the application, not log4j framework. The configuration may also be done programmatically (less problematic but problematic still).
The public API is unfortunately sorely lacking so developers are forced to write brittle code using implementation classes from log4j core. From weeks of studying documentation and stepping through log4j code I see two ways to accomplish reconfiguration:
Stopping the current context and re-initializing using log4j.core.config.Configurator,
similar to the following:
((LoggerContext) LogManager.getContext(false)).stop();
Configurator.initialize(buildDefaultConfiguration()); //programmatically building a configuration
or
((LoggerContext) LogManager.getContext(false)).stop();
Configurator.initialize(null, ConfigurationSource.fromUri(loggingUri)); //passing the configuration source constructed from a known URI
The first line in both examples will stop the current context if it has already been created and started (when running in a web container for example). If log4j has not been initialized (when running as a standalone app for example) it will initialize log4j with the default configuration and start the context first (as a side effect of calling getContext()), and then stop it.
If the current context is not stopped first the call to Configurator.initialize() will have no effect. log4j will ignore your attempt to re-initialize, will not give you any indication of it, and just simply return the current context. This behavior is not mentioned in the "Reconfigure Log4j Using ConfigurationBuilder with the Configurator" section of the Manual. It simply says: "However, should any logging be attempted before Configurator.initialize() is called then the default configuration will be used for those log events." The default configuration will also be used for all subsequent log events in the provided examples because calling Configurator.initialize() will have no effect, unless the current context is stopped first.
Setting a new configuration location on the existing context thus forcing reconfiguration,
similar to the following:
((LoggerContext) LogManager.getContext(false)).setConfigLocation(loggingUri);
This works in a similar fashion: if log4j hasn't been initialized the call to getContext() will trigger initialization and creation of the default context that will then be reconfigured; and if it has been initialized then the current context, whatever it may have been, will get reconfigured. The configuration source will be created from the URI by the log4j framework.
The difference is that in the first way the context is replaced and all loggers in the old (stopped) context will be dead. If any code on the stack holds references to these dead loggers and tries to log to them it will be a no-op. In the second way the context is kept but the configuration is replaced and existing loggers are updated with the new configuration.
Both methods use core code and are therefore brittle, but both work for the sunny day scenario (using log4j-core 2.10.0 anyway). However, neither one appears to afford the user any control over handling any exceptional events, or even inform the user that something went wrong. Log4j will "eat up" any exceptions, and make its own executive decision how to handle them.
If a problem occurs after Configurator.initialize() is called log4j will create a default configuration that effectively cuts all logging off other than errors to the console and happily return the new context back not giving the calling code any clue that logging has effectively been stopped.
If a problem occurs after LoggerContext.setConfigLocation() is called log4j will do essentially the same thing except the current context will be kept. One would think that particularly in the case of a reconfiguration failure the most typical handling would be to revert back to the old configuration. There doesn't appear to be a way to accomplish this because log4j will simply stop logging (other than errors to the console) and give the calling code no indication of the failure.
Here's a typical scenario: several applications extend a common framework. The framework configures the same logging for all extending applications (to facilitate reuse and simplify post-processing of the logs). Some application has a unique logging need and attempts to reconfigure log4j from its own metadata (config file at a known URI). The XML parser throws an exception parsing this file. The exception gets handled internally by log4j, logging is quietly stopped, and no one knows. Well, there is an error log sent to the StatusLogger with the exception, but the calling code doesn't know.
So with this lengthy preamble, the question is: is there a mechanism I haven't discovered yet to modify log4j configuration in a predictable fashion and be able to handle abnormal events should they arise? That is, other than something drastic like (for the example above) extending the XML configuration class and replacing code that handles exceptions, thus running a risk of creating undesirable side effects in the current log4j implementation, not talking about an even greater risk of breaking in the future if the implementation changes.
Any help would be greatly appreciated!
I am new to Grails and I have inherited an existing application. I have a big file message.properties that I would like to prune, in order to remove keys that are no longer used.
In Django there is a command makemessages that goes through all codebase and collects all strings that need translation, adding them to the messages file and commenting out the entries that no longer exist. Is there a similar tool for Grails? If it helps, the project is based on verions 1.3.9.
There is no such tool, but you can create your own gant script. Take a look at getting a list of all i18n properties used in a Grails application and process this list.