commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rsi...@us.ibm.com
Subject Re: [Logging] more issues with stack reading
Date Fri, 26 Jul 2002 23:14:36 GMT
>On Fri, 26 Jul 2002 rsitze@us.ibm.com wrote:

>> I'd STILL like to see this explicit, rather than "hidden" behind magic 
>> attributes:
>
>The benefit of attributes ( like those used in SAX, DOM, XSLT, etc ) 
>is that it is more flexible and allows implementations to expose 
>specific features.

That's exactly my point:  for commons-logging we want to minimize that 
exposure.  Specific API's open the *just* enough to accomplish the 
required deed, but no more.  setAttribute blasts a hole in the wall.

>> Regarding versioning - the 2nd edition of the Java Language 
Specification 
>> states that as long as we don't break our contract (i.e. remove 
methods)
>> with precompiled binaries, we can add-to the existing interfaces 
(13.5.3).
>
>I'm not sure this is correct. Adding methods to an existing interface
>is what happened to JDBC Connection in JDK1.4 - and the result is that 
>it is impossible to have a connection pool that works with both 1.3 and 
>1.4.

Hmm... one to doubt the spec huh?  Can't blame experience :-)
I'd like to understand that better.

>>  Similarly for classes (LogFactory).  So, I believe that we should be 
OK 
>> with adding methods to Log and LogFactory - but I would take a very 
>> conservative approach to that.  To-wit: adding 'entry/exit' log methods 

>> should be of the same form as the the current log interface (sans 
>> throwable parameter): (Object message).
>
>I'm -0 ( very close to -1 ) on entry/exit.
There are logging implementations (and loggers implemented under Log) that 
have these (apparently more than one - the query for this from another 
user was entirely independent of the other I'm aware of..).  As long as 
the 'logic' is eliminated (specifying return types, parameter lists, etc) 
- I'm OK with this.

>> That said, I'd like to explore the idea of separate interfaces for 
>> new/difference 'features'.  Rather than changing the Log interface, we 
can 
>> introduce a NEW interface:
>> 
>>   interface WrappedLog { public void setWrapperClass(Class clazz); }

>I don't like this... We'll end up with a mess of interfaces. I don't 
>know any existing API that follows this model, at least no 'mainstream'
>API.
I thought somewhere in Excalibur or Avalon or other far-off fairy-land.. 
:-)
Seriously, the idea doesn't originate from me, I saw it somewhere in 
open-source first.

As long as we take the conservative approach, we shouldn't end up with a 
mess of interfaces.  There is VERY LITTLE config I would expect to expose. 
 In this case, we don't have configuration settings for the loggers, and I 
appreciate the importance of a meaningful log.

One way to solve this it to push a new attribute into the logging 
implementations that defines the outermost wrapper class.  I'm just sure 
Ceki will love that requirement :-).

>I do agree with your concern on adding configuration features via 
>attributes - but setWrapperClass is in fact a configuration feature,
>added in the worst way.

Can you justify this?  Yes, it's config.  But via the interface it's 
carefully controlled/exposed,

If we expose this ONE attribute in the LogFactory implementation, what 
other attributes filter down next?  How are you going to expose the Log 
implementation to this attribute w/o changing the interface?

>I suppose the only way to sort this out is via vote.

Could be.  I'm learning a lot... I'd hate to loose that :-)

The alternatives I think we are discussing are (I'm tossing in a few from 
previous thoughts, sorry for taking the liberties, now it's your turn :-):

1.  Log.setAttribute()
2.  Log.setWrapperClass()
3.  LogImpl(String wrapperClass, String category) with logic in LogFactory 
to look for this constructor.
4.  separate SetWrapper interface, as described previously, 
5.  Asking log implementations to provide configuration attributes for 
wrapper class(es).
6.  Exposing MBeans (I like this a lot, but it's going to be some work..)
7.  Drop the whole thing, give up on commons-logging, and put our flag in 
JDK 1.4.

Did I miss anything?

>Costin

<ras>

--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>



--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message