Re: [Proposal] Use UGLI as logging abstraction (Re: [RT] Logging in 2.2)

[Nicola Ken Barozzi <ni...@apache.org>]

Torsten Curdt wrote:
>> If you prefer commons logging over it, please write a technical 
>> motivation about it.
> 
> As I already said: I don't see the point of this parameter stuff.

Then don't use the parameter stuff.

> IMO this only leads to mixing of concepts. 

What concepts? Remember that python and Java 1.5 have this capability, 
because it's useful... are they both so wrong?

> Some people will
> use the "{}" some won't. To be honest I would not feel very happy
> with UGLI since IMHO this interface is only half-backed. Sorry.

Half baked because it has "the parameter stuff"?

Remember that log4j uses that interface. Is log4j also half-baked?

> ...and I don't see point of getting rid of the Avalon Logger
> dependency and introducing the UGLI dependency instead. Only
> because we want to get rid of Avalon?

Yes.

> Is there any technical reason to switch from the Avalon Logger
> abstraction?

No.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------

Re: [Proposal] Use UGLI as logging abstraction (Re: [RT] Logging in 2.2)

[Gianugo Rabellino <gi...@gmail.com>]

On Fri, 07 Jan 2005 12:26:12 +0100, Torsten Curdt <tc...@apache.org> wrote:
> >> IMO this only leads to mixing of concepts.
> >
> >
> > What concepts? Remember that python and Java 1.5 have this capability,
> > because it's useful... are they both so wrong?
> 
> No ...it *is* useful!! ...a variable amount
> of parameters!

Bah, I don't like varargs that much, it's just syntax sugar adding
opacity in exchange for a few keystrokes. The compiler is changing
varargs into arrays, and the receiving method needs to be written
against an array anyway, so why bother?

> >> Some people will
> >> use the "{}" some won't. To be honest I would not feel very happy
> >> with UGLI since IMHO this interface is only half-backed. Sorry.
> >
> >
> > Half baked because it has "the parameter stuff"?
> 
> Either make it use the 1.5 stuff (and make
> 1.5 a requirement) or leave it out ...but
> this mixture is what I call half baked.
> 
> > Remember that log4j uses that interface. Is log4j also half-baked?

Not quite, but still this shaky interface adds up to the list of Log4J
poorly engineered stuff that makes me wish for an interface to isolate
myself from it (even though I do reckon that we have to suppport it
given how pervasive it has become). UGLI looks like the less worst
alternative, so I can digest it. But getting to like that... well,
that's entirely another issue.

Ciao,
-- 
Gianugo Rabellino
Pro-netics s.r.l. -  http://www.pro-netics.com
Orixo, the XML business alliance: http://www.orixo.com

Re: [Proposal] Use UGLI as logging abstraction (Re: [RT] Logging in 2.2)

[Vadim Gritsenko <va...@reverycodes.com>]

Carsten Ziegeler wrote:
> 
> So let's drop this topic and finish the virtual sitemap components. 
> Someone?

There is some code in 2.2, in VirtualPipelineGenerator, complete with a running 
sample and list of TODOs. Anybody can continue the started work - but I'd 
personally concentrate on 2.1.7 (and failing tests, and bugs) first.

Vadim

Re: [Proposal] Use UGLI as logging abstraction (Re: [RT] Logging in 2.2)

[Carsten Ziegeler <cz...@apache.org>]

Stefano Mazzocchi wrote:

> 
> Carsten, too early. Now that avalon is closed, nobody is going to modify 
> those classes in a non-compatible way.
That's true.

> 
> There is *less* to worry about now than in the past.
 >
 >
 > Let's try to act rationally people, if ain't broken, don't try to fix it.
 >
I'm not worrying about avalon (or excalibur) and their future. Once we 
had the agreement to move away from marker interfaces to POJOs - one 
remaining piece for this is in fact logging. But it's true that we don't 
have to do it today, we have time. Personally I like to introduce an 
alternative very early in time and have a long migration phase. But I 
have no problem with leaving things as they are.
So let's drop this topic and finish the virtual sitemap components. Someone?

Carsten

Re: [Proposal] Use UGLI as logging abstraction (Re: [RT] Logging in 2.2)

[Stefano Mazzocchi <st...@apache.org>]

Carsten Ziegeler wrote:
> Torsten Curdt wrote:
> 
>>>> Is there any technical reason to switch from the Avalon Logger
>>>> abstraction?
>>>
>>>
>>>
>>> No.
>>
>>
>>
>> Well ...then that's no good reason to me.
>>
>> Rather I would also import the few classes
>> into out repository (like we did with ECM)
>> than doing the switch.
>>
> We can't import the classes in this case as these are interfaces. For 
> ECM we could provide our own implementation, but - for now - we are 
> still using the interfaces of the avalon framework. We agreed to move 
> away someday from these interfaces - and part of this logging discussion 
> is exactly about this: moving away from the avalon interfaces.

Carsten, too early. Now that avalon is closed, nobody is going to modify 
those classes in a non-compatible way.

There is *less* to worry about now than in the past.

Let's try to act rationally people, if ain't broken, don't try to fix it.

-- 
Stefano.

Re: [Proposal] Use UGLI as logging abstraction (Re: [RT] Logging in 2.2)

[Ralph Goers <Ra...@dslextreme.com>]

Carsten Ziegeler wrote:

> Hmm, we have discussed this topic very lengthy and to summarize
> it, we don't want to have dependencies for the core which
> translates to: we don't want the core to depend on avalon.
> On the technical side this means: moving from marker interfaces to POJOs.
>
> With ECM++ ..eh..our own container, we are free to do what we want and 
> we can provide a smooth migration path.

