Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Fix logging-framework static-context headache #8760
As a user I want to be able to use the logger from a static context, whenever there is no access to NodeEngine without any side-effects to the logging configuration.
STATE OF THE ART:
Additionally, it is impossible to always access nodeEngine for logging since there are Hazelcast classes that may be used without having an instance (like Config classes, etc.)
There is a possible problem in the most common use-case:
If somebody uses
In the one-node per JVM case:
In the multiple-nodes per JVM case (shared-case):
the more I'm thinking about it the more hack-ish it appears. I think we should not introduce a new flag to solve our internal issues - it's moving our problems to users = not good.
This is what I see as a better solution:
Now the big question is how to make it easy accessible. Currently it's quite awkward.
There is another feature provided by our logging approach and that is the member that owns the logging, is available. See LoggingServiceImpl.
I'm also not terribly excited about the current logging and would be happier if we could use logging in the traditional way. But we do need to think careful about loosing the 'this member' access.
One of the questions that needs to get addressed is: do we need this information?
@jerrinot LoggingService doesn't solve the problem of logging in static-context
I thought about it and I think we would be good with:
referenced this issue
Aug 23, 2016
OK, I managed to remove a lot of places where static-context logging is used
Places where we do not have a Node and logging is used:
Another very hacky solution would be to put a "LoggingContext" into the thread (storing for example the current HazelcastInstance) and test if this is available, if so you can extract necessary information, otherwise go without it. That way you can use static loggers, have static and instnce-based context logging. As I said, hacky and ... well more of a workaround though but would work since we control most threads anyways.
Thx @noctarius, I considered it too, but that's a bit too much when it comes to Config since there are classes that most certainly will be used from a user's thread before even starting Hazelcast.
In this case I think that all the logging should be removed from Config classes, and that the config should be validated while passed to HazelcastInstance.
I don't care much about logging in rest of the cases, these can be either removed or a logger could be passed from a ThreadLocal context.
This way we would ban static-context logging and solve the problem completely.
It turned out that:
I limited work on this issue to: