On Tue,  7 Aug 2001 16:10, Berin Loritsch wrote:
> Peter Donald wrote:
> > Hi,
> >
> > Doh!
> >
> > I just got feedback that points out that it possible to do a
> > masquerade (sp?) attack against LogKit via something like
> >
> > getLogger().getLogTargets()[0].processEvent( myEvilEvent );
> >
> > So to fix this I suggest we deprecate Logger.getLogTargets() make it
> > return a zero sized array and instead add a "complimenting"
> > setLogTargets() as suggested below?
>
> Masquerading is bad.  What does the complimenting setLogTargets() afford
> us.  Won't that allow the same type of problem?

The main reason for "complimenting/additivity" (thats a really bad term but I 
can't think of a better one at the moment) is that sometimes you want to say 
something like log to these new targets as well as the ones that you inherit 
from your parent Logger.

LogKit supports this via

final LogTarget[] inheritedTargets = logger.getLogTargets();
final LogTarget[] targets = new LogTarget[ inheritedTargets.length + 1 ];

System.arraycopy( targets, ... inheritedTargets );
targets[ 0 ] = myNewTarget;
logger.setLogTargets( targets );

It was so convoluted to allow extensibility while still keeping performance 
(and minimal synchronization required). We could transform it to the 
following which is simpler but can cause a slight performance impact 

final LogTarget[] targets = new LogTarget[] { myNewTarget };
logger.setLogTargets( targets, true );

We could also reimplement other setLogTargets() via something like

void setLogTargets( LogTarget[] targets )
{
  setLogTargets( targets, false );
}

It *seems* like a good idea but I want to let it simmer for a bit to think it 
through (and make sure we don't have any other similar holes).

> > Thoughts?
> >
> > BTW I just noticed that Log4j added a MDC recently (6 hours ago) which is
>
> MDC?  What's that?

Mapped Diagnostic Context (ie ContextMap) to compliment NDC or Nested 
Diagnostic Context (ie ContextStack). I am interested to see how exactly it 
was implemented ... I am going to have to download and check it out when I 
get some spare time (like that ever happens ;]).

> > essentially our ContextMap. Also their PatternFormatter was reworked in a
> > manner similar to ours. I wonder if we will be accused of stealing this
> > time... Ahh the joy of it all.
>
> You mean your innocent this time? ;)

Me innocent? I don't think so. I must have looked into the future and stole 
his ideas that way, I am a magic code monkey !! ;)

> > On Mon,  6 Aug 2001 16:42, Peter Donald wrote:
> > > Hi,
> > >
> > > Heres some feedback got so far about logkit release.
> > >
> > > * Changelog should be below files listing on download page and should
> > > also include data like how to verify signatures
> > > * Release should say "why" you should upgrade
>
> +1

+1

> > > * LogTarget is a stupid name for what it does (no alternative offered)
>
> Gee that helps.

That was mild to some of the ire I get from some of the other zealots. Did I 
ever tell you how I was betraying Apache? That was fun ;)

>
> > > * filters should be in org.apache.log.output.filter or similar (they
> > > are only used by output targets)
>
> -0

-1

Nice in theory but I like backwards compatability. *maybe* if we decide to 
make major changes between beta->stable but I am reluctent to do it at this 
stage (and probably still reluctent then).

> > > * OutputStreamLogger should be named LoggerOutputStream
>
> That makes sense +1

okay will keep "class OutputStreamLogger extends LoggerOutputStream {}" 
around for a bit though.

> > > * documentation sucks (whitepaper does not list every output target or
> > > explain concepts well enough, javadocs missing overview docs for
> > > packages and classes)
>
> Can people be nicer?  It does need the finishing touch.

Its a lot better than it was ! ;)

I could probably do a nicer summary but that will have to wait till stable 
release and time permits.

> > > * Why use testlet when there is junit
>
> We do need to remove the reference to Testlet in the release docs.

Yup. Should we also remove it from webpage references or should we leave it 
as is? I reckon we leave it in for a bit and eventually remove 
links/discussion of it so that it is only linked from historic section?

> > > * why so big download (answer == tools/ext)
>
> Do we want to include all that?  Maybe for the Source, but not for
> the binaries.

It is only in the source downloads and I am not sure we can remove it if we 
need docs built so ... lets ignore this unless more people complain. 

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               |
*-----------------------------------------------------*

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

Reply via email to