Re: [Xtraceprj-developers] xtrace 2 distribution thoughts
Brought to you by:
gporter,
rfonseca76
From: George P. <gp...@cs...> - 2008-03-29 04:18:17
|
I think we should 1) make a very lightweight library that links into users' code. This library shouldn't use log4j or system.*.printout If there is an error, it just silently ignores any logEvent() and similar calls [comments on this idea welcome] 2) Make the backend and proxy link with that lightweight library, but also add a bunch of other code. The backend and proxy should do logging using log4j. Alternatively, I believe that the Java runtime has a built-in logging library (Logger.*)? You can put various providers underneath it, including log4j. It should, I think, be possible to turn logging in the client library on or off dynamically, and not require any jar dependencies. Not 100% sure on this, but I'll look into it. Does anyone know a serious Java developer that we could ask about this? But taking out the logging from any code that links with the users' app is probably a good idea. Andy, can you just go through and comment out all the LOG.info() and LOG.debug() statements? Thanks, George On Mar 28, 2008, at 8:41 PM, Andy Konwinski wrote: > I'll volunteer to refactor the code, looks like we'll be pulling > log4j from TaskID, XTraceMetadata, and probably other classes. So > then that prompts the next question. should we just use > System.out.println() for what are currently the non warning/error > log4j messages, and System.err.println() for the warn/error > messages then? > > Andy > > On Fri, Mar 28, 2008 at 8:31 PM, George Porter > <gp...@ee...> wrote: > Be it resolved! No more log4j in the client library. > > -gp > > On Mar 28, 2008, at 8:29 PM, Matei Zaharia wrote: > > I also agree with not using Log4J from TaskID, it's best to keep > that > > part as small as possible. > > > > BTW have you thought of having separate jars for the client > > instrumentation library and the server? I know we discussed this a > > while back. The server one would contain all the dependencies. > > > > Matei > > > > On Mar 28, 2008, at 11:25 PM, Rodrigo Fonseca wrote: > > > >> Hi Andy, > >> > >> thanks for all the work. I made you and Matei admins. > >> I also agree that we should not use log4J from the TaskID class, > >> because it I am a user instrumenting my app, the X-Trace library > >> should be as little intrusive as possible, and require the least > >> amount of dependencies. This is different from requiring log4J for > >> the > >> proxy (daemon), because then it's another program... > >> > >> This is also a test of the list. > >> > >> Cheers, > >> Rodrigo > >> > >> > >> On Fri, Mar 28, 2008 at 8:17 PM, Andy Konwinski > >> <an...@ee... > >>> wrote: > >>> trying out the xtrace devel list, can you all ack this so i know > >>> our mailing > >>> list is indeed working. > >>> > >>> 1) we should be start using a bug-tracker religiously so we can > all > >>> communicate about things like bugs we find and fix. How about > using > >>> sourceforge's bug tracker. I was gonna add the below bugs to > the sf > >>> bugtracker but the categories are too narrowly defined right now > >>> (only two). > >>> and i got permission denied when i tried to add one. can you make > >>> me (and > >>> matei) a sourceforge proj god so i can make these sorts of > changes, > >>> i.e. add > >>> new bug categories? > >>> > >>> now to the bugs... > >>> > >>> 2) I tweaked the distribution process you created george in an > >>> effort to > >>> alleviate the pain of making users of the xtrace-2.0.jar also > >>> include any > >>> other jars in their class path when they want to use tracing. > Right > >>> now, we > >>> are using log4j in the TaskID class, so when I want to run my > >>> instrumented > >>> source code (i.e. as somebody walking through the sweet tutorial > >>> under the > >>> docs dir) i have to do something like (without newlines) > >>> > >>> java -cp /users/andykonwinski/Desktop/xtrace-2.0-080326/ > >>> lib/log4j-1.2.15.jar:/users/andykonwinski/Desktop/ > >>> xtrace-2.0-080326/lib/xtrace-2.0.jar:. Client > >>> > >>> and while this works, it is more convenient to unpack the log4j > >>> class files > >>> and include them directly within our jar. That is if we even want > >>> to use > >>> log4j in the TaskID class, maybe we should just take that out? I > >>> changed the > >>> jar creation task in the ant file to now pack as much of the > >>> distribution > >>> into the jar as possible, to alleviate the need for complex class > >>> paths when > >>> using it. Maybe we can talk more about this in person on Monday? > >>> Cause I > >>> have a lot of ideas here. > >>> > >>> 3) I also fixed a bug: graph_report.pl was losing the execution > >>> permission > >>> bit and had to be chmoded before it would work, the problem was > >>> with the ant > >>> task we were using, which was just copy. after the copy i added a > >>> chmod now. > >>> > >>> 4) i'm not positive the graph ui is working out of the box, will > >>> follow up > >>> after confirming this > >>> > >>> 5) I am working on the client server instrumentation tutorial now, > >>> which is > >>> why i'm flushing out all of these distribution related issues > >>> > >>> andy > >>> > >>> > >>> > -------------------------------------------------------------------- > >>> ----- > >>> Check out the new SourceForge.net Marketplace. > >>> It's the best place to buy or sell services for > >>> just about anything Open Source. > >>> > >>> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/ > >>> marketplace > >>> > >>> _______________________________________________ > >>> Xtraceprj-developers mailing list > >>> Xtr...@li... > >>> https://lists.sourceforge.net/lists/listinfo/xtraceprj-developers > >>> > >>> > >> > >> > --------------------------------------------------------------------- > >> ---- > >> Check out the new SourceForge.net Marketplace. > >> It's the best place to buy or sell services for > >> just about anything Open Source. > >> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/ > >> marketplace > >> _______________________________________________ > >> Xtraceprj-developers mailing list > >> Xtr...@li... > >> https://lists.sourceforge.net/lists/listinfo/xtraceprj-developers > > > > > > > ---------------------------------------------------------------------- > > --- > > Check out the new SourceForge.net Marketplace. > > It's the best place to buy or sell services for > > just about anything Open Source. > > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/ > > marketplace > > _______________________________________________ > > Xtraceprj-developers mailing list > > Xtr...@li... > > https://lists.sourceforge.net/lists/listinfo/xtraceprj-developers > > > ---------------------------------------------------------------------- > --- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/ > marketplace > _______________________________________________ > Xtraceprj-developers mailing list > Xtr...@li... > https://lists.sourceforge.net/lists/listinfo/xtraceprj-developers > > ---------------------------------------------------------------------- > --- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/ > marketplace_______________________________________________ > Xtraceprj-developers mailing list > Xtr...@li... > https://lists.sourceforge.net/lists/listinfo/xtraceprj-developers |