Yes, but remember that in the big picture we are as much about solving
problems by using existing assets as we are about adding to
org.apache.common.*.  Please, lets not invite changes without clearly
understood requirements.

In this case Geir's proposal requires (somewhere, and I admit that we don't
care where) a supporting framework to be useful.  It may be that the Avalon
solution solves this problem for this Geir by providing both the framework
AND the logger interface, independent of any one logger (which is a goal of
the commons logging - remember that Avalon did that first, even if not in
line with what we wanted for org.apache.commons.logging).

If the requirement stands after the group conversation, great.  If not, say
bye-bye until such time as we have a clear picture for the greater need.

In this case, my vote would be -1 to changing commons-logging (Am I a
voting member under the new by-laws or not?  I'm a committer in Axis, and
I've submitted changes to commons logging) for the reasons above.

I could be swayed if Geir is set on working within commons logging, but I
think he has a existing solution elsewhere that is more than appropriate
for his needs.

Note also that if we introduce the "push" model, and we really desire to
remain consistent within the Jakarta community, then sooner or later we
will want to have that "push" model functional under the Avalon component
framework.... do we REALLY want to go there???  I'll repeat that they
ALREADY HAVE a logger independent interface with minimal supporting
framework.

While it would be nice to talk about a common interface for both commons
logging and LogKit, it must be pointed out that there are fundamental
differences in the API generally used by the user, most notable being
"Object message" versus "String message".

<ras>

*******************************************
Richard A. Sitze            [EMAIL PROTECTED]
CORBA Interoperability & WebServices
IBM WebSphere Development


                                                                                       
                      
                      <costinm@covalen                                                 
                      
                      t.net>                   To:      Jakarta Commons Developers 
List                      
                                               <[EMAIL PROTECTED]>, 
<[EMAIL PROTECTED]>        
                      04/03/2002 02:26         cc:                                     
                      
                      PM                       Subject: Re: [logging]  Need 
interface...                     
                      Please respond                                                   
                      
                      to "Jakarta                                                      
                      
                      Commons                                                          
                      
                      Developers List"                                                 
                      
                                                                                       
                      
                                                                                       
                      




On Wed, 3 Apr 2002, Morgan Delagrange wrote:

> Is that not also the case with Log4J and JDK 1.4?
> Only the Avalon logger has a notion of IoC AFAIK.  It
> seems odd to be supporting IoC logging in
> commons-logging, when we know that all of our other
> components will not be able to utilize it.

Please move the discussion about IoC and Avalon to avalon-dev.

The proposal didn't mentioned IoC and I don't see how this get into
this.

Most of the components implement Beans patterns and should support
runtime changes to config ( JMX or not ). That has nothing to
do with any inversion of control, it's standard java.

Avalon and IoC are 'special' in that they require only one way
to do things - and that's not something we'll do in commons or
other projects. But that's their problem, not ours.

Costin



--
To unsubscribe, e-mail:   <
mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <
mailto:[EMAIL PROTECTED]>





--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to