[logback-user] TurboFilter scope

[Espen Rydningen]

Hi

Thanks! I appreciate the clarification on this topic!

Espen

On Jul 13, 2010, at 7:17 PM, Ceki Gülcü wrote:

> 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?
> 
> _______________________________________________
> Logback-user mailing list
> Logback-user at qos.ch
> http://qos.ch/mailman/listinfo/logback-user