RE: [Cobertura-devel] cobertura-runtime.jar?

[Jared R. <Jar...@sa...>]

Remember that Log4J has intentionally broken their backwards compatibili=
ty in the past. Having a thin wrapper around any logging mechanism (or a=
ny "third party" code) is usually a good idea. It buys you a lot of flex=
ibility and removes your dependence on a single toolkit.
 
Jared
http://www.jaredrichardson.net
 


________________________________

=09From: cob...@li... [mailto:cobertura-d=
eve...@li...] On Behalf Of Sinke, Mark (GE Healthcar=
e)
=09Sent: Friday, August 19, 2005 7:08 AM
=09To: je...@th...; Grzegorz Lukasik
=09Cc: Seigel, James; Mark Doliner; cob...@li...=
t
=09Subject: RE: [Cobertura-devel] cobertura-runtime.jar?
=09
=09
=09Hi folks,
=09 
=09Just to drop in my opinion: if we're trying to avoid shipping a JAR a=
nd if 1.4+ is not a problem, let's just go for using JDK logging. That a=
voids the jar.
=09 
=09If we want a really flexible logging library and do not mind the extr=
a jar, I'm ok with the current log4j solution.
=09 
=09Let's in no case build our own wrapper or try to build a "simple" log=
ging system. We'll end up with code we don't want to maintain. And Syste=
m.out/.err is evil, but I don't need to tell you that, hopefully (at lea=
st we want control over the levels of output). For the Ant task, we shou=
ld be redirecting the log4j output to the ant taskdef.
=09 
=09My two cents,
=09 
=09Mark.
=09 
________________________________

