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

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hi folks,
=20
Just to drop in my opinion: if we're trying to avoid shipping a JAR and
if 1.4+ is not a problem, let's just go for using JDK logging. That
avoids the jar.
=20
If we want a really flexible logging library and do not mind the extra
jar, I'm ok with the current log4j solution.
=20
Let's in no case build our own wrapper or try to build a "simple"
logging system. We'll end up with code we don't want to maintain. And
System.out/.err is evil, but I don't need to tell you that, hopefully
(at least we want control over the levels of output). For the Ant task,
we should be redirecting the log4j output to the ant taskdef.
=20
My two cents,
=20
Mark.
=20
  _____ =20

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

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

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

=20

  _____ =20

From: cob...@li...
[mailto:cob...@li...] On Behalf Of Jeremy
Thomerson
Sent: Friday, August 19, 2005 05:19
To: Grzegorz Lukasik
Cc: Seigel, James; Mark Doliner; cob...@li...
Subject: Re: [Cobertura-devel] cobertura-runtime.jar?

My 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 going 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 for 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 effort 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 plug-n-play.

JT

On 8/18/05, Grzegorz Lukasik <ha...@gm...> wrote:=20

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