[JBoss-dev] [ jboss-Bugs-561683 ] Remove log4j dependency on client side
Bugs item #561683, was opened at 2002-05-28 22:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=561683group_id=22866 Category: None Group: v3.1 Status: Closed Resolution: Fixed Priority: 3 Submitted By: Sacha Labourey (slaboure) Assigned to: Sacha Labourey (slaboure) Summary: Remove log4j dependency on client side Initial Comment: Currently, log4.jar is needed by some jbossXX-client.jar. Consequently, log4j.jar is needed on the client side for no good reason. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=561683group_id=22866 ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [ jboss-Bugs-561683 ] Remove log4j dependency on client side
Jason4j, The wrapper is specific to Log4j, we could make it non-specific, but then we get into writting our own logging infrastructer, which is not something I would suggest. ... What is your beef with log4j? I still don't understand why you want it to go. Jason, my view is extremly simple. While I do see a hugggee interest in log4j (I do really love it, be sure of that, I do) and I even do see a huee interest in log4j on the client side ***while*** developping/debugging, I see absolutely *no* interest in log4j (that I still love) on the client side while running in production. Worst, I really think that this is bad design/packaging. You tell me we use log4j on the client side for errors and warnings. That's not good in production. Either we have a bad behaviour and an exception is raised (RemoteException exists for any EJB method for example), either we shut up. Would you appreciate, while we run your new nice command line tool that you just implemented, that the tool output is suddently messed up with warnings and info messages from log4j... just because log4j had something to say? Not in production. Then, I don't want to write my own loggging infrastructure (I repeat it: I am super-fan of log4j). It is just that we already have and use a wrapper for log4j. Why have we done that? For many reasons, one of them being to be able to change the logging infrastructure we use or more simply send it to /dev/null. It is a minimalistic change. I will take a look at it. And remember: I love log4j. ;) Cheers, Sacha4j ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-561683 ] Remove log4j dependency on client side
On Wed, May 29, 2002 at 04:26:26PM -0700, Jason Dillon wrote: The wrapper is specific to Log4j, we could make it non-specific, but then we get into writting our own logging infrastructer, which is not something I would suggest. Why on earth would you need to do something like that? All you'd need is a standard interface, and then either a NULL implementation (so no logging) or something to use the native JDK 1.4+ logging. Either way, you reduce the dependency on Log4J. It looks like I might get some free time in the next month or so: where's the wrapper, so myself (or someone else) can take a look at it? Why reinvent the wheel, or in this case logging. Log4j does everything we want and keeps most of the crap we don't want or need pluggable, so don't have to use it. It's a case of horses for courses: log4j is great, but not everyone wants to use it. What is your beef with log4j? I still don't understand why you want it to go. From my reading of the thread, it appears to be a desire not to dictate to the client more dependencies than are absolutely necessary. Once a client side app has been developed, it could be deployed to a large number of users at a site, and they'd have very little need for logging (though, clearly, that makes diagnosing problems harder for the sysadmin there) I agree that it's nearly insane to remove _all_ logging, but println()s might be enough to track where things are interesting on a debugged, distributed to the user, client side app. Cheers, Simon -- The idea of a karaoke version of ``My Way'' that lasts for 3750 minutes is just too frightening to consider. Programming Ruby, the Pragmatic Programmers ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-561683 ] Remove log4j dependency on client side
Jason Dillon wrote: You people are all insane. The size is small, and can be made even smaller if it really needs to be. Having light weight clients does not mean we must drop all client-side logging or hack together our own ultra-minimal logging framework or revert to System.out/printStackTrace garbage. Log4j is small, fast, configurable and just what we need. Sure, but how is it configured for the client? Where do log entries go for the client? On the client machine isn't always the right answer. -danch ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-561683 ] Remove log4j dependency on client side
Jason, my view is extremly simple. While I do see a hugggee interest in log4j (I do really love it, be sure of that, I do) and I even do see a huee interest in log4j on the client side ***while*** developping/debugging, I see absolutely *no* interest in log4j (that I still love) on the client side while running in production. Worst, I really think that this is bad design/packaging. So, disable all warnings, or probably limit the threashold to FATAL in production for clients. You tell me we use log4j on the client side for errors and warnings. That's not good in production. Either we have a bad behaviour and an exception is raised (RemoteException exists for any EJB method for example), either we shut up. Would you appreciate, while we run your new nice command line tool that you just implemented, that the tool output is suddently messed up with warnings and info messages from log4j... just because log4j had something to say? Not in production. That just means that I want to change the config, not rip out logging. Then, I don't want to write my own loggging infrastructure (I repeat it: I am super-fan of log4j). It is just that we already have and use a wrapper for log4j. Why have we done that? For many reasons, one of them being to be able to change the logging infrastructure we use or more simply send it to /dev/null. It is a minimalistic change. I will take a look at it. Yes, that is good... I am not really convinced that we need the wrapper either, but we have it and it does not really hurt us. But if you want to change how the logging system behaves then change the Log4j configuration, else we start treding down the path of writting our own logging infrastructure (like to determin if we use a Log4j Logger or a Null Logger and su on). I do not feel that we really need org.jboss.logging.Logger, it is only there to give us easy access to TRACE, though you will probably find that classes that use TRACE do not use DEBUG... perhaps a few do, but for the most part they do not. I understand Scott's reasoning for doing this, but I think we could really go either way. We want to limit the loggers which are verbose so we can easily debug problems with out having to change code. This can be done wil DEBUG and a configuration to only enable DEBUG for specified loggers. Anyways, I understand your point about production, and I believe that the solution is to provide a default log4j.properties which sets the console threshold to FATAL. I belive that if and when there is something really bad going on that it would be better to bitch than to eat the error. But if a client wants to remove the console appender they certainly can, perhaps replace it with a file appender or a null appender. I think we should provide a client/log4j.properties, and then either use the `bin/classpath.sh --client` to setup the basic client classpath (which will include client/ + the files inside and/or instruct the clients to also include that directory in the classpath + the required jars. This is currently not the case, but can be made the case very easily. Then we can have a single logging config for the client, which we don't have to worry about (Log4j will handle the details for us). This means we probably should remove any existing log4j.properties from client jars. BTW, I think we should do the same for jndi.properties --jason And remember: I love log4j. ;) =] --jason ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [ jboss-Bugs-561683 ] Remove log4j dependency on client side
Jason, Which is the part you don't understand? Cheers, Sacha Um... what? --jason ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [ jboss-Bugs-561683 ] Remove log4j dependency on client side
Log4j on the client side is the only way to trace/debug problems with client side code. In the case of JBossMQ, 1/2 of all the work is done on the client side! It's super important to keep the ability to trace client side code. Regards, Hiram From: Sacha Labourey [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: Jason Dillon [EMAIL PROTECTED] Subject: RE: [JBoss-dev] [ jboss-Bugs-561683 ] Remove log4j dependency on client side Date: Wed, 29 May 2002 12:26:20 +0200 Jason, Which is the part you don't understand? Cheers, Sacha Um... what? --jason ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development _ Chat with friends online, try MSN Messenger: http://messenger.msn.com ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-561683 ] Remove log4j dependency on client side
Log4j is our logging infrastructure, server and client side... why would we want to remove that? --jason On Wednesday 29 May 2002 03:26 am, Sacha Labourey wrote: Jason, Which is the part you don't understand? Cheers, Sacha Um... what? --jason ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-561683 ] Remove log4j dependency on client side
Note, we should be using log4j-core.jar on the client, to reduce the footprint. I have not checked to see if this is the case. --jason On Wednesday 29 May 2002 06:31 am, Hiram Chirino wrote: Log4j on the client side is the only way to trace/debug problems with client side code. In the case of JBossMQ, 1/2 of all the work is done on the client side! It's super important to keep the ability to trace client side code. Regards, Hiram From: Sacha Labourey [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: Jason Dillon [EMAIL PROTECTED] Subject: RE: [JBoss-dev] [ jboss-Bugs-561683 ] Remove log4j dependency on client side Date: Wed, 29 May 2002 12:26:20 +0200 Jason, Which is the part you don't understand? Cheers, Sacha Um... what? --jason ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development _ Chat with friends online, try MSN Messenger: http://messenger.msn.com ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [ jboss-Bugs-561683 ] Remove log4j dependency on client side
Log4j is our logging infrastructure, server and client side... why would we want to remove that? ?!!??? Log4j is our logging infrastructure on the *server* side, yes. But the client side isn't *your* infrastructure but the user's infrastructure. What if the user wants to use another log4j version? etc. our client side code mustn't be so intrusive. You know what I mean? Cheers, Sacha ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-561683 ] Remove log4j dependency on client side
Log4j is our logging infrastructure on the *server* side, yes. But the client side isn't *your* infrastructure but the user's infrastructure. What if the user wants to use another log4j version? etc. our client side code mustn't be so intrusive. JBoss code is running on both sides. We don't want to sacrafice logging on the client. There is alot going on there, especialy now will client interceptors. What is the big deal with the jar? We ship with a default version of the log4j.properties which only spews warnings or errors (or we should do so, and it is quite easy). And if they really want to disable all of if then they configure Log4j to use null loggers and appenders. You know what I mean? We do not want to loose logging on the client side... and we do not want to have two seperate logging interfaces... and we deffinetly don't want to start putting System.out and printStackTrace() into that code. Your previous email sounded like you wanted to remove Log4j on the client... and I think that would be a horrible idea. Why do you want it out? You must have had a reason to send the email. Can you explain what your pain was and perhaps we can find a better solution to it (other than ditching log4j on the client). ? --jason ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-561683 ] Remove log4j dependency on client side
With dynamic proxies and client side interceptors there is JBoss code on both side. We just need to run even if log4j is not present on the client side. There is no reason to ban log4j use on code that may show up in an external client because that code may in fact be running in the same VM as the server if the client is collocated. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Sacha Labourey [EMAIL PROTECTED] To: Jason Dillon [EMAIL PROTECTED]; Sacha Labourey [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, May 29, 2002 3:29 PM Subject: RE: [JBoss-dev] [ jboss-Bugs-561683 ] Remove log4j dependency on client side Log4j is our logging infrastructure, server and client side... why would we want to remove that? ?!!??? Log4j is our logging infrastructure on the *server* side, yes. But the client side isn't *your* infrastructure but the user's infrastructure. What if the user wants to use another log4j version? etc. our client side code mustn't be so intrusive. You know what I mean? Cheers, Sacha ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [ jboss-Bugs-561683 ] Remove log4j dependency on client side
Why do you want it out? You must have had a reason to send the email. Can you explain what your pain was and perhaps we can find a better solution to it (other than ditching log4j on the client). Yes. I agree that we need to have tools to debug our stuff. My problem is that log4j is only used for debugging but in reality it means that that all beans in production now must have log4j on the client side. It is like saying: we absolutely need Junit and Jmeter for testing our stuff, consequently all clients applications needs to have these on their classpath because it is easier for us.. If I am remember well, we never use log4j directly, right? but a wrapper class? What I meant was: couldn't we make the wrapper not require log4j by default. ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-561683 ] Remove log4j dependency on client side
Yes. I agree that we need to have tools to debug our stuff. My problem is that log4j is only used for debugging but in reality it means that that all beans in production now must have log4j on the client side. This is not true, log4j is used to indicate errors and warnings as well. It is like saying: we absolutely need Junit and Jmeter for testing our stuff, consequently all clients applications needs to have these on their classpath because it is easier for us.. I think this is an extreme view... but I can see how you might have derived this from the above. If I am remember well, we never use log4j directly, right? but a wrapper class? What I meant was: couldn't we make the wrapper not require log4j by default. The wrapper is specific to Log4j, we could make it non-specific, but then we get into writting our own logging infrastructer, which is not something I would suggest. Why reinvent the wheel, or in this case logging. Log4j does everything we want and keeps most of the crap we don't want or need pluggable, so don't have to use it. If size is your issue... the minimal jar (log4j-core.jar) is only 76k... which I think is peanuts in the general case, and can be trimmed if required for ultraminamalists. What is your beef with log4j? I still don't understand why you want it to go. --jason ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-561683 ] Remove log4j dependency on client side
They seem to have dropped log4j-core.jar in 1.2.2 as I couldn't find it. The log4j-boot.jar is probably the same thing. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: Hiram Chirino [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, May 29, 2002 3:24 PM Subject: Re: [JBoss-dev] [ jboss-Bugs-561683 ] Remove log4j dependency on client side Note, we should be using log4j-core.jar on the client, to reduce the footprint. I have not checked to see if this is the case. --jason ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [ jboss-Bugs-561683 ] Remove log4j dependency on client side
|If I am remember well, we never use log4j directly, right? but a wrapper |class? What I meant was: couldn't we make the wrapper not require log4j by |default. clearly please no log4j on the client, test or no test on our part please no... let's keep it lightweight, marcf | | |___ | |Don't miss the 2002 Sprint PCS Application Developer's Conference |August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-561683 ] Remove log4j dependency on client side
You people are all insane. The size is small, and can be made even smaller if it really needs to be. Having light weight clients does not mean we must drop all client-side logging or hack together our own ultra-minimal logging framework or revert to System.out/printStackTrace garbage. Log4j is small, fast, configurable and just what we need. --jason On Wednesday 29 May 2002 07:47 pm, marc fleury wrote: |If I am remember well, we never use log4j directly, right? but a wrapper |class? What I meant was: couldn't we make the wrapper not require log4j by |default. clearly please no log4j on the client, test or no test on our part please no... let's keep it lightweight, marcf |___ | |Don't miss the 2002 Sprint PCS Application Developer's Conference |August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-561683 ] Remove log4j dependency on client side
Bugs item #561683, was opened at 2002-05-28 22:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=561683group_id=22866 Category: None Group: v3.1 Status: Open Resolution: None Priority: 3 Submitted By: Sacha Labourey (slaboure) Assigned to: Nobody/Anonymous (nobody) Summary: Remove log4j dependency on client side Initial Comment: Currently, log4.jar is needed by some jbossXX-client.jar. Consequently, log4j.jar is needed on the client side for no good reason. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=561683group_id=22866 ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
