Почему я получаю java.lang.NoSuchFieldError: для значения Enum?

Question

У меня есть Enum в банке, которую я изготовил сам. Этот jar является зависимостью второго jar, который использует значения enum.

Теперь второй jar является каркасом ведения журнала, тогда как первый jar в этом случае является модельными классами каркаса ведения журнала.

Я пытаюсь внедрить эту структуру журналирования в созданное мной веб-приложение. Короче говоря, нужно еще немного поработать, но я застрял на одной проблеме. Ошибка в инициализации конфигурации фреймворка перехватывается как исключение и вызывает метод. Этот метод имеет значение Enum в качестве одного из параметров. Тем не менее, я получаю java.lang.NoSuchFieldError для этого перечисления.

Значение Enum было ERROR, поэтому я подумал, что это может быть совпадением. Но когда я изменил его на BABYLOVE, сообщение об ошибке также изменилось.

Я проверил наличие избыточности и / или возможных совпадений в именах классов / перечислений, но я не могу найти ни одного.

Последовательность заказа:

1. Веб-приложение требует инициализации каркаса (прямая зависимость)
2. logging-framework имеет проблемы с загрузкой собственной конфигурации и выдает исключение
3. Исключение обрабатывается, и вызывается метод для регистрации ошибки
4. Метод вызывается с несколькими параметрами, один из которых является значением enum из logging-framework-model.jar, который является транзитивной зависимостью веб-приложения.

5. Веб-приложение выдает исключение

   java.lang.NoSuchFieldError: BABYLOVE
   at logging.framework.Constants.<clinit>(Constants.java:52)
   at logging.framework.Logger.<init>(Logger.java:60)
   at logging.framework.LogContext.getLoggerFromContext(LogContext.java:95)
   at logging.framework.LogContext.getCurrent(LogContext.java:48)
   at action.navigation.CalendarElementEditorAction.execute(CalendarElementEditorAction.java:39)
   Truncated. see log file for complete stacktrace
   

Константы, строка 51-52:

public static final Event ConfigValidationFailed = 
EventLogHelper.getEvent(EventLogSource.LoggingFramework, EventLogEntryType.BABYLOVE");

EventLogEntryType:

@XmlType(name = "EventLogEntryType")
@XmlEnum
public enum EventLogEntryType {

//for test purposes, should be removed. This variable is given a name that can not be confused with standard names in error messages, like Error and Warning can.
@XmlEnumValue("BabyLove")
BABYLOVE("BabyLove"),

@XmlEnumValue("Error")
ERROR("Error"),
@XmlEnumValue("Warning")
WARNING("Warning"),
@XmlEnumValue("Information")
INFORMATION("Information"),
@XmlEnumValue("SuccessAudit")
SUCCESSAUDIT("SuccessAudit"),
@XmlEnumValue("FailureAudit")
FAILUREAUDIT("FailureAudit");



private final String value;

EventLogEntryType(String v) {
    value = v;
}

public String value() {
    return value;
}

public static EventLogEntryType  fromValue(String v) {
    for (EventLogEntryType c: EventLogEntryType .values()) {
        if (c.value.equals(v)) {
            return c;
        }
    }
    throw new IllegalArgumentException(v);
}

Я не знаю, имеет ли это значение, но я использую maven2, чтобы справиться со своими зависимостями.

Answer 1

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

Мое веб-приложение является одним из двух очень похожих, у обоих есть зависимость от jar-файла, содержащего некоторую базовую модель и классы бизнес-логики. Ранее я добавил каркас ведения журналов (версия 1) в pom.xml этого проекта. Таким образом, среда ведения журналов 1.0 была транзитивной зависимостью веб-приложения, в то время как среда ведения журналов 2.0 была прямой зависимостью веб-приложения. Я предполагаю, что прямые зависимости имеют приоритет над переходными, поэтому 2.0 был тем, кто был упакован в мою войну. Однако, поскольку структура ведения журнала состоит из структуры (прямая зависимость) и набора классов моделей (транзитивная зависимость), война была упакована с моделью инфраструктуры ведения журнала версии 1.0.

После того, как я распаковал войну и обнаружил, что это был довольно простой процесс, чтобы выяснить, где он был неправильно импортирован, и в итоге у меня был только каркас логирования версии 2.0 для полного набора.