MDC, NDC (was: Re: Restarting development)

[Christian Grobmeier <gr...@gmail.com>]

On 30 Nov 2013, at 20:50, Ivan Habunek wrote:

> We actually have MDC and NDC.
> https://github.com/apache/logging-log4php/blob/master/src/main/php/LoggerMDC.php
> https://github.com/apache/logging-log4php/blob/master/src/main/php/LoggerNDC.php
>
> I think it's not documented well (or maybe at all). They're supported
> in the Pattern Layout:
> http://logging.apache.org/log4php/docs/layouts/pattern.html

Thanks. I know remember that I put some work in these classes before 
ages.

In this case I am caring about the docs.

However I never found much sense in the NDC. Any objections to remove 
NDC?

Cheers

>
> Ivan
>
> On 30 November 2013 20:43, Christian Grobmeier <gr...@gmail.com> 
> wrote:
>> Hi folks,
>>
>> I would like to step in again too. One of my main interests is to 
>> implement
>> a mapped diagnostic context.
>> In log4j1 it is known as MDC, in log4j2 it is the thread context:
>> http://logging.apache.org/log4j/2.x/manual/thread-context.html
>>
>> I really see benefits in having such a feature in log4php as well. 
>> not sure
>> how to start with, but I would love
>> to see it in 3.0.
>>
>> Cheers
>>
>>
>> On 26 Nov 2013, at 11:27, Ivan Habunek wrote:
>>
>>> OK. Step no. 1 is something only I can do. And for that I need to 
>>> push
>>> the new web site + sphinx-doc generated documentation. And do a
>>> release of the current state at the same time. I have ~80% of work
>>> done (see "docs" branch), and i have a working prototype of the new
>>> web site which I have not yet committed anywhere.
>>>
>>> Now I just need to find time to do this...
>>>
>>> Regards,
>>> Ivan
>>>
>>> On 26 November 2013 10:33, Sven Rautenberg <sv...@rtbg.de> wrote:
>>>>
>>>> Change is inevitable. :)
>>>>
>>>> I agree a quick 3.0 might not add very much value, but on the other 
>>>> hand
>>>> discussing the internal naming and renaming of classes also does 
>>>> not add
>>>> external value.
>>>>
>>>> One could change to PSR-0, but would this actually change the 
>>>> public
>>>> interface? Or is this something considered internal refactoring?
>>>>
>>>> Anyway, I'd like to have tagged experimental versions as soon as 
>>>> possible
>>>> for my own integration of Log4php. ;)
>>>>
>>>>
>>>>
>>>>
>>>> Ivan Habunek <iv...@gmail.com> schrieb:
>>>>>
>>>>>
>>>>> Hi Sven, nice to have you aboard.
>>>>>
>>>>> I don't thing it's a good idea to release a final 3.0 version 
>>>>> which
>>>>> will change a lot in future versions. And if we just tack on
>>>>> namespaces to current class naming scheme, that would need to be
>>>>> changed in the future. I think it's worth putting in a little more
>>>>> effort into a 3.0 release. At the very least, we should fix class
>>>>> naming so it's e.g. Apache\Log4php\Layouts\PatternLayout instead 
>>>>> of
>>>>> LoggerLayoutPattern.
>>>>>
>>>>> If we do go down the quick & dirty path (which is tempting, since 
>>>>> it's
>>>>> progress and is within reach), then I would much prefer to call 
>>>>> the
>>>>> result 3.0 alpha 1, and have more iterations before releasing the
>>>>> final product. We don't need to rush, but we need to break this 
>>>>> down
>>>>> to small steps otherwise we'll get stuck again.
>>>>>
>>>>> Concerning the 2.x branch, I'd like to keep it active parallel 
>>>>> with
>>>>> 3.x. We'd can just copy the current master & develop branches to
>>>>> master-2.x and develop-2.x (or something similar, don't know if
>>>>> there's a standard naming scheme for this). This way we can later
>>>>> release new versions of 2.x if needed.
>>>>>
>>>>> PSR-2, as you said, is not a problem.
>>>>>
>>>>> BTW, If my life goes according to plan (which it never does), I 
>>>>> might
>>>>> have more time to work on log4php sometime early next year. Until 
>>>>> then
>>>>> I'll try to invest time into managing the project, and start the 
>>>>> work
>>>>> towards 3.0 with your and others' help.
>>>>>
>>>>> Regards,
>>>>> Ivan
>>>>>
>>>>> On 26 November 2013 09:28, Sven Rautenberg <sv...@rtbg.de> wrote:
>>>>>>
>>>>>>
>>>>>> Sorry to step right into your discussion.
>>>>>>
>>>>>> I'd propose this:
>>>>>>
>>>>>> 1. Merge the current three branches somehow into a "current" 
>>>>>> version
>>>>>> and
>>>>>> release the accumulated fixes as 2.3.1 or 2.4.0 depending on the
>>>>>> changes.
>>>>>>
>>>>>> 2. Then decide to move on to 3.0 and apply PSR-2 coding style. 
>>>>>> There is
>>>>>> a
>>>>>> style fixer available from Fabienne Potencier - a one time 
>>>>>> call&commit
>>>>>> effort.
>>>>>>
>>>>>> 3. Only then I'd go and just add a genuine namespace to all 
>>>>>> classes
>>>>>> without
>>>>>> any other change.
>>>>>>
>>>>>> 4. Now add PSR-3 logger. Probably change the internal levels, 
>>>>>> too.
>>>>>>
>>>>>> 5. Release 3.0. ;)
>>>>>>
>>>>>> 6. Only now think about features helping with PSR-3.
>>>>>>
>>>>>> This shouldn't take very much time. I'd try to help where I can, 
>>>>>> but
>>>>>> point 1
>>>>>> is keeping me from having done the rest as a pull request 
>>>>>> already.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Ivan Habunek <iv...@gmail.com> schrieb:
>>>>>>
>>>>>>> Hi everyone, it's been a while...
>>>>>>>
>>>>>>> Dmitriy Ulyanov contacted me and said he's interested in 
>>>>>>> continuing
>>>>>>> work on log4php. I'd like to continue the discussion here on the
>>>>>>> mailing list.
>>>>>>>
>>>>>>> So, Dmitriy, what approach did you have in mind? For starters, 
>>>>>>> did you
>>>>>>> plan on working on 3.0 release (a rewrite which would feature
>>>>>>> namespaces and PSR-3 support), or do you prefer working further 
>>>>>>> on
>>>>>>> 2.3?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Ivan
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Sven Rautenberg
>>>>
>>>>
>>>>
>>>> Mit freundlichen Grüßen
>>>>
>>>> Sven Rautenberg
>>
>>
>>
>> ---
>> http://www.grobmeier.de
>> @grobmeier
>> GPG: 0xA5CC90DB