=09Mark J. Sinke
=09Senior Software Architect/Lead System Designer Plasma 2.0 (http://pla=
sma.health.ge.com <http://plasma.health.ge.com/> )
=09GE Healthcare Information Technologies
=09Core Infrastructure Platforms

=09T +31 30 692 6000
=09F +31 30 692 6010
=09D *381 6446
=09E mar...@me... <mailto:mar...@me...>  

=09www.gehealthcare.com <http://www.gehealthcare.com/> 

=09 

________________________________

=09From: cob...@li... [mailto:cobertura-d=
eve...@li...] On Behalf Of Jeremy Thomerson
=09Sent: Friday, August 19, 2005 05:19
=09To: Grzegorz Lukasik
=09Cc: Seigel, James; Mark Doliner; cob...@li...=
t
=09Subject: Re: [Cobertura-devel] cobertura-runtime.jar?
=09
=09
=09My only question is this:  Do you really think the majority of users =
use JDK logging?  I'd venture to say that the majority of our users use =
either a home-grown logging solution, or one of the major ones available=
, like Log4J.  By the number of people that use Cobertura yet are not up=
 to JRE / JDK 1.4, this would seem to be the case.  But, I'm fine with g=
oing with a simple solution if that's what everyone wants.  I just think=
 that if we build it this way, it makes it really easy to add support fo=
r N different logging systems, it shouldn't matter if we support 1 or 10=
.  If we have the ability to dynamically determine if java.logging is on=
 the class path, and if so, use it, we can with minimum additional effor=
t see if another one is available.  And users who don't use one that we =
create can create one class to support their logging system. It's very p=
lug-n-play.
=09
=09JT
=09
=09
=09On 8/18/05, Grzegorz Lukasik <ha...@gm...> wrote: 

=09=09Jeremy,
=09=09
=09=09I suggest simplier version of your solution. Use just two loggers:
=09=09java logging api, and if cannot then use System.out/System.err. Th=
is
=09=09way majority of users will use JDK logging, and if someone needs t=
o 
=09=09use java version < 1.4 then raw output is provided.
=09=09
=09=09Grzegorz
=09=09
=09=09On 8/18/05, Jeremy Thomerson <jer...@gm...> wrote:
=09=09> This is actually along the lines of what I was thinking as well.=
  If I were 
=09=09> going to do it, here's what I would do:
=09=09>
=09=09>  Create a class like James suggested that is always the class we=
 go to to
=09=09> get a logger.
=09=09>  The logger it returns is an interface (IBasicLogger?) 
=09=09>  The factory class can check for several different common logger=
s, in the
=09=09> order that we prefer, and for each one you can have a class that=
 wraps the
=09=09> particular logger that it is designed to wrap with an implementa=
tion of our 
=09=09> basic interface.
=09=09>
=09=09>  example:
=09=09>
=09=09>  LoggingFactory:
=09=09>   -- static method getLogger(String name) : returns IBasicLogger
=09=09>  method basically goes through a list class names that we give i=
t, and for 
=09=09> each one, knows which concrete class (see below) to instantiate.=
  If it
=09=09> finds no implemented logging classes on the classpath, falls bac=
k to
=09=09> SystemBasicLogger
=09=09>
=09=09>  IBasicLogger:
=09=09>   -- standard logging methods (debug, info, error, error with Th=
rowable) 
=09=09>  Log4JBasicLogger:
=09=09>   -- implements IBasicLogger.  All calls to the interface method=
s get
=09=09> redirected to the Log4J logger that it contains (which is create=
d upon
=09=09> construction, using the name that was passed to getLogger(String=
)) 
=09=09>  SystemBasicLogger : implements IBasicLogger, formats and sends =
messages to
=09=09> System.out, System.err, as appropriate
=09=09>  <OtherLogger>BasicLogger : same as Log4J implementation, but re=
directs to
=09=09> whatever logging facility it is designed to wrap.
=09=09>
=09=09>  I'd love to work on this for the next release (not 1.6 on Monda=
y) if
=09=09> everyone likes it.
=09=09>
=09=09>  Jeremy
=09=09>
=09=09>
=09=09> On 8/18/05, Seigel, James < Jam...@av...> wrote:
=09=09> >
=09=09> > Wrap log4j and make a factory method that determines if it is =
there...
=09=09> >
=09=09> > public class Clogger { 
=09=09> >     private static Clogger logger =3D null;
=09=09> >
=09=09> >     public static Clogger getLogger() {
=09=09> >         if(logger =3D=3D null) {
=09=09> >             logger =3D determineLogger();
=09=09> >         } 
=09=09> >         return logger;
=09=09> >     }
=09=09> >
=09=09> >     private static Clogger determineLogger() {
=09=09> >         // class load log4j logger if fails
=09=09> >         // return Clogger instance of system.out.println
=09=09> >         // else return a "wrapped" log4j logger with forwardin=
g methods
=09=09> >     }
=09=09> >
=09=09> >     .
=09=09> >     .
=09=09> >     .
=09=09> >
=09=09> > } 
=09=09> >
=09=09> > Just as an idea.....but I am on holiday..brain broken
=09=09> >
=09=09> > Cheers
=09=09> > James.
=09=09> >
=09=09> > -----Original Message-----
=09=09> > From: cob...@li...
=09=09> > [mailto: cob...@li...] On
=09=09> Behalf Of
=09=09> > Grzegorz Lukasik 
=09=09> > Sent: Thursday, August 18, 2005 1:33 PM
=09=09> > To: Mark Doliner
=09=09> > Cc: cob...@li...
=09=09> > Subject: Re: [Cobertura-devel] cobertura-runtime.jar?
=09=09> >
=09=09> > Here are two additional articles about JCL written by the auth=
or of
=09=09> > log4j. The conclusion of both is the same - JCL can produce un=
expected
=09=09> > problems with its "dynamic discovery mechanism". 
=09=09> >
=09=09> > Think again before adopting the commons-logging API
=09=09> > http://www.qos.ch/logging/thinkAgain.jsp
=09=09> >
=09=09> > Taxonomy of class loader problems encountered when using Jakar=
ta Commons 
=09=09> > Logging
=09=09> > http://www.qos.ch/logging/classloader.jsp
=09=09> >
=09=09> >
=09=09> > Mentioned is also Simple Logging Facade for Java (SLF4J) as a 
=09=09> > replacement for JCL. The problem with all this solutions is th=
at we
=09=09> > would need concrete implementation of some logger included.
=09=09> >
=09=09> > Alternatively, we could use java logging api, but then Cobertu=
ra would 
=09=09> > not work with JDK<1.4 (what is not so bad afterall).
=09=09> >
=09=09> > I think that the easiest solution would be just to create our =
own
=09=09> > logging "system" (I will try to create it), so that we do not =
have to 
=09=09> > bother.
=09=09> >
=09=09> > Don't hesitate to send your comments.
=09=09> >
=09=09> >
=09=09> > Grzegorz
=09=09> >
=09=09> > On 8/18/05, Mark Doliner < Mar...@sa...> wrote:
=09=09> > > After reading that article, I kind of like Jakarta Commons L=
ogging.
=09=09> > It sounds like it would be small, not cause many conflicts, an=
d for most
=09=09> > people it would just use the logging built into JDK 1.4 and hi=
gher.  It
=09=09> > sounds like it's basically a simple logging class written by t=
he Jakarta
=09=09> > people.
=09=09> > > -Mark
=09=09> > >
=09=09> > > > -----Original Message-----
=09=09> > > > From: cob...@li...
=09=09> > > > [mailto: cob...@li... <mail=
to:cob...@li...> ]
=09=09> On
=09=09> > > > Behalf Of Grzegorz Lukasik
=09=09> > > > Sent: Thursday, August 18, 2005 7:35 AM
=09=09> > > > To: Mark Doliner
=09=09> > > > Cc: cob...@li...
=09=09> > > > Subject: Re: [Cobertura-devel] cobertura-runtime.jar?
=09=09> > > >
=09=09> > > > My vote goes to simple logging class. 
=09=09> > > >
=09=09> > > > Grzegorz
=09=09> > > >
=09=09> > > > On 8/18/05, Grzegorz Lukasik <ha...@gm... > wrote:
=09=09> > > > > I have checked some other tools (not too many as you can=
 see): 
