WSO2 EI 6.1.1 - операторы журнала уровня API DEBUG, которые помещаются после посредника вызовов, не могут быть найдены в соответствующем файле журнала

Мне нужно зарегистрировать уровень DEBUG для определенного API. Я использую отдельный лог-файл для примера API: http://localhost:8280/test001. Я использовал для каждого API свойства log4j для этого требования (ссылка: https://docs.wso2.com/display/ESB490/Per-API+Logs+in+WSO2+ESB). ПРОБЛЕМА: журналы уровня DEBUG, которые помещаются после посредника вызовов, не могут быть найдены в файле.

мой API: test.xml

<?xml version="1.0" encoding="UTF-8"?><api context="/test001" name="test" xmlns="http://ws.apache.org/ns/synapse">
<resource methods="GET"><inSequence>
       <log category="DEBUG" level="custom">
            <property name="DEBUG category" value="DEBUG LOG BEFORE CALL MEDIATOR"/>
        </log>

        <call>
            <endpoint>
                <http method="get" uri-template="http://localhost:8280/sample001"/>
            </endpoint>
        </call>
        <log category="DEBUG" level="custom">
            <property name="DEBUG category" value="DEBUG LOG AFTER CALL MEDIATOR"/>
        </log>
        <log level="custom">
            <property name="INFO  category" value="INFO LOG AFTER CALL MEDIATOR"/>
        </log>
        <payloadFactory media-type="xml">
            <format>
                <test>SUCCESS</test>
            </format>
            <args/>
        </payloadFactory>
        <loopback description="loop backing to out-sequence"/>
    </inSequence>
    <outSequence>
        <log category="DEBUG" level="custom">
            <property name="DEBUG category" value=" DBUG OUT SEQUENCE"/>
        </log>
        <log level="custom">
            <property name="INFO category" value="INFO OUT SEUENCE"/>
        </log>
        <send/>
    </outSequence>
    <faultSequence>
        <log category="DEBUG" level="custom">
            <property name="log DEBUG" value=" DBUG FAULT SEQUENCE"/>
        </log>
        <log level="custom">
            <property name="log DEBUG" value="INFO FAULT SEUENCE"/>
        </log>
    </faultSequence></resource></api>

мои конфигурации log4j wso2ei-6.1.1 \ conf \ log4j.properties:

log4j.category.API_LOGGER.test =DEBUG,COMMON_API_APPENDER
log4j.appender.test.Append = true

log4j.appender.COMMON_API_APPENDER=org.apache.log4j.DailyRollingFileAppender
log4j.appender.COMMON_API_APPENDER.File=${carbon.home}/repository/logs/commonApi.log
log4j.appender.COMMON_API_APPENDER.datePattern='.'yyyy-MM-dd
log4j.appender.COMMON_API_APPENDER.layout=org.apache.log4j.PatternLayout
log4j.appender.COMMON_API_APPENDER.layout.ConversionPattern=%d{ISO8601} [%X{ip}-%X{host}] [%t] %5p %c{1} %m%n

Примечание. другие свойства в файле log4j.properties не изменяются.

commonApi.log:

2017-11-21 19:42:06,502 [-] [localhost-startStop-1]  INFO test Initializing API: test
2017-11-21 19:43:21,703 [-] [PassThroughMessageProcessor-1] DEBUG test DEBUG category = DEBUG LOG BEFORE CALL MEDIATOR
2017-11-21 19:43:22,021 [-] [PassThroughMessageProcessor-3] DEBUG test DEBUG category =  DBUG OUT SEQUENCE
2017-11-21 19:43:22,021 [-] [PassThroughMessageProcessor-3]  INFO test INFO category = INFO OUT SEUENCE

Как вы можете видеть в коде API, строка журнала:

DEBUG category = DEBUG LOG AFTER CALL MEDIATOR

отсутствует в файле commonApi.log.

wso2carbon.log:

TID: [-1234] [] [2017-11-21 19:43:21,703] DEBUG {API_LOGGER.test} -  DEBUG category = DEBUG LOG BEFORE CALL MEDIATOR {API_LOGGER.test}
TID: [-1234] [] [2017-11-21 19:43:21,711]  INFO {org.apache.synapse.core.axis2.TimeoutHandler} -  This engine will expire all callbacks after GLOBAL_TIMEOUT: 120 seconds, irrespective of the timeout action, after the specified or optional timeout {org.apache.synapse.core.axis2.TimeoutHandler}
TID: [-1234] [] [2017-11-21 19:43:22,004]  INFO {org.apache.synapse.mediators.builtin.LogMediator} -  To: /sample001, MessageID: urn:uuid:c7c63feb-9c3f-46f7-b3cb-9a9d0b4fb82e, Direction: request, Envelope: <?xml version='1.0' encoding='utf-8'?><soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"><soapenv:Body/></soapenv:Envelope> {org.apache.synapse.mediators.builtin.LogMediator}
TID: [-1234] [] [2017-11-21 19:43:22,019]  INFO {org.apache.synapse.mediators.builtin.LogMediator} -  INFO  category = INFO LOG AFTER CALL MEDIATOR {org.apache.synapse.mediators.builtin.LogMediator}
TID: [-1234] [] [2017-11-21 19:43:22,021] DEBUG {API_LOGGER.test} -  DEBUG category =  DBUG OUT SEQUENCE {API_LOGGER.test}
TID: [-1234] [] [2017-11-21 19:43:22,021]  INFO {org.apache.synapse.mediators.builtin.LogMediator} -  INFO category = INFO OUT SEUENCE {org.apache.synapse.mediators.builtin.LogMediator}
TID: [-1234] [] [2017-11-21 19:43:22,021]  INFO {API_LOGGER.test} -  INFO category = INFO OUT SEUENCE {API_LOGGER.test}

Но вы можете увидеть строку информационного журнала:

INFO  category = INFO LOG AFTER CALL MEDIATOR

в файле wso2carbon.log (это гарантирует выполнение после вызова-посредника).

Примечание. Однако я могу заверить вас в следующих вещах:

  • Это поток посредничества, который записывается после выполнения посредника вызова. (Я могу видеть информационные журналы в консоли.).
  • Посредник вызова успешно отвечает значениями.

  • Без посредника вызовов в API все строки журнала DEBUG присутствуют в файле commonApi.log (работает должным образом).

  • журналы вне очереди DEBUG присутствуют в файле в любом случае. (работает должным образом)

Заранее спасибо.!


person imasmohamed    schedule 21.11.2017    source источник
comment
Если во время вызова посредника произошла ошибка, сообщение будет передано в последовательность ошибок.   -  person simar    schedule 22.11.2017
comment
Как я уже упоминал в вопросе, посредник вызовов успешно отвечает значениями.! ваш комментарий не имеет отношения к этому вопросу.   -  person imasmohamed    schedule 23.11.2017


Ответы (1)


Вы уверены, что вам нужно использовать посредник вызовов в неблокирующем режиме (по умолчанию посредник вызовов неблокирующий)? Ваш код работает, если вы изменили режим на блокировку, как показано ниже.

<call blocking="true">

Или вы можете использовать <callout> посредник, который по умолчанию блокирует, чтобы получить тот же результат.

Поскольку журналы INFO работают, я думаю, что это может быть ошибка в WSO2 IE6.

person prageeth    schedule 22.11.2017