ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject Re: Ant2 logging
Date Thu, 10 May 2001 04:41:15 GMT
At 06:32  9/5/01 -0700, Diane Holt wrote:
>--- Peter Donald <donaldp@apache.org> wrote:
>> At 05:58  9/5/01 -0700, Diane Holt wrote:
>> >Will any of the various approaches being discussed allow me (either
>> >via some configuration-type approach or via a home-grown logger class)
>> >to have my logging come out like:
>> 
>> None of the discussion is related to that at all ;] - but presumably
>> what you want will be doable by customizing listeners ;)
>
>If that's the case, then I'm completely lost -- so can you (or anyone
>else) take me back a step and explain what it is that -is- being
>discussed? 

I will try

>Are you talking about replacing/changing the way the log()
>stuff in the source-files is done 

partially.

>(I thought the only thing we were
>looking to do with that was to internationalize it)? If that is what's
>being discussed, then I guess I must have missed the beginning, so could
>someone say (in non-flammable, non-Java-centric terms) what the ideas are
>for how/why it should be changed? (Or if you want to just point me to
>something in the archives or the docs to read, that'd be fine.)

essentially using 

log(Priority.DEBUG,"Message", exception);

is bad programming style for any number of reasons. It can get error-prone
fast and is less clear for programmers to follow. Both LogKit and Log4j
discourage this sort of approach for that reason. Ideally the UI is clearer
like below example which decreases cognitive load and complexity of
resulting code etc.

debug( "Message", exception );

If we were working with an Ant1 style system then this is the only change
we would need. The problem lies in the fact that we are adding both
threading and Task containers. 

Because we are dealing with threading we need to have some way of passing a
token with logger object instances. In some systems you could work around
this need by using separate ThreadGroups for each task combined with
InheritableThreadLocalVariables .. however this is overkill for ant2 and
would slow down processing very very very much.

You may claim that InheritableThreadLocalVariables are sufficient to
associate a thread with a task but as we have no control over certain
behaviours that make this void it would be nothing more than a hack to use
this - and would fail to work in some cases.

These tokens that are passed around are often called
categories/channels/subjects (Both logging toolkits call them categories). 

Containership of tasks is another issue. We have to have a way to indicate
that messages are coming from subtasks rather than parent task. And because
we want arbitrary containership it must be possible without building the
sub-tasks to be aware of their parenting. 

As it is highly likely that we will want a single container task to have
similar logging properties we have to have some safe way to have
hierarchial tokens passed between tasks and allow each sub-task to
instantiate sub-tokens of current token etc.

These tokens also align with the concept of "categories" in logkit/log4j -
both of which are hierarchial. I don't know of any clean way of doing this
without the notion of hierarchial tokens.

Now when ever a logger receives a log event it needs to be routed via
*something* to the ProjectListener. The *something* may also need to do
some extra operations. These extra operations are because ProjectListener
will no longer receive serial event stream (as threads make ant events
async). So it may need to reset task name to appropriate one etc.

Now this *something* has to be aware of priorities and hierarchial
categories, it has to allow a hook for aspect handlers and has to deliver
events to adapter for ProjectListener.

Now the aspect handler correlates strongly with the notion of filters
present in both logkit and log4j and the adpater as an implementation of
LogTarget/Appender.

So in simple terms Jon is saying we should build a facade that reimplements
the core of LogKit to do the routing and can be plugged in as appropriate.

Connor is saying we should build it ourselveas (though I am not sure he has
thought about all the implications yet).

Stefan saids we may need general hierarchial management - in which case
adopting logkit/log4j is not required. But we will defer discussion of this
till later.

I say we adopt a single logging toolkit to do this as they already offer
the features and the UI. All we have to do is write the filter and the
adapters. My opinion of course is that we use logkit as it is the most
lightweight and does not try to do all the extra funtionality (ie object
rendering et al). It is also designed to work in a "protected" environment
where you can't fiddle with your parent components bits. In theory you only
need the 6 of 9 core classes (Don't need ContextStack - which is equivelent
to log4js NDC, nor do you need formatter or LogKit - which is a deprecated
facade).

I thought it would be a nobrainer to use 6 classes from another project ...
guess I was a little wrong.

hmm that was a little longer than I thought it was going to be but thats
the basic explanation - wait for more of these points (async
ProjectListener, AspectHandler et al to be raised later).

Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*


Mime
View raw message