FOP, Avalon, Logging

[COFFMAN Steven <SC...@COVANSYS.com>]

Hi,
	Over at FOP, several (4) users have recently raised concerns with
FOP's adoption of Avalon and LogKit. The most valid complaint is by those
who had embedded FOP into applications that use Log4J and now have two
different logs. I remember the proposal to make a single Avalon interface
that either Log4J or LogKit could be plugged into interchangeably, but now
that Avalon 4.0 final is out, I wanted to raise the issue again. Also,
there's an alternative approach to the proposal that might have some good
ideas:
http://www.openinstitute.org/trunk/

-Steve

On Thu, 13 Sep 2001 22:40:13 -0400 Christopher Burkey wrote:
> At our company we have have found a solution to the logging dilemma and 
> think FOP should do the same.
> 
> At this point there seems to be several ways to log errors within a Java 
> application:
> 
> 1. JDK 1.4's new Logging API's
> 2. Log4J
> 3. Log Kit
> 4. Avalon's Loggable interface
> 5. Some new JDK compatible API's
> 
> The worst part about this situation is that one component might use Log4J 
> and another part of the same application may depend on Log Kit. So now
your 
> logs are spread all over the place within the same application.( Our 
> company is writing a Swing application that had this exact problem. )
> 
> The solution is:
> 
> Logging should be done in the same way JDBC is done. There should be one 
> set of interfaces and multiple drivers. Log Kit and Log4J considered the 
> equivalent of JDBC drivers such as Oracle, DB2 etc...
> 
> We put together Trunk ( http://www.openinstitute.org/trunk/ ) as a 
> collection of Interfaces compatible with multiple drivers.
> 
>  From the Trunk Docs:
> 
> LoggingDriver.getDriver()
> 	 *   <li>Get the value of the 
> <tt>org.openinstitute.trunk.LoggingDriver</tt> system property,
> 	 *     which must be a class that implements the {@link
LoggingDriver} 
> interface.
> 
> Example Usage: 	
> 
> Logger LOGGER = LoggingDriverFactory.getDriver().getLogger( 
> SomeApplication.class );
> 	  LOGGER.info("Hello world!");
> 
> Now FOP can use any driver such as Log4J or Log Kit.
> 
> 
> 
> 
> ________________________________________________
> Christopher Burkey		cburkey@einnovation.com	
> President		 	513-542-3401
> eInnovation Inc. 		http://einnovation.com
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org

Freundliche Grüsse
OUTLINE AG
Jeremias Märki

mailto:jeremias.maerki@outline.ch

Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
Fon +41 (41) 317 2020 - Fax +41 (41) 317 2029
Internet http://www.outline.ch


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org

Re: FOP, Avalon, Logging

[Peter Donald <do...@apache.org>]

On Sat, 15 Sep 2001 01:22, COFFMAN Steven wrote:
> Hi,
> 	Over at FOP, several (4) users have recently raised concerns with
> FOP's adoption of Avalon and LogKit. The most valid complaint is by those
> who had embedded FOP into applications that use Log4J and now have two
> different logs. 

In these cases it is probably best to create adapters between the two APIs 
(ie have an appender that delivers to LogKit system or a LogTarget that 
delivers to Log4j system). When I originally switched the majority of my apps 
away from using Log4j (at about version Log4J 0.64) this is what I did and it 
worked reasonably okay.

> I remember the proposal to make a single Avalon interface
> that either Log4J or LogKit could be plugged into interchangeably, but now
> that Avalon 4.0 final is out, I wanted to raise the issue again. 

You should have raised the issue earlier ;) The problem in changing Loggable 
interface now would break backwards compatability with the framework. I don't 
really like the idea of doing this to a supposedly stable API - especially 
such an essential part of framework. It would have been better to have made 
this change during alpha or at worst beta phases but not now because it will 
break too much stuff.

Then again I know it will also help in introducing the framework into some 
existing systems. So I guess it is not so bad. Maybe if we release next 
version of Framework, LogKit and re-release Excalibur (so they all work with 
released jars) then I wouldn't -1 it ... ;)

> Also,
> there's an alternative approach to the proposal that might have some good
> ideas:
> http://www.openinstitute.org/trunk/

Thats similar to what I proposed ages ago to Ceki and it is also similar to 
the proposal in jakarta commons. The problem is that adopting such an 
interface doesn't really gain you anything. It just creates a 6th API that 
you have to learn. 

In time it will become largely unnecessary - as jdk1.4 becomes "standard" 
install most people will move to that toolkit and it will become THE standard 
and all the other logging APIs will go away much like JGL (a great 
collections library pre-jdk1.2).

-- 
Cheers,

Pete

*--------------------------------*
| Every rule has an exception,   |
| except the rule of exceptions. |
*--------------------------------*

---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org