Logging filter match semantics

[mtopolnik]

I am trying to eliminate this warning message from the logs:

JBAS011006: Not installing optional component org.springframework.web.context.request.async.StandardServletAsyncWebRequest due to exception: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011054: Could not find default constructor for class org.springframework.web.context.request.async.StandardServletAsyncWebRequest

This is a well-known message related to a possible bug in Spring and has no ill consequences.

My problem is, this filter has no effect:

<filter>

  <not>

    <match pattern="JBAS011054" />

  </not>

</filter>

This one works:

<filter>

  <not>

    <match pattern="JBAS011006" />

  </not>

</filter>

but is not as selective as it should be because it applies to all "Not installing optional component" messages. This variant doesn't work, either:

<filter>

  <not>

    <match pattern="JBAS011006.*JBAS011054" />

  </not>

</filter>

So my question would be, what is the exact semantics of the regex? Does it match only against the message code before the colon?

[jamezp]

What version of JBoss AS, EAP or WildFly are you using?

Looking at the message it appears that the JBAS011054 message is coming in as a part of the message format. In older versions of the log manager the filters were only executed on the unformatted message. This was changed in 1.4.3.Final and 1.5.1.Final to allow the regex filter to be applied to formatted messages. You might just need to upgrade the jboss-logmanager module.

--

James R. Perkins

[mtopolnik]

I'm using AS 7.1.1.Final and I see it comes with logmanager version 1.2.2.GA. I have proceeded to upgrade logmanager to 1.5.1.Final, with no effect; I upgraded jboss-logging to 3.1.3.GA for good measure, but still no change.

[jamezp]

Where is the filter defined? If it's on a logger then it would need to be on the specific logger category the message is being logged from as loggers don't inherit filters. If it's on the handler, it should work. I just tried upgrading 7.1.1.Final to use jboss-logmanager-1.5.1.Final and it worked fine for me. Make sure you change the module.xml to point to the new version.

--

James R. Perkins

[mtopolnik]

This is the context:

        <subsystem xmlns="urn:jboss:domain:logging:1.1">

            <console-handler name="CONSOLE">

                <level name="INFO"/>

                <filter>

                    <not>

                        <match pattern="JBAS011054"/>

                    </not>

                </filter>

                <formatter>

                    <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>

                </formatter>

            </console-handler>

            <periodic-rotating-file-handler name="FILE">

                <filter>

                    <not>

                        <match pattern="JBAS011054"/>

                    </not>

                </filter>

                <formatter>

                    <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>

                </formatter>

                <file relative-to="jboss.server.log.dir" path="server.log"/>

                <suffix value=".yyyy-MM-dd"/>

                <append value="true"/>

            </periodic-rotating-file-handler>

I have edited module.xml and also deleted the old JARs. This is my modules/org/jboss/logmanager/main/module.xml:

<module xmlns="urn:jboss:module:1.1" name="org.jboss.logmanager">

    <resources>

        <resource-root path="jboss-logmanager-1.5.1.Final.jar"/>

        <!-- Insert resources here -->

    </resources>

    <dependencies/>

</module>

[jamezp]

Weird that looks similar to what I had. I just had a filter on the console-handler to filter out a deployment. My XML looks like:

<console-handler name="CONSOLE">
    <level name="INFO"/>
    <formatter>
        <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%X{testId}%E%n"/>
    </formatter>
    <filter>
        <not>
            <match pattern="jboss-as-helloworld\.war"/>
        </not>
    </filter>
</console-handler>

I saw nothing on the console about the deployment.

--

James R. Perkins

[mtopolnik]

Here's a summary of expressions which do and don't work against the message.

These don't work:

"JBAS011054"

"Could not find default constructor"

"ComponentDescription"

These work:

"JBAS011006"

"StandardServletAsyncWebRequest"

I don't what to make of this except that I can't escape the feeling that there's something fishy going on in the implementation.

[mtopolnik]

Correction: there is a simple explanation of my results. Pattern matching doesn't work against the string representation of the exception.

[jamezp]

Ah-ha, yes. That was going to be my next question. I'll have a test and look on whether that should be happening or not.

--

James R. Perkins