---
http://www.grobmeier.de
@grobmeier
GPG: 0xA5CC90DB

Re: MDC, NDC (was: Re: Restarting development)

[Christian Grobmeier <gr...@gmail.com>]

On 1 Dec 2013, at 17:25, Ivan Habunek wrote:

> Cool. Be sure to work on the docs branch, docs folder. The Sphinx
> docs. Not the old xdoc web site. Keep in mind those docs are for
> 2.3.1, not 3.0.
>
> I will merge it into v3 branch after releasing 2.3.1. to prevent
> duplicate effort.
>
> Is that ok for you?

Yes, thanks a lot!

>
> Regards,
> Ivan
>
> On 1 December 2013 17:20, Christian Grobmeier <gr...@gmail.com> 
> wrote:
>> On 1 Dec 2013, at 11:37, Ivan Habunek wrote:
>>
>>> On 1 December 2013 11:23, Christian Grobmeier <gr...@gmail.com> 
>>> wrote:
>>>>
>>>> In Log4j2 we have not kept it because we lack of such a scenario. 
>>>> In
>>>> addition people
>>>> seem to be confused over NDC. Curious about your ideas here (also 
>>>> useful
>>>> for
>>>> docs, in case we keep it).
>>>
>>>
>>> Consider a scenario where you have a layered application. Imagine 
>>> your
>>> request has to go through a series of layers (like a protocol stack,
>>> for example). You can make each layer add an entry to the NDC. Then
>>> when something is logged, you could know exactly where you are in 
>>> the
>>> stack, and what the components in the stack are. When leaving a 
>>> layer,
>>> you just pop() the entry you added on arrival.
>>
>>
>> Basically you could do that with MDC as well (pushing an object 
>> instead of a
>> primitive value).
>> But I see your point. Let's leave it in for now, I am going to work 
>> through
>> some docs.
>>
>>
>> Cheers
>>
>>>
>>> Ivan
>>
>>
>>
>> ---
>> http://www.grobmeier.de
>> @grobmeier
>> GPG: 0xA5CC90DB


---
http://www.grobmeier.de
@grobmeier
GPG: 0xA5CC90DB

Re: MDC, NDC (was: Re: Restarting development)

[Ivan Habunek <iv...@gmail.com>]

Cool. Be sure to work on the docs branch, docs folder. The Sphinx
docs. Not the old xdoc web site. Keep in mind those docs are for
2.3.1, not 3.0.

I will merge it into v3 branch after releasing 2.3.1. to prevent
duplicate effort.

