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 <[email protected] <mailto:[email protected]>> 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 [email protected] http://qos.ch/mailman/listinfo/logback-user
