[logback-user] TurboFilter scope

[Ceki Gülcü]

Hi Espen,

As far as performance goes, using a turbo filter would not bring any
benefits (as in zero benefit) which goes to explain why appenders take
regular filters a not turbo filters. As Ralph ruggested earlier, just
use a regular filter and you will be fine.


On 13/07/2010 3:53 PM, Espen Rydningen wrote:
> Hi Ralph
>
> The main reason for wanting to use the turbo filter, is performance. The
> web application has a very large user mass, within the banking
> community, and our customers expects the application to perform. When
> that is said, I have not any real evaluation on the difference between
> turbo filter and regular filter yet, so I'm only leaning on the logback
> documentation on that matter.
>
> Espen
>
> On Tue, Jul 13, 2010 at 3:44 PM, Ralph Goers <rgoers at apache.org
> <mailto:rgoers at apache.org>> wrote:
>
>     Why do you want to use a TurboFilter instead of a regular filter?
>
>     Ralph
>
>     On Jul 13, 2010, at 6:15 AM, Espen Rydningen wrote:
>
>>     Sorry for the double post, gmail pulled a trick on me :) Just
>>     ignore the other post.
>>
>>     Hi
>>
>>     I want to revisit this subject and theme. I saw that this thread
>>     ended 20th May 2008
>>     <http://marc.info/?l=logback-user&m=121130259107132&w=2>, but I
>>     did not find any conclusions on your discussion. The reason I find
>>     this subject interesting, is that I have use case which I can't
>>     seem to solve in any other way then setting a turbofilter on an
>>     appender.
>>
>>     This is situation:
>>     One enterprise web application, which today uses a proprietary,
>>     home built, logging framework, logs statement to both file and to
>>     a database via an EJB. I have started the work to replace this
>>     logging framework with LogBack/SL4J.
>>
>>     Our new design would include file appender, and a jms appender
>>     which posts to a jms queue.
>>
>>     Example of log statements in the current solution:
>>     <codeSnippet>
>>                     //The logger is the file logger
>>                     logger.debug("Bar property was not defined in
>>     abc.properties");
>>
>>                     //FooLog is responsible for sending log message to
>>     the EJB
>>                     LogContext lctx = new LogContext("webapplication",
>>     getClass().getName(), "theFooBarMethod()", LayerType.PRESENTATION);
>>                     FooLog.log(logcontext, 6001, new String[] { "Bar
>>     property was not defined in abc.properties" }, null);
>>     </codeSnippet>
>>
>>     This type of logging I want to change to this kind of logging:
>>     <codeSnippet>
>>                     logger.debug("Bar property was not defined in
>>     abc.properties");
>>     </codeSnippet>
>>
>>     This is my use case:
>>     We need to separate which log statements that goes to file and
>>     which goes to JMS (and eventually to database)
>>
>>     This is how I want to solve it:
>>
>>     This would only go to file
>>     <codeSnippet>
>>                     logger.debug("Bar property was not defined in
>>     abc.properties");
>>     </codeSnippet>
>>
>>     But this would go to both file and jms
>>     <codeSnippet>
>>                     Marker JMS_MARKER = MarkerFactory.getMarker("JMS");
>>                     logger.debug(JMS_MARKER, "Bar property was not
>>     defined in abc.properties");
>>     </codeSnippet>
>>
>>     This could be obtained by doing something like this:
>>
>>     <appender name="Queue" class="com.a.b.c.log.CustomJMSQueueAppender">
>>     <InitialContextFactoryName>org.apache.activemq.jndi.ActiveMQInitialContextFactory</InitialContextFactoryName>
>>     <ProviderURL>tcp://localhost:61616</ProviderURL>
>>     <QueueConnectionFactoryBindingName>ConnectionFactory</QueueConnectionFactoryBindingName>
>>     <QueueBindingName>MyQueue</QueueBindingName>
>>
>>     <turboFilter class="ch.qos.logback.classic.turbo.MarkerFilter">
>>     <Marker>JMS</Marker>
>>     <OnMismatch>DENY</OnMismatch>
>>     </turboFilter>
>>
>>     </appender>
>>
>>     To end this; Is my use case covered in LogBack framework somehow,
>>     without waiting for this kind of features?