So I've been porting some of our services to use Logback over log4j and I've been using the log4j-over-slf4j jar to spoof log4j for our legacy dependencies. The only issue is log4j-over-slf4j doesn't implement many of the classes of log4j so I'm seeing a decent few class not found exceptions from dependent jars. How have people got around this? Is it enough to just put the nlog4j in your classpath instead of the log4j-over-slf4j jar? I'd still like to use one logback config file to drive all my logging to a single log file. Thanks. jt _______________________________________________ This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unless specifically indicated, this e-mail is not an offer to buy or sell or a solicitation to buy or sell any securities, investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Barclays. Any views or opinions presented are solely those of the author and do not necessarily represent those of Barclays. This e-mail is subject to terms available at the following link: www.barcap.com/emaildisclaimer. By messaging with Barclays you consent to the foregoing. Barclays Capital is the investment banking division of Barclays Bank PLC, a company registered in England (number 1026167) with its registered office at 1 Churchill Place, London, E14 5HP. This email may relate to or be sent from other members of the Barclays Group. _______________________________________________
The question has to be why do your dependent jars need to call these APIs in log4j? Unfortunately log4j does not differentiate between the interface for firing off log events (the sort of thing SLF4J/Commons logging provide) and its API for managing what is actually done for them. As a general rule libraries should only be using the bare minimum of logging (the equivalent of the SLF4J interface - which is what log4j-over-slf4j implements) and only the end user application should be defining things like appenders and turning logging on or off. If your dependent jars are using the log4j API for controlling what is done with logging events then either they have a real dependency on log4j for some good reason or else they are behaving badly. Without knowing what these dependencies are, what they are doing and why there's not much else can be said. (Of course you always have the option of using log4j as your slf4j implementation via slf4j-log4j; you can still pipe JULI & Commons Logging to SLF4J and use SLF4J in your own code and so end up with a single logging config file, just a log4j one rather than a logback one.) ----- Original Message -----
From: "Jeremy Truelove" <Jeremy.Truelove@barclayscapital.com> To: logback-user@qos.ch Sent: Wednesday, 27 October, 2010 1:30:22 PM Subject: [logback-user] Legacy Log4j Question So I've been porting some of our services to use Logback over log4j and I've been using the log4j-over-slf4j jar to spoof log4j for our legacy dependencies. The only issue is log4j-over-slf4j doesn't implement many of the classes of log4j so I'm seeing a decent few class not found exceptions from dependent jars. How have people got around this? Is it enough to just put the nlog4j in your classpath instead of the log4j-over-slf4j jar? I’d still like to use one logback config file to drive all my logging to a single log file. Thanks.
jt
_______________________________________________
This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unless specifically indicated, this e-mail is not an offer to buy or sell or a solicitation to buy or sell any securities, investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Barclays. Any views or opinions presented are solely those of the author and do not necessarily represent those of Barclays. This e-mail is subject to terms available at the following link: www.barcap.com/emaildisclaimer . By messaging with Barclays you consent to the foregoing. Barclays Capital is the investment banking division of Barclays Bank PLC, a company registered in England (number 1026167) with its registered office at 1 Churchill Place, London, E14 5HP. This email may relate to or be sent from other members of the Barclays Group.
_______________________________________________ _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
Unfortunately I don't have the ability to change these dependencies and I don't know why they are coded in the way they are so they have such a hard dependency on log4j. Is there any plan to add the rest of the classes to log4j-over-slf4j just to support legacy jar dependency issues? -----Original Message----- From: logback-user-bounces@qos.ch [mailto:logback-user-bounces@qos.ch] On Behalf Of Robert Elliot Sent: Wednesday, October 27, 2010 8:46 AM To: logback users list Subject: Re: [logback-user] Legacy Log4j Question The question has to be why do your dependent jars need to call these APIs in log4j? Unfortunately log4j does not differentiate between the interface for firing off log events (the sort of thing SLF4J/Commons logging provide) and its API for managing what is actually done for them. As a general rule libraries should only be using the bare minimum of logging (the equivalent of the SLF4J interface - which is what log4j-over-slf4j implements) and only the end user application should be defining things like appenders and turning logging on or off. If your dependent jars are using the log4j API for controlling what is done with logging events then either they have a real dependency on log4j for some good reason or else they are behaving badly. Without knowing what these dependencies are, what they are doing and why there's not much else can be said. (Of course you always have the option of using log4j as your slf4j implementation via slf4j-log4j; you can still pipe JULI & Commons Logging to SLF4J and use SLF4J in your own code and so end up with a single logging config file, just a log4j one rather than a logback one.) ----- Original Message -----
From: "Jeremy Truelove" <Jeremy.Truelove@barclayscapital.com> To: logback-user@qos.ch Sent: Wednesday, 27 October, 2010 1:30:22 PM Subject: [logback-user] Legacy Log4j Question So I've been porting some of our services to use Logback over log4j and I've been using the log4j-over-slf4j jar to spoof log4j for our legacy dependencies. The only issue is log4j-over-slf4j doesn't implement many of the classes of log4j so I'm seeing a decent few class not found exceptions from dependent jars. How have people got around this? Is it enough to just put the nlog4j in your classpath instead of the log4j-over-slf4j jar? I’d still like to use one logback config file to drive all my logging to a single log file. Thanks.
jt
_______________________________________________
This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unless specifically indicated, this e-mail is not an offer to buy or sell or a solicitation to buy or sell any securities, investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Barclays. Any views or opinions presented are solely those of the author and do not necessarily represent those of Barclays. This e-mail is subject to terms available at the following link: www.barcap.com/emaildisclaimer . By messaging with Barclays you consent to the foregoing. Barclays Capital is the investment banking division of Barclays Bank PLC, a company registered in England (number 1026167) with its registered office at 1 Churchill Place, London, E14 5HP. This email may relate to or be sent from other members of the Barclays Group.
_______________________________________________ _______________________________________________ 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's said in the past that the answer is no. After all, what would it do? You have to bear in mind that it's intended to redirect log4j to slf4j - so it has to be slf4j implementation agnostic. So it can't actually *do* anything with programmatic attempts to change the levels of Logger instances or add Appenders; the most you could have is a no operation implementation. That would probably result in loads of null pointer exceptions as your dependent jars try to use objects retrieved via the API, not to mention that if your dependent jars actually need to do these things then they will be broken even if no exception is thrown immediately. (One possibility I could see is adding all the classes and methods to be binary compatible but making all the methods throw an UnsupportedOperationException explaining why log4j-over-slf4j only implements a small subset of log4j's API so that people aren't left wondering about ClassNotFoundExceptions - which might have saved you having this conversation, but wouldn't actually solve your problem.) If you have a hard dependency on log4j that you can't change then I guess you have to use log4j. ----- Original Message -----
From: "Jeremy Truelove" <Jeremy.Truelove@barclayscapital.com> To: logback-user@qos.ch Sent: Wednesday, 27 October, 2010 1:58:27 PM Subject: Re: [logback-user] Legacy Log4j Question Unfortunately I don't have the ability to change these dependencies and I don't know why they are coded in the way they are so they have such a hard dependency on log4j. Is there any plan to add the rest of the classes to log4j-over-slf4j just to support legacy jar dependency issues?
-----Original Message----- From: logback-user-bounces@qos.ch [mailto:logback-user-bounces@qos.ch] On Behalf Of Robert Elliot Sent: Wednesday, October 27, 2010 8:46 AM To: logback users list Subject: Re: [logback-user] Legacy Log4j Question
The question has to be why do your dependent jars need to call these APIs in log4j? Unfortunately log4j does not differentiate between the interface for firing off log events (the sort of thing SLF4J/Commons logging provide) and its API for managing what is actually done for them. As a general rule libraries should only be using the bare minimum of logging (the equivalent of the SLF4J interface - which is what log4j-over-slf4j implements) and only the end user application should be defining things like appenders and turning logging on or off.
If your dependent jars are using the log4j API for controlling what is done with logging events then either they have a real dependency on log4j for some good reason or else they are behaving badly. Without knowing what these dependencies are, what they are doing and why there's not much else can be said.
(Of course you always have the option of using log4j as your slf4j implementation via slf4j-log4j; you can still pipe JULI & Commons Logging to SLF4J and use SLF4J in your own code and so end up with a single logging config file, just a log4j one rather than a logback one.)
----- Original Message -----
From: "Jeremy Truelove" <Jeremy.Truelove@barclayscapital.com> To: logback-user@qos.ch Sent: Wednesday, 27 October, 2010 1:30:22 PM Subject: [logback-user] Legacy Log4j Question So I've been porting some of our services to use Logback over log4j and I've been using the log4j-over-slf4j jar to spoof log4j for our legacy dependencies. The only issue is log4j-over-slf4j doesn't implement many of the classes of log4j so I'm seeing a decent few class not found exceptions from dependent jars. How have people got around this? Is it enough to just put the nlog4j in your classpath instead of the log4j-over-slf4j jar? I’d still like to use one logback config file to drive all my logging to a single log file. Thanks.
jt
_______________________________________________
This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unless specifically indicated, this e-mail is not an offer to buy or sell or a solicitation to buy or sell any securities, investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Barclays. Any views or opinions presented are solely those of the author and do not necessarily represent those of Barclays. This e-mail is subject to terms available at the following link: www.barcap.com/emaildisclaimer . By messaging with Barclays you consent to the foregoing. Barclays Capital is the investment banking division of Barclays Bank PLC, a company registered in England (number 1026167) with its registered office at 1 Churchill Place, London, E14 5HP. This email may relate to or be sent from other members of the Barclays Group.
_______________________________________________ _______________________________________________ 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
On 27.10.2010 15:08, Robert Elliot wrote:
Ceki's said in the past that the answer is no. After all, what would it do? You have to bear in mind that it's intended to redirect log4j to slf4j - so it has to be slf4j implementation agnostic. So it can't actually *do* anything with programmatic attempts to change the levels of Logger instances or add Appenders, the most you could have is a no operation implementation. That would probably result in loads of null pointer exceptions as your dependent jars try to use objects retrieved via the API, not to mention that if your dependent jars actually need to do these things then they will be broken even if no exception is thrown immediately.
Indeed I have said as much in the past. However, if users are willing to go through the trial and error process, I think we could add more missing classes and/or methods with NOP implementations. As long as the caller is satisfied with nop, things should be OK.
(One possibility I could see is adding all the classes and methods to be binary compatible but making all the methods throw an UnsupportedOperationException explaining why log4j-over-slf4j only implements a small subset of log4j's API so that people aren't left wondering about ClassNotFoundExceptions - which might have saved you having this conversation, but wouldn't actually solve your problem.)
NOP could be a viable alternative.
If you have a hard dependency on log4j that you can't change then I guess you have to use log4j.
I agree but may be the caller could be satisfied with NOP. It should be possible to satisfy most callers except perhaps in certain cases which could become rather hard to diagnose due to the NOP trickery...
----- Original Message -----
From: "Jeremy Truelove"<Jeremy.Truelove@barclayscapital.com> To: logback-user@qos.ch Sent: Wednesday, 27 October, 2010 1:58:27 PM Subject: Re: [logback-user] Legacy Log4j Question Unfortunately I don't have the ability to change these dependencies and I don't know why they are coded in the way they are so they have such a hard dependency on log4j. Is there any plan to add the rest of the classes to log4j-over-slf4j just to support legacy jar dependency issues?
-----Original Message----- From: logback-user-bounces@qos.ch [mailto:logback-user-bounces@qos.ch] On Behalf Of Robert Elliot Sent: Wednesday, October 27, 2010 8:46 AM To: logback users list Subject: Re: [logback-user] Legacy Log4j Question
The question has to be why do your dependent jars need to call these APIs in log4j? Unfortunately log4j does not differentiate between the interface for firing off log events (the sort of thing SLF4J/Commons logging provide) and its API for managing what is actually done for them. As a general rule libraries should only be using the bare minimum of logging (the equivalent of the SLF4J interface - which is what log4j-over-slf4j implements) and only the end user application should be defining things like appenders and turning logging on or off.
If your dependent jars are using the log4j API for controlling what is done with logging events then either they have a real dependency on log4j for some good reason or else they are behaving badly. Without knowing what these dependencies are, what they are doing and why there's not much else can be said.
(Of course you always have the option of using log4j as your slf4j implementation via slf4j-log4j; you can still pipe JULI& Commons Logging to SLF4J and use SLF4J in your own code and so end up with a single logging config file, just a log4j one rather than a logback one.)
----- Original Message -----
From: "Jeremy Truelove"<Jeremy.Truelove@barclayscapital.com> To: logback-user@qos.ch Sent: Wednesday, 27 October, 2010 1:30:22 PM Subject: [logback-user] Legacy Log4j Question So I've been porting some of our services to use Logback over log4j and I've been using the log4j-over-slf4j jar to spoof log4j for our legacy dependencies. The only issue is log4j-over-slf4j doesn't implement many of the classes of log4j so I'm seeing a decent few class not found exceptions from dependent jars. How have people got around this? Is it enough to just put the nlog4j in your classpath instead of the log4j-over-slf4j jar? I’d still like to use one logback config file to drive all my logging to a single log file. Thanks.
jt
Yes, I am flip-flopping. On 27.10.2010 16:15, Ceki Gulcu wrote:
On 27.10.2010 15:08, Robert Elliot wrote:
Ceki's said in the past that the answer is no. After all, what would it do? You have to bear in mind that it's intended to redirect log4j to slf4j - so it has to be slf4j implementation agnostic. So it can't actually *do* anything with programmatic attempts to change the levels of Logger instances or add Appenders, the most you could have is a no operation implementation. That would probably result in loads of null pointer exceptions as your dependent jars try to use objects retrieved via the API, not to mention that if your dependent jars actually need to do these things then they will be broken even if no exception is thrown immediately.
Indeed I have said as much in the past. However, if users are willing to go through the trial and error process, I think we could add more missing classes and/or methods with NOP implementations. As long as the caller is satisfied with nop, things should be OK.
(One possibility I could see is adding all the classes and methods to be binary compatible but making all the methods throw an UnsupportedOperationException explaining why log4j-over-slf4j only implements a small subset of log4j's API so that people aren't left wondering about ClassNotFoundExceptions - which might have saved you having this conversation, but wouldn't actually solve your problem.)
NOP could be a viable alternative.
If you have a hard dependency on log4j that you can't change then I guess you have to use log4j.
I agree but may be the caller could be satisfied with NOP.
It should be possible to satisfy most callers except perhaps in certain cases which could become rather hard to diagnose due to the NOP trickery...
----- Original Message -----
From: "Jeremy Truelove"<Jeremy.Truelove@barclayscapital.com> To: logback-user@qos.ch Sent: Wednesday, 27 October, 2010 1:58:27 PM Subject: Re: [logback-user] Legacy Log4j Question Unfortunately I don't have the ability to change these dependencies and I don't know why they are coded in the way they are so they have such a hard dependency on log4j. Is there any plan to add the rest of the classes to log4j-over-slf4j just to support legacy jar dependency issues?
-----Original Message----- From: logback-user-bounces@qos.ch [mailto:logback-user-bounces@qos.ch] On Behalf Of Robert Elliot Sent: Wednesday, October 27, 2010 8:46 AM To: logback users list Subject: Re: [logback-user] Legacy Log4j Question
The question has to be why do your dependent jars need to call these APIs in log4j? Unfortunately log4j does not differentiate between the interface for firing off log events (the sort of thing SLF4J/Commons logging provide) and its API for managing what is actually done for them. As a general rule libraries should only be using the bare minimum of logging (the equivalent of the SLF4J interface - which is what log4j-over-slf4j implements) and only the end user application should be defining things like appenders and turning logging on or off.
If your dependent jars are using the log4j API for controlling what is done with logging events then either they have a real dependency on log4j for some good reason or else they are behaving badly. Without knowing what these dependencies are, what they are doing and why there's not much else can be said.
(Of course you always have the option of using log4j as your slf4j implementation via slf4j-log4j; you can still pipe JULI& Commons Logging to SLF4J and use SLF4J in your own code and so end up with a single logging config file, just a log4j one rather than a logback one.)
----- Original Message -----
From: "Jeremy Truelove"<Jeremy.Truelove@barclayscapital.com> To: logback-user@qos.ch Sent: Wednesday, 27 October, 2010 1:30:22 PM Subject: [logback-user] Legacy Log4j Question So I've been porting some of our services to use Logback over log4j and I've been using the log4j-over-slf4j jar to spoof log4j for our legacy dependencies. The only issue is log4j-over-slf4j doesn't implement many of the classes of log4j so I'm seeing a decent few class not found exceptions from dependent jars. How have people got around this? Is it enough to just put the nlog4j in your classpath instead of the log4j-over-slf4j jar? I’d still like to use one logback config file to drive all my logging to a single log file. Thanks.
jt
On Wed, Oct 27, 2010 at 10:15 AM, Ceki Gulcu <ceki@qos.ch> wrote:
If you have a hard dependency on log4j that you can't change then I guess you have to use log4j.
I agree but may be the caller could be satisfied with NOP.
It should be possible to satisfy most callers except perhaps in certain cases which could become rather hard to diagnose due to the NOP trickery...
In that case it might be nice to let the caller implement the log4j functionality or at least allow it to be optionally included so the caller *can* implement it. For what it is worth it I haven't ever had this problem. --Nik
Since the existing log4j-over-slf4j doesn't include the classes at all the caller could implement them, couldn't they? Just in a separate jar. ----- Original Message -----
From: "Nikolas Everett" <nik9000@gmail.com> To: "logback users list" <logback-user@qos.ch> Sent: Wednesday, 27 October, 2010 3:23:24 PM Subject: Re: [logback-user] Legacy Log4j Question On Wed, Oct 27, 2010 at 10:15 AM, Ceki Gulcu < ceki@qos.ch > wrote:
If you have a hard dependency on log4j that you can't change then I guess you have to use log4j.
I agree but may be the caller could be satisfied with NOP.
It should be possible to satisfy most callers except perhaps in certain cases which could become rather hard to diagnose due to the NOP trickery...
In that case it might be nice to let the caller implement the log4j functionality or at least allow it to be optionally included so the caller *can* implement it.
For what it is worth it I haven't ever had this problem.
--Nik _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
participants (4)
-
Ceki Gulcu -
Jeremy.Truelove＠barclayscapital.com -
Nikolas Everett -
Robert Elliot