The download page [0] has had "It will be upgraded in the coming weeks." on it for quite a few months. Is there a status update to share? Is it being discontinued? Regarding the statement "It expects logback version 0.9.9.", will it fail with 0.9.18? I could not find a list of Eclipse versions it should work with. Anyone using it with Galileo? I was about to just "try it", but have had problems in the past trying to recover from incompatibilities, so hesitate. Also, as a feature, we were hoping for a simple picklist of log levels (or regexp to apply to the view) to real-time filter the view vs drop incoming messages. Any plans for a plugin update site vs manual install? [0] http://logback.qos.ch/download.html
Hello all, I need to name my log file as /${host-name}.log/ and the question is, how can I do it? In logback.xml I can use properties definition, but it's static, not dynamical evaluabled. System properties can't help me to, I can't define host on every application start. I can use LoggerContext, but I don't want to have 'compile' dependencies on logback classes. In version 0.9.17 was made possibility to save formatted timestamp in property. May be possible to create property evaluator tag, to dynamical define some properties value? Something like this: <property name="host name" evaluator="org.xxx.PropertyEvaluator"> <parameter name="host type">value</parameter> </property> Evaluator will be called on property initialization with listed parameters. I can make necessary patch for logback. May be I have said well-known truths :) Sorry and correct me. Best regards, Aleksey Didik
Hello Aleksey, What you describe would be a pretty useful feature to have. Can you please enter an enhancement request on our jira? Best regards, On 01/02/2010 11:12 AM, Aleksey Didik wrote:
Hello all,
I need to name my log file as /${host-name}.log/ and the question is, how can I do it? In logback.xml I can use properties definition, but it's static, not dynamical evaluabled. System properties can't help me to, I can't define host on every application start. I can use LoggerContext, but I don't want to have 'compile' dependencies on logback classes.
In version 0.9.17 was made possibility to save formatted timestamp in property. May be possible to create property evaluator tag, to dynamical define some properties value? Something like this:
<property name="host name" evaluator="org.xxx.PropertyEvaluator"> <parameter name="host type">value</parameter> </property>
Evaluator will be called on property initialization with listed parameters. I can make necessary patch for logback.
May be I have said well-known truths :) Sorry and correct me.
Best regards, Aleksey Didik
Hello Ceki done http://jira.qos.ch/browse/LBCLASSIC-182. I'll try to make patch if you want :) Best regards, Aleksey. 01.02.2010 20:17, Ceki Gülcü пишет:
Hello Aleksey,
What you describe would be a pretty useful feature to have. Can you please enter an enhancement request on our jira?
Best regards,
On 01/02/2010 11:12 AM, Aleksey Didik wrote:
Hello all,
I need to name my log file as /${host-name}.log/ and the question is, how can I do it? In logback.xml I can use properties definition, but it's static, not dynamical evaluabled. System properties can't help me to, I can't define host on every application start. I can use LoggerContext, but I don't want to have 'compile' dependencies on logback classes.
In version 0.9.17 was made possibility to save formatted timestamp in property. May be possible to create property evaluator tag, to dynamical define some properties value? Something like this:
<property name="host name" evaluator="org.xxx.PropertyEvaluator"> <parameter name="host type">value</parameter> </property>
Evaluator will be called on property initialization with listed parameters. I can make necessary patch for logback.
May be I have said well-known truths :) Sorry and correct me.
Best regards, Aleksey Didik
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
Hello, I have caught a problem of using embedded Jetty and slf4j, may be you can help me. Jetty tell me this one: java.lang.LinkageError: loader constraint violation: when resolving method "org.slf4j.impl.StaticLoggerBinder.getLoggerFactory()Lorg/slf4j/ILoggerFactory;" the class loader (instance of org/eclipse/jetty/webapp/WebAppClassLoader) of the current class, org/slf4j/LoggerFactory, and the class loader (instance of sun/misc /Launcher$AppClassLoader) for resolved class, org/slf4j/impl/StaticLoggerBinder, have different Class objects for the type org/slf4j/ILoggerFactory used in the signature [main o.e.j.u.l.Slf4jLog.warn:111] I have next jars: Embedded Jetty classpath: slf4j-api-1.5.10.jar logback-classic-0.9.18.jar War libs: slf4j-api-1.5.10.jar But I add slf4j-api-1.5.10.jar logback-classic-0.9.18.jar to WAR libs and delete logback-classic-0.9.18.jar from jetty classpath, all work fine. Best regards, Aleksey Didik
Hello Aleksey, I am not totally surprised by what you describe. According to the java laguage specification (JLS) two classes loaded by distinct class loaders are deemed incompatible even if the classes are bitwise identical. When the jetty class loader loads ch.qos.classic.Logger it also needs to load org.slf4j.Logger which it can, and does. When the ch.qos.classic.Logger is returned to your web-application as a org.slf4j.Logger as requested by your web-application, the returned Logger is not compatible with the expected Logger, even if they are both of type org.slf4j.Logger. Your web-application expects it to be loaded by the web-app's class loader but the returned instance is loaded by the jetty class loader, hence the error you observe. HTH, On 03.02.2010 18:36, Aleksey Didik wrote:
Hello, I have caught a problem of using embedded Jetty and slf4j, may be you can help me.
Jetty tell me this one:
java.lang.LinkageError: loader constraint violation: when resolving method "org.slf4j.impl.StaticLoggerBinder.getLoggerFactory()Lorg/slf4j/ILoggerFactory;" the class loader (instance of org/eclipse/jetty/webapp/WebAppClassLoader) of the current class, org/slf4j/LoggerFactory, and the class loader (instance of sun/misc /Launcher$AppClassLoader) for resolved class, org/slf4j/impl/StaticLoggerBinder, have different Class objects for the type org/slf4j/ILoggerFactory used in the signature [main o.e.j.u.l.Slf4jLog.warn:111]
I have next jars:
Embedded Jetty classpath: slf4j-api-1.5.10.jar logback-classic-0.9.18.jar
War libs: slf4j-api-1.5.10.jar
But I add slf4j-api-1.5.10.jar logback-classic-0.9.18.jar to WAR libs and delete logback-classic-0.9.18.jar from jetty classpath, all work fine.
Best regards, Aleksey Didik
If you think about it, this is one area where all the app servers seem to really suck. Having them in your war means your application can control the version and if you want to upgrade the process is really simple. If you have multiple web applications in the server each can be independently using their own stuff. Relying on the jars in the classpath can make it risky to upgrade them and might possibly break the app server. Ideally, the only thing that should be on the classpath that the application sees is the API that the app server provides. Everything else should be invisible behind a different classloader. Of course, if it was easy to do they would all be doing it that way. Ralph On Feb 3, 2010, at 10:56 AM, Nikolas Everett wrote:
Why not remove slf4j and logback from your war?
Nik _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
Yes, it's a variant, but in this case I can't use my war in another contanier (real jetty, tomcat ) without add slf4j jar to container libs. And it could be a cause of some conflicts, I think. Aleks. 03.02.2010 22:56, Nikolas Everett ?????:
Why not remove slf4j and logback from your war?
Nik
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
Hello Ceki, Thanks for explanation. It's clear now. I'll try to make something with this situation. Aleksey. 03.02.2010 21:46, Ceki Gulcu пишет:
Hello Aleksey,
I am not totally surprised by what you describe. According to the java laguage specification (JLS) two classes loaded by distinct class loaders are deemed incompatible even if the classes are bitwise identical.
When the jetty class loader loads ch.qos.classic.Logger it also needs to load org.slf4j.Logger which it can, and does. When the ch.qos.classic.Logger is returned to your web-application as a org.slf4j.Logger as requested by your web-application, the returned Logger is not compatible with the expected Logger, even if they are both of type org.slf4j.Logger. Your web-application expects it to be loaded by the web-app's class loader but the returned instance is loaded by the jetty class loader, hence the error you observe.
HTH,
On 03.02.2010 18:36, Aleksey Didik wrote:
Hello, I have caught a problem of using embedded Jetty and slf4j, may be you can help me.
Jetty tell me this one:
java.lang.LinkageError: loader constraint violation: when resolving method "org.slf4j.impl.StaticLoggerBinder.getLoggerFactory()Lorg/slf4j/ILoggerFactory;"
the class loader (instance of org/eclipse/jetty/webapp/WebAppClassLoader) of the current class, org/slf4j/LoggerFactory, and the class loader (instance of sun/misc /Launcher$AppClassLoader) for resolved class, org/slf4j/impl/StaticLoggerBinder, have different Class objects for the type org/slf4j/ILoggerFactory used in the signature [main o.e.j.u.l.Slf4jLog.warn:111]
I have next jars:
Embedded Jetty classpath: slf4j-api-1.5.10.jar logback-classic-0.9.18.jar
War libs: slf4j-api-1.5.10.jar
But I add slf4j-api-1.5.10.jar logback-classic-0.9.18.jar to WAR libs and delete logback-classic-0.9.18.jar from jetty classpath, all work fine.
Best regards, Aleksey Didik
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
Assuming jetty uses child-first a.k.a. local-first class loading order, I would recommend to bundle slf4j and logback jar in your war file. Jetty used to have the opposite class loading order, i.e. parent-first, but I am under the impression that it changed to local-first class loading in recent versions. BTW, Tomcat uses local-first class loading by default. HTH, On 04/02/2010 9:28 AM, Aleksey Didik wrote:
Hello Ceki, Thanks for explanation. It's clear now. I'll try to make something with this situation.
Aleksey.
03.02.2010 21:46, Ceki Gulcu пишет:
Hello Aleksey,
I am not totally surprised by what you describe. According to the java laguage specification (JLS) two classes loaded by distinct class loaders are deemed incompatible even if the classes are bitwise identical.
When the jetty class loader loads ch.qos.classic.Logger it also needs to load org.slf4j.Logger which it can, and does. When the ch.qos.classic.Logger is returned to your web-application as a org.slf4j.Logger as requested by your web-application, the returned Logger is not compatible with the expected Logger, even if they are both of type org.slf4j.Logger. Your web-application expects it to be loaded by the web-app's class loader but the returned instance is loaded by the jetty class loader, hence the error you observe.
HTH,
On 03.02.2010 18:36, Aleksey Didik wrote:
Hello, I have caught a problem of using embedded Jetty and slf4j, may be you can help me.
Jetty tell me this one:
java.lang.LinkageError: loader constraint violation: when resolving method "org.slf4j.impl.StaticLoggerBinder.getLoggerFactory()Lorg/slf4j/ILoggerFactory;"
the class loader (instance of org/eclipse/jetty/webapp/WebAppClassLoader) of the current class, org/slf4j/LoggerFactory, and the class loader (instance of sun/misc /Launcher$AppClassLoader) for resolved class, org/slf4j/impl/StaticLoggerBinder, have different Class objects for the type org/slf4j/ILoggerFactory used in the signature [main o.e.j.u.l.Slf4jLog.warn:111]
I have next jars:
Embedded Jetty classpath: slf4j-api-1.5.10.jar logback-classic-0.9.18.jar
War libs: slf4j-api-1.5.10.jar
But I add slf4j-api-1.5.10.jar logback-classic-0.9.18.jar to WAR libs and delete logback-classic-0.9.18.jar from jetty classpath, all work fine.
Best regards, Aleksey Didik
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
By the way, if the document on Jetty's class loading architecture [1] is accurate, than jetty uses local-first class loading as required by the servlet specs but with exceptions. Indeed, since jetty uses slf4j internally, it is part of what is called the "server classes" which jetty does NOT export to web-apps. So, bundling slf4j-api, logback-core and logback-classic in your web-app should work fine. Interestingly enough, jetty considers org.apache.log4j and org.apache.commons.logging as *system* classes which the web-app cannot override. I am sure there are good reasons for this strategy but it does not affect slf4j users, unless of course they are using log4j or if they are using jcl-over-slf4j. Yes, it's complicated... [1] http://docs.codehaus.org/display/JETTY/Classloading On 04/02/2010 9:41 AM, Ceki Gülcü wrote:
Assuming jetty uses child-first a.k.a. local-first class loading order, I would recommend to bundle slf4j and logback jar in your war file.
Jetty used to have the opposite class loading order, i.e. parent-first, but I am under the impression that it changed to local-first class loading in recent versions.
BTW, Tomcat uses local-first class loading by default.
HTH,
Jetty used to have the opposite class loading order, i.e. parent-first But if is it truth, it's a straight way to have problems like mine, isn't it?
No, I'm not right. Parent-first is preferable in my situation, because slf4j classes for webapp will be loaded from jetty class loader in this case, and no conflict here... Yes, I tried to change my embedded jetty class loading order to parent first and all works as I need with slf4j-only-WAR. But I tried to deploy slf4j-only-WAR to tomcat with slf4j+logback in Tomcat libs and caught the same linkage error. Tomcat use local-first order by default :) I think I can use embedded jetty with parent-first order and slf4j-only-WAR, but in this case I can't use this WAR in another contaners. Ok, I'll have logback+slf4j in my WAR. Thanks a lot for the help, Aleksey. 04.02.2010 12:52, Ceki Gülcü пишет:
By the way, if the document on Jetty's class loading architecture [1] is accurate, than jetty uses local-first class loading as required by the servlet specs but with exceptions. Indeed, since jetty uses slf4j internally, it is part of what is called the "server classes" which jetty does NOT export to web-apps. So, bundling slf4j-api, logback-core and logback-classic in your web-app should work fine.
Interestingly enough, jetty considers org.apache.log4j and org.apache.commons.logging as *system* classes which the web-app cannot override. I am sure there are good reasons for this strategy but it does not affect slf4j users, unless of course they are using log4j or if they are using jcl-over-slf4j.
Yes, it's complicated...
[1] http://docs.codehaus.org/display/JETTY/Classloading
On 04/02/2010 9:41 AM, Ceki Gülcü wrote:
Assuming jetty uses child-first a.k.a. local-first class loading order, I would recommend to bundle slf4j and logback jar in your war file.
Jetty used to have the opposite class loading order, i.e. parent-first, but I am under the impression that it changed to local-first class loading in recent versions.
BTW, Tomcat uses local-first class loading by default.
HTH,
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
Ceki Gülcü skrev:
Interestingly enough, jetty considers org.apache.log4j and org.apache.commons.logging as *system* classes which the web-app cannot override. I am sure there are good reasons for this strategy but it does not affect slf4j users, unless of course they are using log4j or if they are using jcl-over-slf4j.
If applications are used using Jetty contexts everything is overridable. The Jetty configuration file format is just a thin XML-layer on top of a quite sophisticated object creation hierarchy. Hence my suggestion to use it in logback. -- Thorbjørn Ravn Andersen "...plus... Tubular Bells!"
I have checked sonar bundle with embedded jetty, they use the same as you suggest. WAR have slf4j + logback libs and Embedded Jetty libs have slf4j + logback libs. Looks like it will be my solution too.
Jetty used to have the opposite class loading order, i.e. parent-first
But if is it truth, it's a straight way to have problems like mine, isn't it? Aleksey. 04.02.2010 12:41, Ceki Gülcü пишет:
Assuming jetty uses child-first a.k.a. local-first class loading order, I would recommend to bundle slf4j and logback jar in your war file.
Jetty used to have the opposite class loading order, i.e. parent-first, but I am under the impression that it changed to local-first class loading in recent versions.
BTW, Tomcat uses local-first class loading by default.
HTH,
On 04/02/2010 9:28 AM, Aleksey Didik wrote:
Hello Ceki, Thanks for explanation. It's clear now. I'll try to make something with this situation.
Aleksey.
03.02.2010 21:46, Ceki Gulcu пишет:
Hello Aleksey,
I am not totally surprised by what you describe. According to the java laguage specification (JLS) two classes loaded by distinct class loaders are deemed incompatible even if the classes are bitwise identical.
When the jetty class loader loads ch.qos.classic.Logger it also needs to load org.slf4j.Logger which it can, and does. When the ch.qos.classic.Logger is returned to your web-application as a org.slf4j.Logger as requested by your web-application, the returned Logger is not compatible with the expected Logger, even if they are both of type org.slf4j.Logger. Your web-application expects it to be loaded by the web-app's class loader but the returned instance is loaded by the jetty class loader, hence the error you observe.
HTH,
On 03.02.2010 18:36, Aleksey Didik wrote:
Hello, I have caught a problem of using embedded Jetty and slf4j, may be you can help me.
Jetty tell me this one:
java.lang.LinkageError: loader constraint violation: when resolving method "org.slf4j.impl.StaticLoggerBinder.getLoggerFactory()Lorg/slf4j/ILoggerFactory;"
the class loader (instance of org/eclipse/jetty/webapp/WebAppClassLoader) of the current class, org/slf4j/LoggerFactory, and the class loader (instance of sun/misc /Launcher$AppClassLoader) for resolved class, org/slf4j/impl/StaticLoggerBinder, have different Class objects for the type org/slf4j/ILoggerFactory used in the signature [main o.e.j.u.l.Slf4jLog.warn:111]
I have next jars:
Embedded Jetty classpath: slf4j-api-1.5.10.jar logback-classic-0.9.18.jar
War libs: slf4j-api-1.5.10.jar
But I add slf4j-api-1.5.10.jar logback-classic-0.9.18.jar to WAR libs and delete logback-classic-0.9.18.jar from jetty classpath, all work fine.
Best regards, Aleksey Didik
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
Ceki Gülcü skrev:
Assuming jetty uses child-first a.k.a. local-first class loading order, I would recommend to bundle slf4j and logback jar in your war file.
Jetty used to have the opposite class loading order, i.e. parent-first, but I am under the impression that it changed to local-first class loading in recent versions.
Default is servlet specification behaviour, but it is very easy to alter to parent-first. We use that to allow all web applications in the container to see the global slf4j and logback instances, as we want them to go together (for now). -- Thorbjørn Ravn Andersen "...plus... Tubular Bells!"
Hello all, patch for evaluable properties functionality was added to JIRA http://jira.qos.ch/browse/LBCLASSIC-182 Best regards, Aleksey Didik. 01.02.2010 20:37, Aleksey Didik пишет:
Hello Ceki
done http://jira.qos.ch/browse/LBCLASSIC-182.
I'll try to make patch if you want :)
Best regards, Aleksey.
01.02.2010 20:17, Ceki Gülcü пишет:
Hello Aleksey,
What you describe would be a pretty useful feature to have. Can you please enter an enhancement request on our jira?
Best regards,
On 01/02/2010 11:12 AM, Aleksey Didik wrote:
Hello all,
I need to name my log file as /${host-name}.log/ and the question is, how can I do it? In logback.xml I can use properties definition, but it's static, not dynamical evaluabled. System properties can't help me to, I can't define host on every application start. I can use LoggerContext, but I don't want to have 'compile' dependencies on logback classes.
In version 0.9.17 was made possibility to save formatted timestamp in property. May be possible to create property evaluator tag, to dynamical define some properties value? Something like this:
<property name="host name" evaluator="org.xxx.PropertyEvaluator"> <parameter name="host type">value</parameter> </property>
Evaluator will be called on property initialization with listed parameters. I can make necessary patch for logback.
May be I have said well-known truths :) Sorry and correct me.
Best regards, Aleksey Didik
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
participants (7)
-
Aleksey Didik -
Ceki Gulcu -
Ceki Gülcü
-
Jeff Jensen -
Nikolas Everett -
Ralph Goers -
Thorbjoern Ravn Andersen