=09=09> > > > >
=09=09> > > > > EMMA: homegrown logging utility
=09=09> > > > > Clover: in library they have org.apache.log subdirectory=
,
=09=09> > > > so maybe log4j is used
=09=09> > > > > NoUnit: Log4j
=09=09> > > > > Spring: Jakarta Commons Logging
=09=09> > > > > Tomcat: Jakarta Commons Logging
=09=09> > > > >
=09=09> > > > > BTW. Interesting note created by JCL author: 
=09=09> > > > > http://radio.weblogs.com/0122027/2003/08/15.html
=09=09> > > > >
=09=09> > > > > Grzegorz
=09=09> > > > > 
=09=09> > > > >
=09=09> > > > > On 8/18/05, Grzegorz Lukasik < ha...@gm...> wrote:
=09=09> > > > > > The one option that I like in log4j configuration now,=
 is the 
=09=09> > > > > > possibility to turn more verbose level on. As you wrot=
e,
=09=09> > > > if we will
=09=09> > > > > > use plain System.out/System.err solution we will have =
to
=09=09> > > > remove a lot 
=09=09> > > > > > of current output messages.
=09=09> > > > > >
=09=09> > > > > > Maybe we could use some very lighweight logger (single=
 class
=09=09> > with
=09=09> > > > > > debug, info, error methods). 
=09=09> > > > > >
=09=09> > > > > > I will check other tools, to check how they handle it.
=09=09> > > > > >
=09=09> > > > > > Grzegorz
=09=09> > > > > > 
=09=09> > > > > > On 8/17/05, Mark Doliner <ma...@ki...> wrote:
=09=09> > > > > > > Eh, I guess I don't have a strong opinion either way=
.
=09=09> > > > What do you think about
=09=09> > > > > > > maybe removing a lot of our current log4j output, an=
d
=09=09> > > > changing the rest to
=09=09> > > > > > > System.out or System.err, and getting rid of log4j e=
ntirely?
=09=09> > > > > > >
=09=09> > > > > > > -Mark
=09=09> > > > > > >
=09=09> > > > > > > On Tue, 16 Aug 2005 19:52:49 +0200, Grzegorz Lukasik=
 wrote 
