I have tried TTextLogAppender and TLogFileAppender and noticed that between app restarts the logfile is cleared and did not notice any property / method that would change this behaviour. I like log4net, especially the ability to rollover logging (create new files) on filesize / periods and just appends log data irrespective of app restarts etc. Does any of the existing appenders in spring4d expose similar behaviour to this? Should I rather register log4d as a logger instance in my container?
Related
Currently I read properties file by defining a global element like;
> <configuration-properties doc:name="Local Configuration Properties"
> doc:id="899a4f41-f036-4262-8cf2-3b0062dbd740"
> file="config\local_app.properties" />
But this is not enough for me
when try to deal different clients dynamically.
Usecase
I need to pick right configuration file when request comes in. That is, for different clients I have different properties file.( their credentials and all different). When request is received from listener, i'll check with clientid header and based on that value, i'll pick right configuration file. My properties files are added to different location.(Doing deployment through openshift.) Not within mule app. So, we don't need to redeploy the application each time, when our application supports new client.
So, in this case, how to define ? and how to pick right properties file?
eg:
clientid =google, i have properties file defined for google-app.properties.
clientid=yahoo, i have properties file defined for yahoo-app.properties.
clientid=? I'll add properties file ?-app.properties later
Properties files are read deployment time. That means that if you change the values, you to redeploy the application to read the new ones. System properties need a restart of the Mule Runtime instance to be set. And Runtime Manager properties need a restart of the application. In any case the application will restart. Properties can not be used as you want.
There is no way to use configuration properties dynamically like that. What you could do is to create a module using Mule SDK that read properties files and returns the resulting set of properties, so you can assign the result to a variable, and use the values as variables. You will need to find a way to update the values. Maybe set a flow with a scheduler to read the values with a fixed frequency.
I'm writing a plugin which implements the ILaunchConfigurationDelegate.
I have to override this method: launch(ILaunchConfiguration configuration, String mode, ILaunch launch, IProgressMonitor monitor);
Can I attach a TextConsole to it like for the ones in the JavaApplication launch type when writing with System.out.println()?
I would like to have that in order that my launch has the same lifecycle management for its console.
Essentially my ILaunchConfiguration type is a container which holds all possible other ILaunchConfiguration types. When launching my launch container I want to log the behaviour of the others which start in a sequence. This logging would be ideal in a TextConsole. Example: 'Hello World started.' 'Hello World terminated', 'Pi approximator started' ... etc.
AFAIK, there are no extra steps necessary to redirect std in/out to the Eclipse console. The Common tab of every launch configuration type has an Allocate console option that provides this feature if enabled.
If your launch configuration type does not provide the CommonTab, you can set the IDebugUIConstants.ATTR_CAPTURE_IN_CONSOLE attribute of your ILaunchConfiguration to true.
For the container launch, you can simply allocate a TextConsole to write the log messages to. The debug/launch framework attaches consoles to IProcess instances and this won't help here but you may want to look to ProcessConsole and ProcessConsoleManager to adopt the relevant part to opening and discarding the console.
Alternatively, you could investigate if setting the ATTR_CAPTURE_IN_CONSOLE of the container launch to true and creating a dummy IProcess that satisfies the requirements of the ProcessConsoleManager wrt to consoles.
I'm trying to get started using logging in an ASP.NET Core 1.0 application - but this is my first time using any sort of logging, and the built in solution is presenting me some confusion.
In my Startup.cs, I initialize logging as I've seen in the sample applications;
log.AddConsole(Configuration.GetSection("Logging"));
log.AddDebug();
This works fine, my Logging section in the config file is defined as follows;
{
"Logging": {
"IncludeScopes": false,
"LogLevel": {
"Default": "Debug",
"System": "Debug",
"Microsoft": "Debug"
}
}
}
This all works fine, but the problem is that I see everything output to the screen, like this;
That information is not bad, of course - but it's a bit verbose and clutters up the command line. I'd really like to only see errors and debug-level messages, such as when I call them like this;
Logger.LogDebug("debug info");
But I'm very unclear about how to go about this.
Is there any way to achieve this level of tuning?
Update
after more working with it, if I create only a console with LogLevel.Error, I can get the immediate result I want - but then I lose any information of the other levels. Can non-relevant information (LogLevel.Information and lower) be sent to another place? Like the Output console in Visual Studio?
To answer your question you can implement an ILogger and then log what you want in the "public void Log". Inside of that method you can switch statement the LogLevel and write it to the console, write it to a DB, only write certain things, etc. The round about steps would be:
Create a class that implements ILogger. If you want to manually handle every log level and do something different with it you can do it there (as long as you haven't set the LogLevel too high in the startup). Here you can write to a Db, write to the console, email, whatever you want.
Create class that implements ILoggerProvider, fill in it's methods (CreateLogger is where you'll instantiate your ILogger you created in step 1).
Create an extension method to ILoggerFactor that looks something like this:
public static ILoggerFactory AddMyLogger(this ILoggerFactory loggerFactory, IHttpContextAccessor httpContextAccessor)
{
loggerFactory.AddProvider(new AppsLoggerProvider(httpContextAccessor));
return loggerFactory;
}
In the Configure method of the Startup, add something like this (what you pass down the line is up to you):
// Create our logger and set the LogLevel
loggerFactory.AddMyLogger(httpContextAccessor);
loggerFactory.MinimumLevel = LogLevel.Verbose;
Note: The ILoggerFactor was injected into the Configure method (ILoggerFactory loggerFactory).
ASP.NET Core defines the following six levels of logging verbosity:
Trace – For the most detailed messages, containing possibly sensitive information. Should never be enabled in production.
Debug – For interactive investigation during development: Useful for debugging but without long term value.
Information – For tracking the general flow of the application.
Warning – For unnormal events in the application, including errors and exceptions, which are handled and as such do not impact the application’s execution but could be a sign of potential probelms.
Error – For actual failures which cause the current activity to fail, leaving the application in a recoverable state though, so other activities will not be impacted.
Critical – For failures on the application level which leaves the application in a unrecoverable state and impacts the further execution.
These levels are sorted by verbosity from very verbose, to very quiet but with important consequences. This also means that Information is considered less verbose than Debug.
This means that when you configure a logger to show logging of the Debug verbosity, you always include the less verbose log levels as well. So you will also see Information. The only way to get rid of those Information log entries would be to set the verbosity to Warning or higher.
The amount of logging on the Information level was chosen deliberately by the ASP.NET Core team, to make sure that important parts are visible. It might seem very verbose to you, but it’s entirely by design. In general, it’s more useful to log more than too little, so in case you actually need to access the logs, you have enough context information to make the logs actually useful.
If you want to hide that information, you could for example set the log level for Microsoft.AspNet.Hosting to Warning. Or alternatively, set the log level to Warning in general, but set it to Debug for your application’s namespaces to only see your own logging output.
You could also log to files and utilize a log file viewing utility (e.g. TailBlazer) to access the logs while using filters to focus on the parts you are interested in.
I would like to capture the messages logged by SQLServerDbSupport and DBMigrate during a migration. Calling flyway.migrate does the migration, but it is not always obvious what actions were applied. I am hoping to capture this to determine what changes, if any were applied.
I already tried setting STDOUT to a ByteArrayOutputStream but that didn't work, presumably as the logger is initialised before the re-direction.
What other options are there to obtain the output messages ?
All you have to do is configure whatever logging framework you use to achieve this. No need to reassign stdout.
While this suggestion is great I am not sure how it addresses the need to capture the output from one migration only, while another migration is running. Do you have an example of a logger configuration which deal with individual migration in a concurrent scenario /
Also, is it possible to configure a size based rolling file appender to do auto compression like a rolling file appender?
Thanks
Is it possible to decouple the location of the active vs. archived log files with apache log4cxx?
Not out of the box, but you can achieve it by writing a new appender, overridding the RollingFileAppender. Override the setOption() method to provide a new option denoting a logging directory, say loggingDir, and the setFile() method to take this new option into account.
As for zipping the rolled-over file, I'm only sure that a good extension point to implement it in would be the
virtual void append(const spi::LoggingEventPtr& event, log4cxx::helpers::Pool& p);
method; however, I'm not a C++ guy, so I don't know what's best to use to implement the compression.