How to set javax logger handle to be refactor sensitive

Someone might yell at me to read the faqqing faq, but I'm in a hurry ...

Does anyone have a way to make javax or log4j logger refactor-sensitive?

Say, that currently utils.Something has the logger handle:

final static private Logger logger = Logger.getLogger(Something.class.getName());

And logging.properties has

.level = warning
utils.Something.level=info

Then using Eclipse to refactor Something to nutilla.Somewhere

resulting in my logger handle and logger property becoming out of sync.

Perhaps, set logging levels programmatically?

Has anyone bothered to do it and was it worth the trouble?

Clarification: After refactoring utils.Something to nutilla.Somewhere, the logger handle now would only log warning and not info, because of the entry in logging.properties file. So the question is, is there a way to replace the function of logging.properties file with programmatic means and if so, is it worth the trouble?

Reason and Motivation for question

I'm obstinate at not lis开发者_JS百科tening when advising me to avoid refactoring because ... Refactoring is a constant habit of mine. I create classes by the hour, merge them, delete them, extract methods, etc ... I'm a restless class creator who finds no time wondering where to initially place a class. I dislike sitting down wasting time wondering where to place them initially - so I just place them in the most convenient package namespace.

After building a good amount of class/interface structure, it becomes apparent to me where certain classes, interfaces or methods shd have been then all the refactoring activities take place and ... tada ... that's when my logging.properties file is ruined a hundred lines.

If you configure logging using class (as opposed to package) names, checking "Update fully qualified class names in non-Java text files" in eclipse's rename refactoring dialog should do the trick.

I do not think there is a way out of the box that updated the package names and class names in your properties file as a result of refactoring actions.

You can:

• update the properties file by hand when refactoring is done (refactoring should be an action that is not undertaken eveery week :=)
• use fixed strings to create loggers (make logging more functional instead of physical)
• load the properties file and adjust the property names on the basis of constants you declare in your class before initialising log4j with that properties collection

I would go for the first option myself, too much automagic behaviour can get you in a very non-transparent situation quickly.

I wouldn't use it (I think it makes more sense to be careful when refactoring) but here it goes:

    private static Logger logger = Logger.getLogger(new Exception().getStackTrace()[0].getClassName());