=09=09> > > > > > > > I have created quick patch that replaces log4j cal=
ls
=09=09> > > > in coveragedata
=09=09> > > > > > > > package with System.out/System.err.
=09=09> > > > > > > > cobertura-runtime.jar is now created. It contains =
classes
=09=09> > from
=09=09> > > > > > > > coveragedata package and
=09=09> > > > > > > > all referenced. It does not depend on any librarie=
s. 
=09=09> > > > > > > >
=09=09> > > > > > > > I am not sure if it is a good solution. Any opinio=
ns?
=09=09> > > > > > > >
=09=09> > > > > > > > I have removed classpath entries in javac task tha=
t 
=09=09> > > > point to the
=09=09> > > > > > > > directory where class files
=09=09> > > > > > > > are copied - does it make any sense?
=09=09> > > > > > > > 
=09=09> > > > > > > > Grzegorz
=09=09> > > > > > > >
=09=09> > > > > > > > On 8/16/05, Grzegorz Lukasik <ha...@gm... > =
wrote:
=09=09> > > > > > > > > There is related RFE -
=09=09> > > > > > > > >
=09=09> > > > > > >
=09=09> > > >
=09=09> https://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D12=
55
=09=09> > > > 210&group_id=3D130558&atid=3D720018
=09=09> > > > > > > > >
=09=09> > > > > > > > > Maybe we could create cobertura.jar as normal, a=
nd
=09=09> > > > additionaly create
=09=09> > > > > > > > > cobertura-runtime.jar that can be optionally use=
d.
=09=09> > > > Not so nice
=09=09> > > > > > > > > solution, but 
=09=09> > > > > > > > > users would be able to upgrade without problems.
=09=09> > > > > > > > >
=09=09> > > > > > > > > cobertura-runtime.jar should not contain any 
=09=09> > > > references to dependend
=09=09> > > > > > > > > libraries - we could replace log4j with System.o=
ut,
=09=09> > > > System.err for
=09=09> > > > > > > > > coveragedata package (grrrrrr...). 
=09=09> > > > > > > > >
=09=09> > > > > > > > > Grzegorz
=09=09> > > > > > > > >
=09=09> > > > > > > > > On 6/17/05, Seigel, James < James.Seigel@avocent=
.com >
=09=09> > wrote:
=09=09> > > > > > > > > > I like having the one jar.  I will have to hav=
e
=09=09> > > > both around anyway.  No 
=09=09> > > > > > > > > > opinion on naming scheme.
=09=09> > > > > > > > > >
=09=09> > > > > > > > > > Cheers
=09=09> > > > > > > > > > James. 
=09=09> > > > > > > > > >
=09=09> > > > > > > > > > -----Original Message-----
=09=09> > > > > > > > > > From:
=09=09> cob...@li...
=09=09> > > > > > > > > >
=09=09> > > > [mailto: cob...@li... ]
=09=09> On Behalf Of
=09=09> > Mark
=09=09> > > > > > > > > > Doliner
=09=09> > > > > > > > > > Sent: Thursday, June 16, 2005 2:33 PM
=09=09> > > > > > > > > > To: cob...@li...
=09=09> > > > > > > > > > Subject: [Cobertura-devel] cobertura-runtime.j=
ar?
=09=09> > > > > > > > > > 
=09=09> > > > > > > > > > Cobertura currently consists of one jar file, =
and
=09=09> > > > this jar must be on
=09=09> > > > > > > > > > your classpath when instrumenting, running tes=
ts, 
=09=09> > > > and reporting.
=09=09> > > > > > > > > > However, when you actually run your tests, onl=
y
=09=09> > > > one of the packages in
=09=09> > > > > > > > > > this jar is used, and the package only require=
s log4j. 
=09=09> > > > > > > > > >
=09=09> > > > > > > > > > How do people feel about creating a cobertura.=
jar and a
=09=09> > > > > > > > > > cobertura-runtime.jar , where
=09=09> > > > cobertura-runtime.jar contains all the
=09=09> > > > > > > > > > classes in the package
=09=09> > > > net.sourceforge.cobertura.coveragedata.  And
=09=09> > > > > > > > > > cobertura.jar would contain everything else (a=
nt
=09=09> > > > tasks, instrumenting
=09=09> > > > > > > > > > code, reporting code, etc.)
=09=09> > > > > > > > > > 
=09=09> > > > > > > > > > The goal is to make it more clear that asm, nc=
ss,
=09=09> > > > jakarta-oro, etc. are
=09=09> > > > > > > > > > not required when running instrumenting code. =
 I 
