2017-02-03 5 views
0

Мы заметили, что если исключение генерируется, когда события CDI обрабатываются - например, с @Observes(during = TransactionPhase.BEFORE_COMPLETION) - тогда исключение не регистрируется, если уровень журнала выше DEBUG.Weld CDI не регистрирует исключения, если уровень отладки не включен

Weld записывает что-то простое, как это:

16:31:41,732 ERROR [org.jboss.weld.Event] WELD-000401 Failure while notifying an observer of event SomeEventDTO 

Линии 85-86 в DeferredEventNotification от Weld показать проблему: https://github.com/weld/core/blob/master/modules/jta/src/main/java/org/jboss/weld/module/jta/DeferredEventNotification.java

} catch (Exception e) { 
     EventLogger.LOG.asyncObserverFailure(metadata); 
     EventLogger.LOG.catchingDebug(e); 
    } 

Является ли это потому, что данные говорят исключение и его StackTrace не нужно регистрировать, или это потому, что Weld довольно (слишком) расслаблен в обработке исключений.

Есть ли лучшее решение, чем обертывание всего кода наблюдения событий блоком try-catch?

Примечание: установка стандартного уровня журнала для org.jboss.weld.Event на DEBUG вызывает слишком много регистрации. Каждое отправленное событие также вошли:

17:47:14,088 DEBUG [org.jboss.weld.Event] WELD-000400 Sending event SomeEventDTO directly to observer [method] public com.foo.bar.BeanClass.methodName(SomeEventDTO) 
+0

Ваш собственный первый консольный журнал показывает, что уровень ведения журнала для WELD-000401 на самом деле является «ERROR». Поэтому не имеет смысла быть видимым только с уровнем DEBUG. Сначала я должен убедиться, что вы правильно установили регистрацию в своей AS. Например, с WildFly вам нужно отдельно установить уровень для Weld и для самой консоли WildFly. – Siliarus

+0

@Siliarus Я не понимаю, что вы имеете в виду. Если я установил регистрацию в целом на ERROR, я получаю только строку с WELD-000401 и NO stacktrace. Если я установил уровень ведения журнала в целом на DEBUG, я также получаю стек. Это означает, что Weld эффективно скрывает исключение в производственной среде, где уровень журнала не будет DEBUG. Как я должен знать, какова фактическая ошибка, если Weld только регистрирует ее на уровне DEBUG? –

ответ

1

Теперь, когда я понимаю ваш вопрос (извините за путаницу перед), позвольте мне пролить некоторый свет.

Сообщение об ошибке, похоже, намеренно скрыто Weld. Нет никаких ограничений на регистрацию. Что касается исключений, спецификация просто описывает, что должно взорваться и когда.

Кроме того, вы используете модуль Weld JTA, который, как мне кажется, не соответствует какой-либо спецификации CDI (что означает его спецификацию для сварки), поэтому в любом случае, возможно, у него не было бы права говорить.

Теперь к решению, я думаю, что у вас есть справедливая точка с регистрацией, это действительно не помогает. Поэтому я пошел вперед и создал JIRA issue (WELD-2330). Так как это ветвь 3.x, она должна быть исправлена ​​довольно быстро. Не стесняйтесь вскакивать и говорить в нем или даже вносить свой вклад.

+0

Большое спасибо. Теперь мне просто нужно дождаться:) JBoss использовать последнюю версию Weld и b) клиента обновить до версии JBoss. Надеюсь, все это произойдет до Пасхи, когда мы продолжим жить ... :-) –

+0

Как работа до тех пор, я думаю, мы могли бы включить ведение журнала DEBUG для событий Weld и использовать фильтр регистрации, чтобы отключить материал, который мы надеваем 't want, à la http://middlewaremagic.com/jboss/?p=2421 –

+0

Хм, код, на который вы указали, находится на главной ветке (Weld 3.0/CDI 2.0), и в выпуске есть также исправление для 2.4 Weld (который находится в EAP 6.x/7.x и Wildfly). Однако, если вы используете JBoss AS 7, это не поможет вам; это Weld 1.x, который больше не активно развивается. В этом случае я буду бояться только с фильтрацией журнала отладки. Это так? – Siliarus