log4j - Properties File

[Sasank Vemana]

I am not a Java Developer so please bare with me if my question is very basic!

I want to know if I can get the entire log4j.properties file constructed in Java code. I am not talking about configuring the logger using Java code.

I have a logger that is already configured using a file. I want to get access to either Logger or LogManager (any other?) class and print the current configuration that is in memory.

Is this possible?

[Junilu Lacar]

Welcome to the Ranch!

Putting the obvious question of "What's the point of doing that if you already have the configuration file?" aside, the Log4J Logger API Documentation will tell you all the getters available so you can access a number of configuration items. I don't know for sure if the API provides everything you'll need to check all configurable items that can be set with a configuration file though. I imagine it would but you can find that out for yourself.

[Sasank Vemana]

Okay. Thanks. That is what I am finding very hard to figure out!

The reason why I am doing this is my properties is stored as the database. I am working on PeopleSoft/PeopleCode (ERP). We do have some basic functionality in PeopleCode to work with java classes.

I am trying to store my properties in my database so we don't have to get to each and every instance of our app servers to configure the properties file (for dynamic changes).

I want to pretty much write something that would compare the current properties in the database with the properties that is currently configured/stored in memory! This is the reason why I am trying to construct the current configuration into something that resembles the properties file! Hope this explains my requirements.

Happy to consider other options if there are any suggestions.

[Junilu Lacar]

Read your configuration in the database into a java.util.Properties object, then use org.apache.log4j.PropertyConfigurator.configure(Properties)

[Sasank Vemana]

Thank you once again. I appreciate your help and patience with me.

I am doing that already to perform the initial configuration. I want to write code to only "re-configure" the properties if there is a change to the properties in the database. That is the reason why I am trying to compare what is already configured.

[Junilu Lacar]

Why do you even care to compare configurations? Just reconfigure the loggers when you detect a change in the configuration settings in the database, no questions asked. I think you're trying to optimize prematurely. What's a few milliseconds difference compared to the time you've already spent trying to figure out how to save a few clock cycles?

[Junilu Lacar]

I can't imagine your logger setting changing every few minutes, or even every few days. So why do you think it's worth all the trouble you're going through. Just reconfigure already.

[Sasank Vemana]

Thanks Junilu! This is exactly the sort of input I was looking for.

The reason why I was trying to optimize my code was because we have several app servers with each server again with several domains. Each domain has its own JVM.

Recently, we have several performance issues with concurrent users hammering the system (since we work in the University Sector, we have several thousand students hitting our system concurrently). I did not want to introduce another issue with having several users hitting the same app server domain trying to re-configure the logger at the same time causing problems.

What are your thoughts? I hope it is just me over-thinking the problem. I would prefer to go with your suggest as it is a lot easier to implement!

[Junilu Lacar]

I would say that if you can, schedule logger configuration changes such that they happen during periods of least user activity. Propagate the changes to all your app instances at that time without trying to eek out a few milliseconds savings by only changing the configuration items that actually changed. I can't imagine the difference being more than a few milliseconds, honestly, and I don't really think it will be a big hit to application performance so I don't think it's worth the extra effort you're putting into it.

If you're having application performance problems, use a profiler to find the bottlenecks. Programmers are notoriously bad at improving performance based on gut feeling and intuition. Don't even try to do that.

[Sasank Vemana]

Just as an FYI to the group. I found it interesting that there is a class that provides this information that is in memory.

org.apache.log4j.config.PropertyPrinter

Print Method writes to a printwriter.

This gives the entire log4j properties in memory. Only difference is that logger is replaced with category in the in-memory properties.

E.g.: log4j.logger.TEST_123=ALL, file

would show up as
log4j.category.TEST_123=ALL, file

Thanks!