=09=09> > > > think this would help
=09=09> > > > > > > > > > avoid classpath conflicts with ASM.
=09=09> > > > > > > > > >
=09=09> > > > > > > > > > Good idea?  Bad idea?  Suggestions for better 
=09=09> > > > names for the jars?
=09=09> > > > > > > > > > Should the jars include the version number in =
their name
=09=09> > > > > > > > > > ("cobertura-1.5.jar ")?  Should the runtime ja=
r
=09=09> > > > still use log4j, or
=09=09> > > > > > > > > > should we get rid of that dependency?
=09=09> > > > > > > > > >
=09=09> > > > > > > > > > FYI, I'll be out of town from now until Sunday=
 night.
=09=09> > > > > > > > > >
=09=09> > > > > > > > > > -Mark
=09=09> > > > > > > 
=09=09> > > > > > >
=09=09> > > > > >
=09=09> > > > >
=09=09> > > >
=09=09> > > >
=09=09> > > >
=09=09> ------------------------------------------------------- 
=09=09> > > > SF.Net email is Sponsored by the Better Software Conferenc=
e & EXPO
=09=09> > > > September 19-22, 2005 * San Francisco, CA * Development
=09=09> > > > Lifecycle Practices
=09=09> > > > Agile & Plan-Driven Development * Managing Projects & Team=
s * 
=09=09> > > > Testing & QA
=09=09> > > > Security * Process Improvement & Measurement *
=09=09> > > > http://www.sqe.com/bsce5sf
=09=09> > > > _______________________________________________ 
=09=09> > > > Cobertura-devel mailing list
=09=09> > > > Cob...@li...
=09=09> > > >
=09=09> https://lists.sourceforge.net/lists/listinfo/cobertura-devel
=09=09> > > >
=09=09> > >
=09=09> > >
=09=09> > > -------------------------------------------------------
=09=09> > > SF.Net email is Sponsored by the Better Software Conference =
& EXPO
=09=09> > > September 19-22, 2005 * San Francisco, CA * Development Life=
cycle
=09=09> > Practices
=09=09> > > Agile & Plan-Driven Development * Managing Projects & Teams =
* Testing 
=09=09> > & QA
=09=09> > > Security * Process Improvement & Measurement *
=09=09> > http://www.sqe.com/bsce5sf
=09=09> > > _______________________________________________ 
=09=09> > > Cobertura-devel mailing list
=09=09> > > Cob...@li...
=09=09> > >
=09=09> https://lists.sourceforge.net/lists/listinfo/cobertura-devel
=09=09> > >
=09=09> >
=09=09> >
=09=09> > -------------------------------------------------------
=09=09> > SF.Net email is Sponsored by the Better Software Conference & =
EXPO 
=09=09> > September 19-22, 2005 * San Francisco, CA * Development Lifecy=
cle
=09=09> > Practices
=09=09> > Agile & Plan-Driven Development * Managing Projects & Teams * =
Testing &
=09=09> > QA
=09=09> > Security * Process Improvement & Measurement * 
=09=09> > http://www.sqe.com/bsce5sf
=09=09> > _______________________________________________
=09=09> > Cobertura-devel mailing list
=09=09> > Cob...@li...
=09=09> >
=09=09> https://lists.sourceforge.net/lists/listinfo/cobertura-devel
=09=09> >
=09=09> > 
=09=09> > -------------------------------------------------------
=09=09> > SF.Net email is Sponsored by the Better Software Conference & =
EXPO
=09=09> > September 19-22, 2005 * San Francisco, CA * Development Lifecy=
cle 
=09=09> Practices
=09=09> > Agile & Plan-Driven Development * Managing Projects & Teams * =
Testing & QA
=09=09> > Security * Process Improvement & Measurement * http://www.sqe.=
com/bsce5sf 
=09=09> > _______________________________________________
=09=09> > Cobertura-devel mailing list
=09=09> > Cob...@li...
=09=09> >
=09=09> https://lists.sourceforge.net/lists/listinfo/cobertura-devel
=09=09> >
=09=09> >
=09=09> >
=09=09>
=09=09>
=09=09
=09=09
=09=09