[land] Land/Logging WAS: [lang] MethodUtils

[Henri Yandell <ba...@generationjava.com>]

On Thu, 31 Oct 2002, robert burrell donkin wrote:

> one of the consequences of MethodUtils being in lang is that lang can't
> depend on commons-logging. i found that without logging, it's nearly
> impossible to debug some things.

As a hypothetical, what are the bad sides to Lang being dependent on
Logging. It would obviously be nice to have a Lang which logs output.

I would hope that the JDK someday would have good internal logging
support.

However, Logging also might want to depend on Lang. So we have the classic
cyclic dependency. Solutions? Merge?

Anyways. I'm not proposing this, I just want to generate some thoughts..

Hen


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [land] Land/Logging WAS: [lang] MethodUtils

[Steve Downey <st...@netfolio.com>]

I think the API/implementation split for logging is the right way to handle 
it. As long as the API doesn't depend on [lang], and I don't see a reason it 
really should, the problem is fairly straightforward. Bootstraping the build 
will mean building logging-api, then lang, then the rest of logging. 

A bit messy, but not irretrievably so.

On Thursday 31 October 2002 10:04 pm, Henri Yandell wrote:
> On Thu, 31 Oct 2002, robert burrell donkin wrote:
> > one of the consequences of MethodUtils being in lang is that lang can't
> > depend on commons-logging. i found that without logging, it's nearly
> > impossible to debug some things.
>
> As a hypothetical, what are the bad sides to Lang being dependent on
> Logging. It would obviously be nice to have a Lang which logs output.
>
> I would hope that the JDK someday would have good internal logging
> support.
>
> However, Logging also might want to depend on Lang. So we have the classic
> cyclic dependency. Solutions? Merge?
>
> Anyways. I'm not proposing this, I just want to generate some thoughts..
>
> Hen



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>