Using the standard GWT logger, is it possible to disable the Log statements for a complete package in the xml?
Or at least individual class's?
At the moment in the xml I can disable/endable all the logging with;
<set-property name="gwt.logging.enabled" value="TRUE"/>
This seems to set it globally for all class's in all packages. Is it possible to do this selectively in the xml?
The guide here; http://www.gwtproject.org/doc/latest/DevGuideLogging.html seems to only cover configuring the rootlogger, covering every log in the project. I am probably missing the obvious, but I don't "get" how to apply this selectively.
Given all my log statements are named;
protected static Logger Log = Logger.getLogger("parent.childc");
It seems like selectively turning them on/off should be possible.
Thanks,
Thomas
If you have all of your logger instances really initialized as Logger.getLogger("Example"), you can't selectively turn them off and on, since they are all one instance called 'Example', so I'm assuming that this isn't actually the case.
For the most part, this is normal JULI - the standard mechanisms that work on the JVM will work here. This is doubly true in dev mode, which actually uses the standard java.util.logging.Logger implementation. So if you are just looking for cleaned up logging in dev mode, treat it as you would any other logger - from the root instance, find the package or class that you want to disable/enable, and set the log level to where you want it.
In compiled code this behaves a little differently, you may need to experiment a bit to see exactly how, I don't recall at the moment. However, you can still use LogManager, and can walk all existing loggers, packages:
LogManager manager = LogManager.getLogManager();
Enumeration<String> allLoggers = manager.getLoggerNames();
// for each String in the list, grab the logger via manager.getLogger
The advantage to this as opposed to Logger.getLogger is that this will only tell you about loggers that already exist, instead of creating them as you go. This way you could have a config file or url param that specifies which details you wish to see logged, and disable the rest.
EDIT: I ran an old sample I had made again, and it appears that the chief difference between dev mode and prod mode is that in prod mode you get a logger per package, with root at the top and the specific named loggers as 'leaf nodes', while in dev mode all loggers seem to be placed in the root logger directly, with no intermediate packages. It is possible that if you requested a logger for a particular package that it would then make one, but I didn't test to find out.
Related
I have a VSTS account within the region of US. And I have a bunch of Unit tests, which run successfully on my local server. But when deployed to the VSTS, all the tests related to the date time are failed. I guess this is because the interpretation of the date time format is different as my local is using the UK format. Because there are quite a number of test projects, instead of changing it individually, is there any way to change the VSTS default thread's current culture as UK? I know probably the change of region might do the trick, but any other way?
Of course, a lot is possible, but it would be a far better idea to make sure your application correctly handles accidentally being deployed to a machine with a different culture.
You've basically uncovered an unexpected and unwanted behaviour of your code, or you've detected that you're not able to run in different cultures.
I'd personally try to make the code more resilient, e.g. explicitly set the right culture and depend on InvariantCulture where possible.
If you want the easy way out, you can do one of the following:
Use an initializer
Add one method to your test project and decorate it with the [AssemblyInitializer] attribute:
[TestClass()]
public sealed class CultureInitializer
{
[AssemblyInitialize()]
public static void AssemblyInit(TestContext context)
{
Thread.CurrentThread.CurrentCulture = new CultureInfo("en-GB");
Thread.CurrentThread.CurrentUiCulture = new CultureInfo("en-GB");
}
}
Force the user profile culture settings
I recommend you don't do this, while it shouldn't, it may influence other processes running after your tests, change output formats or cause other unwanted behaviours similar to what you're now experiencing.
The data is stored in the registry in the following location:
HKEY_CURRENT_USER\Control Panel\International
You'll want to change the value before starting the tests, as these values are read from the system when starting the application unless you're registering for the events to be signalled when these values change, your tests will not see the difference.
Run a script in the build definition before the tests start
Set-Culture -CultureInfo en-GB
I'm using the OPAL framework to implement static analyses. I wondered if it is possible to suppress the console output of the framework which is printed on the console while execution. The following shows a part of the output.
...
[info][OPAL] Bytecod Representation - Development Build (asserstions are enables)
[info][project configuration] the JDK is part of the analysis
[warn][project configuration] supertype information incomplete
...
I found that OPAL has several LogLevels (i.e. WARN, INFO, ERROR) but I couldn't find a way to specify the logging granularity. I'm really interested in warnings and errors but I would like to suppress the (massive) output at info level.
By now I figured out that it is possible to suppress the console output of OPAL. The OPAL logging mechanism uses several LogContext objects. It exists one GlobalLogContext and one LogContext per available Project. Since both are independent it is necessary to silence both types.
The first context is used for every logging event which does not happen in the context of a specific project whereas the project-specific context is used to log messages in a given context.
The OPALLogger.update(...) method can be used to update the Logger that is used for a LogContext. With this method, it is possible to associate a new Logger with a LogContext. If you are running OPAL with the command line, a ConsoleOPALLogger can be used as follows.
val project = ...
OPALLogger.updateLogger(project.logContext, new ConsoleOPALLogger(true, org.opalj.log.Error))
OPALLogger.updateLogger(GlobalLogContext, new ConsoleOPALLogger(true, org.opalj.log.Error))
I have a task to collect and report some runtime statistics for my application. Ostrich looks quite friendly in both API and feature set. But I can't find any documentation about the most of declared features. Especially it is difficult to configure stats reporting through the web interface without any understanding of configuration principles.
So my main question: is there any documentation besides the README?
If no, could someone give an example of the following features (all of them are from the top of README):
load & reload per-environment configuration (there is example on SO already, but what if I want to use a classpath resource? how to define an environment? how to reload configuration?)
report statistics into log files
Or (perfectly) give a good architectural overview of configuration in Ostrich so I can find some way to do configuration by myself.
Ostrich config files are just regular scala classes, so if you want to load a classpath resource, you probably should create the config instance in code instead.
Here is how I load default config if -f command-line arg is not specified:
val runtime = RuntimeEnvironment(this, args)
val server =
if (runtime.configFile.exists) {
runtime.loadRuntimeConfig[Server]()
} else {
(new RPCServerConfig)()(runtime)
}
Note that you have to
- create config instance
- then call it's apply() method
- then apply(runtime) on the result
You can easily extend this to load different configs depending by e.g. lift's Props.mode
This seems like a simple thing, but I can't find an answer in the existing questions:
How do you add a global argument to all your present and existing run or debug configurations? In my case, I need a VM argument, but I see that this could be useful for runline arguments as well.
Basically, every time I create a unit test I need to create a configuration (or run, which creates one), and then manually edit each one with the same VM argument. This seems silly for such a good tool.
This is not true. You can add the VM arguments to the JRE definition. This is exactly what it is for. I use it myself so that assertions are enabled and heap is 1024mb on every run, even future ones.
Ouch: 7-years bug, asking for running configuration template, precisely for that kind or reason.
This thread proposes an interesting workaround, based on duplicating a fake configuration based on string substitution:
You can define variables in Window->Preferences->Run/Debug->String Substitution. For example you can define a projectName_log4j variable with the
correct -Dlog4j.configuration=... value.
In a run configuration you can use ${projectName_log4j} and you don't have to remember the real value.
You can define a project-specific "empty" run configuration.
Set the project and the arguments fields in this configuration but not the main class. If you have to create a new run configuration for this project select this one and use 'Duplicate' from its popup-menu to copy this configuration.
You have to simply set the main class and the program arguments.
Also you can combine both solutions: use a variable and define an "empty"
run configuration which use this variable. The great advantage in this case
is when you begin to use a different log4j config file you have to change
only the variable declaration.
Not ideal, but it may alleviate your process.
I want to adopt logging within several utility classes, e. g. DBI. What is the best practice to do it with Log::Log4perl?
I think it is OK to subclass DBI (say, MyDBI) and override some methods there to make them do the logging. But there's a problem with categories. If you create a logger with
Log::Log4perl->get_logger(ref $self || $self)
then all log entries belong to MyDBI and it would be hard to filter them. So it seems better to me to pass a logger to MyDBI from the calling module (say, MyModule), so that category would be semantically right. The first question, is it OK in general? I mean, are there any hidden reefs regarding such approach?
The second question, how to pass the logger to MyDBI? I have an idea to declare a global variable, e. g. $MyDBI::logger and set in the calling method:
local $MyDBI::logger = Log::Log4perl->get_logger(ref $self || $self);
There's a traditional dislike for global variables. Can you think of a better way?
EDIT: Of course, the best code is no code. caller would suffice, if it took inheritance into account.
The third question, is it possible to log into both categories, MyDBI and MyModule, with Log::Log4perl, if they are hierarchically unrelated?
I would strongly encourage you to to log independently on the caller in a separate logger either per function or per module, so that you can run your module independently of log4perl used in your caller.
Each module will create its own logger with Log::Log4perl->get_logger("module name").If the caller does not create any appender, the program will simply not log anything and the log4perl in the modules will be ignored from a functional stand point. Log4Perl implements a singleton pattern for creating a logger, which is similar to a global variable.
Your Logging should be fine-grained as possible and as a rule of thumb I log in debug any input parameter and any result of a function/method. If really necessary, you can also use the stack trace to find out the caller which has lead to the error condition. Adding it into the parameters does just add additional complexity.
The following recipes might give you some more ideas about the flexibility on the configuration side of log4perl.Log4Perl Recipes The whole idea for me is to keep the code unchanged and change the logging configuration depending on my actual logging/bug tracing requirements (which might change in the future). To keep the code unchanged if possible is even more important with modules as you want to avoid testing all calling programs.
To answer your questions in brief.
1.) Each module should have its own logger
2.) Thus do not add the loggers into the interface
3.) Log4Perl will log on all levels depending on your appender configuration. This way you control what you will see not see - normal level will usually be INFO and specific modules might be in debug. In bad cases the Pattern layout will allow you to add the stack trace into the logging purely with configuration.