Есть ли минималистичный способ получить ResourceBundle по умолчанию, когда вам не нужна локализация? - PullRequest
Новая
       15

Есть ли минималистичный способ получить ResourceBundle по умолчанию, когда вам не нужна локализация?

0 голосов
/ 01 ноября 2011

Я хочу наследовать, чтобы расширить java.util.logging.Logger.Единственный видимый конструктор - это 

protected Logger(String name, String resourceBundleName)

. Несмотря на то, что когда вы хотите получить экземпляр, они предлагают два способа: 

static Logger   getLogger(String name)
static Logger   getLogger(String name, String resourceBundleName)

Есть ли способ получить какой-то видпо умолчанию ResourceBundle или имя по умолчанию ResourceBundle, чтобы я мог использовать конструктор, не создавая файл свойств интернационализации и связанный объект?

Конечно, я мог бы просто создать класс-обертку и использовать getLogger(String name), чтобы избежать необходимости в имени ResourceBundle.К сожалению, это означает, что мне пришлось бы реализовывать метод-обертку для каждого метода Logger, который я хочу использовать.(Слишком много печатается).

Редактировать: Следующая попытка получить данные локализации по умолчанию из Logger не работает.

import java.util.logging.Logger;

class JLogger extends Logger
{
    static Logger dummyLogger = Logger.getLogger("com.dummy.utilities");

    private JLogger(String name)
    {
        super(name, JLogger.dummyLogger.getResourceBundleName());
    }

    static JLogger getJLogger(String name)
    {
        return new JLogger(name);
    }

    public void severe() // a zero arguments version of severe
    {
        severe("");
    }
}

getResourceBundleName() просто возвращает ноль.Конструктор super(name, resourceName) создает что-то, что не ведет журналирование, если вторым аргументом является null.

1 Ответ

1 голос
/ 01 ноября 2011

К сожалению, это означает, что мне нужно будет реализовать метод-обертку для каждого метода Logger, который я хочу использовать. (Слишком много печатать).

Нет необходимости делать это, это уже сделано. Взгляните на SLF4J и Commons Logging , они предоставляют разумные оболочки вокруг java.util.logging, скрывая ужасность этого API.

Эти два API также могут делегировать надлежащую базовую реализацию журнала, такую ​​как Logback или Log4J, полностью обходя java.util.logging.

...