Ok, so copy the interfaces from Avalon and name then o.a.c.whatever.

Ralph

Re: [Proposal] Use UGLI as logging abstraction (Re: [RT] Logging in 2.2)

[Carsten Ziegeler <cz...@apache.org>]

Torsten Curdt wrote:

> 
> They would no longer be the "avalon interfaces"
> ..or is the ECM++ still avalon?
> 
> What was the reason again to move exchange the
> abstraction layer? ...not talking about the
> implementation.
> 
> Sorry, guys this discussion getting a bit absurd to me.

Hmm, we have discussed this topic very lengthy and to summarize
it, we don't want to have dependencies for the core which
translates to: we don't want the core to depend on avalon.
On the technical side this means: moving from marker interfaces to POJOs.

With ECM++ ..eh..our own container, we are free to do what we want and 
we can provide a smooth migration path.

Carsten

Re: [Proposal] Use UGLI as logging abstraction (Re: [RT] Logging in 2.2)

[Torsten Curdt <tc...@apache.org>]

>>>> Is there any technical reason to switch from the Avalon Logger
>>>> abstraction?
>>>
>>> No.
>>
>> Well ...then that's no good reason to me.
>>
>> Rather I would also import the few classes
>> into out repository (like we did with ECM)
>> than doing the switch.
>>
> We can't import the classes in this case as these are interfaces. For 
 > ECM we could provide our own implementation, but - for now - we are
 > still using the interfaces of the avalon framework.

...well interfaces then - whatever.

> We agreed to move 
> away someday from these interfaces - and part of this logging discussion 
> is exactly about this: moving away from the avalon interfaces.

They would no longer be the "avalon interfaces"
..or is the ECM++ still avalon?

What was the reason again to move exchange the
abstraction layer? ...not talking about the
implementation.

Sorry, guys this discussion getting a bit absurd to me.
--
Torsten

Re: [Proposal] Use UGLI as logging abstraction (Re: [RT] Logging in 2.2)

[Carsten Ziegeler <cz...@apache.org>]

Torsten Curdt wrote:
>>> Is there any technical reason to switch from the Avalon Logger
>>> abstraction?
>>
>>
>> No.
> 
> 
> Well ...then that's no good reason to me.
> 
> Rather I would also import the few classes
> into out repository (like we did with ECM)
> than doing the switch.
> 
We can't import the classes in this case as these are interfaces. For 
ECM we could provide our own implementation, but - for now - we are 
still using the interfaces of the avalon framework. We agreed to move 
away someday from these interfaces - and part of this logging discussion 
is exactly about this: moving away from the avalon interfaces.

Carsten

Re: [Proposal] Use UGLI as logging abstraction (Re: [RT] Logging in 2.2)

[Torsten Curdt <tc...@apache.org>]

>> IMO this only leads to mixing of concepts. 
> 
> 
> What concepts? Remember that python and Java 1.5 have this capability, 
> because it's useful... are they both so wrong?

No ...it *is* useful!! ...a variable amount
of parameters!

>> Some people will
>> use the "{}" some won't. To be honest I would not feel very happy
>> with UGLI since IMHO this interface is only half-backed. Sorry.
> 
> 
> Half baked because it has "the parameter stuff"?

Either make it use the 1.5 stuff (and make
1.5 a requirement) or leave it out ...but
this mixture is what I call half baked.

> Remember that log4j uses that interface. Is log4j also half-baked?

Also with the parameters? ...wasn't aware
of that ...but my opinion would still apply.

>> ...and I don't see point of getting rid of the Avalon Logger
>> dependency and introducing the UGLI dependency instead. Only
>> because we want to get rid of Avalon?
> 
> Yes.
> 
>> Is there any technical reason to switch from the Avalon Logger
>> abstraction?
> 
> No.

Well ...then that's no good reason to me.

Rather I would also import the few classes
into out repository (like we did with ECM)
than doing the switch.

cheers
--
Torsten

Re: [Proposal] Use UGLI as logging abstraction (Re: [RT] Logging in 2.2)

[Stefano Mazzocchi <st...@apache.org>]

Nicola Ken Barozzi wrote:
> Torsten Curdt wrote:
> 
>>> If you prefer commons logging over it, please write a technical 
>>> motivation about it.
>>
>>
>> As I already said: I don't see the point of this parameter stuff.
> 
> 
> Then don't use the parameter stuff.
> 
>> IMO this only leads to mixing of concepts. 
> 
> 
> What concepts? Remember that python and Java 1.5 have this capability, 
> because it's useful... are they both so wrong?
> 
>> Some people will
>> use the "{}" some won't. To be honest I would not feel very happy
>> with UGLI since IMHO this interface is only half-backed. Sorry.
> 
> 
> Half baked because it has "the parameter stuff"?
> 
> Remember that log4j uses that interface. Is log4j also half-baked?
> 
>> ...and I don't see point of getting rid of the Avalon Logger
>> dependency and introducing the UGLI dependency instead. Only
>> because we want to get rid of Avalon?
> 
> 
> Yes.
> 
>> Is there any technical reason to switch from the Avalon Logger
>> abstraction?
> 
> 
> No.

People, enough bike shedding already.

Nicola, UGLI is a nice attempt and an improvement over existing stuff, 
but Torsten is right: without Java 1.5/python/C unlimited parameter 
passing style, it's clearly a hack.

Carsten understimated the amount of establishment (rational or 
irrational) on top of the existing logging environments.

I say we move on to move important things.

-- 
Stefano.