Is that ok for you?

Regards,
Ivan

On 1 December 2013 17:20, Christian Grobmeier <gr...@gmail.com> wrote:
> On 1 Dec 2013, at 11:37, Ivan Habunek wrote:
>
>> On 1 December 2013 11:23, Christian Grobmeier <gr...@gmail.com> wrote:
>>>
>>> In Log4j2 we have not kept it because we lack of such a scenario. In
>>> addition people
>>> seem to be confused over NDC. Curious about your ideas here (also useful
>>> for
>>> docs, in case we keep it).
>>
>>
>> Consider a scenario where you have a layered application. Imagine your
>> request has to go through a series of layers (like a protocol stack,
>> for example). You can make each layer add an entry to the NDC. Then
>> when something is logged, you could know exactly where you are in the
>> stack, and what the components in the stack are. When leaving a layer,
>> you just pop() the entry you added on arrival.
>
>
> Basically you could do that with MDC as well (pushing an object instead of a
> primitive value).
> But I see your point. Let's leave it in for now, I am going to work through
> some docs.
>
>
> Cheers
>
>>
>> Ivan
>
>
>
> ---
> http://www.grobmeier.de
> @grobmeier
> GPG: 0xA5CC90DB

Re: MDC, NDC (was: Re: Restarting development)

[Christian Grobmeier <gr...@gmail.com>]

On 1 Dec 2013, at 11:37, Ivan Habunek wrote:

> On 1 December 2013 11:23, Christian Grobmeier <gr...@gmail.com> 
> wrote:
>> In Log4j2 we have not kept it because we lack of such a scenario. In
>> addition people
>> seem to be confused over NDC. Curious about your ideas here (also 
>> useful for
>> docs, in case we keep it).
>
> Consider a scenario where you have a layered application. Imagine your
> request has to go through a series of layers (like a protocol stack,
> for example). You can make each layer add an entry to the NDC. Then
> when something is logged, you could know exactly where you are in the
> stack, and what the components in the stack are. When leaving a layer,
> you just pop() the entry you added on arrival.

Basically you could do that with MDC as well (pushing an object instead 
of a primitive value).
But I see your point. Let's leave it in for now, I am going to work 
through some docs.

Cheers

>
> Ivan


---
http://www.grobmeier.de
@grobmeier
GPG: 0xA5CC90DB

Re: MDC, NDC (was: Re: Restarting development)

[Ivan Habunek <iv...@gmail.com>]

On 1 December 2013 11:23, Christian Grobmeier <gr...@gmail.com> wrote:
> In Log4j2 we have not kept it because we lack of such a scenario. In
> addition people
> seem to be confused over NDC. Curious about your ideas here (also useful for
> docs, in case we keep it).

Consider a scenario where you have a layered application. Imagine your
request has to go through a series of layers (like a protocol stack,
for example). You can make each layer add an entry to the NDC. Then
when something is logged, you could know exactly where you are in the
stack, and what the components in the stack are. When leaving a layer,
you just pop() the entry you added on arrival.

Ivan

Re: MDC, NDC (was: Re: Restarting development)

[Christian Grobmeier <gr...@gmail.com>]

On 1 Dec 2013, at 9:42, Ivan Habunek wrote:

> On 30 November 2013 21:23, Christian Grobmeier <gr...@gmail.com> 
> wrote:
>>> We actually have MDC and NDC.
>>>
>> Thanks. I know remember that I put some work in these classes before 
>> ages.
>>
>> In this case I am caring about the docs.
>>
>> However I never found much sense in the NDC. Any objections to remove 
>> NDC?
>
> I never used it, but I can foresee a scenario where it would be
> useful.

In Log4j2 we have not kept it because we lack of such a scenario. In 
addition people
seem to be confused over NDC. Curious about your ideas here (also useful 
for docs, in case we keep it).

> It doesn't present much in the way of maintenance so I think
> we should keep it.

On the other hand it's always a bit risky to have code in the base which 
is either not used
or really cared about

Cheers

>
> Ivan


---
http://www.grobmeier.de
@grobmeier
GPG: 0xA5CC90DB

Re: MDC, NDC (was: Re: Restarting development)

[Ivan Habunek <iv...@gmail.com>]

On 30 November 2013 21:23, Christian Grobmeier <gr...@gmail.com> wrote:
>> We actually have MDC and NDC.
>>
> Thanks. I know remember that I put some work in these classes before ages.
>
> In this case I am caring about the docs.
>
> However I never found much sense in the NDC. Any objections to remove NDC?

I never used it, but I can foresee a scenario where it would be
useful. It doesn't present much in the way of maintenance so I think
we should keep it.

Ivan