Perhaps we should put a message on the site "we're unable to select a new logo,
so log4j-2.0 will not be G.A. for the foreseeable future". :-P
(Just kidding.)
About LoggerProvider, I liked having the extra methods to be able to
extend/wrap Loggers, but I also don't like the name very much.
I hesitate to propose this as I agree with Ralph's main point that I think our
time would be better spent fixing outstanding Jiras than renaming and
refactoring stuff that already works fine, but here goes:
How about:
1. LoggerProvider -> ExtendedLogger,
AbstractLoggerProvider -> AbstractExtendedLogger
2. Move all methods from LoggerProvider into Logger and remove LoggerProvider,
AbstractLoggerProvider -> AbstractLogger
Sent from my iPhone
> On 2014/06/03, at 16:12, Gary Gregory <garydgreg...@gmail.com> wrote:
>
> Well, let's talk about it! I find some of these typs names confusing and the
> javadocs could be better. Better names will help us. Names are important to
> communicate clearly what our _intentions_ are.
>
> Gary
>
>
> -------- Original message --------
> From: Ralph Goers
> Date:06/03/2014 02:38 (GMT-05:00)
> To: Log4J Developers List
> Subject: Re: Config clean up for AppenderRef
>
> We are never going to release 2.0. A few of you keep wanting to continually
> refactor and rename stuff is making things worse in my opinion. As I have
> said before, a good example is that I find AbstractLogger to be a much better
> name than AbstractLoggerProvider and think it was a mistake to rename it, but
> I didn't speak up fast enough when it happened. We have over 100 Jira issues
> that I would think would be far more productive to address then these silly
> refactoring and renaming excercises.
>
> Just leave the configuration syntax alone.
>
> Sent from my iPad
>
>> On Jun 2, 2014, at 10:48 PM, Gary Gregory <garydgreg...@gmail.com> wrote:
>>
>>> On Mon, Jun 2, 2014 at 11:54 PM, Remko Popma <remko.po...@gmail.com> wrote:
>>> I wish everyone on the team would think of these things more in terms of
>>> trade-offs.
>>> What is the cost/benefit analysis of this change?
>>>
>>> Plus: one or two people on the team like this name better from an
>>> aesthetical point of view (I don't see any functional benefit). That gets
>>> some points, but not as many as a functional improvement would get.
>>>
>>> Minus: it breaks the configuration of existing users. That's a lot of minus
>>> points to me.
>>>
>>> Times the number of affected people (both plus and minus)...
>>>
>>> And why are we even talking about this?
>>
>> Because I am a volunteer and I care about some things more than others, if
>> other folks don't, that's fine too.
>>
>> Look at this as a trade-off of working in a FOSS environment ;-)
>>
>> Also, for a new major version, everything matters. This is really more like
>> a version 1.0 of the reboot of a classic franchise. IMO, everything deserves
>> special care as we'll have to live with it for a long time.
>>
>> This is why I've not been pushing for a release. I'd like to know as much of
>> the code as possible. Check out all the nooks and crannies.
>>
>> I have great respect for the work Ralph has put in, it is a tremendous
>> effort of high quality. But, it does not mean that it cannot benefit from
>> reviews, spit, and polish.
>>
>> I think the community has grown and sees people come and go (where is Nick
>> Williams BTW ;-) It is nice that we can benefit from various talents in
>> different areas. We should take advantage of it all.
>>
>> I like the enthusiasm and work that Matt has recently put in for example.
>> We've got a lot of talented people, let's take advantage of these volunteers
>> and let them all flourish.
>>
>> Sure we might end up with more features, bells and whistles than are
>> strictly needed, but hopefully and so far, the software is that much the
>> better for it. And yes, we should all keep a diligent eye toward speed and
>> memory, and all the usual good that comes from peer reviews.
>>
>> Cheers,
>> Gary
>>
>>>
>>> Sent from my iPhone
>>>
>>>> On 2014/06/03, at 10:28, Gary Gregory <garydgreg...@gmail.com> wrote:
>>>>
>>>> Hm, why not adopt the same convention as Ant? It would be nicer IMO:
>>>>
>>>> <File id="MyAppender />
>>>> <AppenderRef refid="MyAppender />
>>>>
>>>> Both attributes have "id" in their name so the connection is more obvious.
>>>>
>>>> Gary
>>>>
>>>>
>>>>> On Mon, Jun 2, 2014 at 5:24 AM, Ralph Goers <rgo...@apache.org> wrote:
>>>>> I think I agree with Remko. I think ref= is clearer.
>>>>>
>>>>> Sent from my iPad
>>>>>
>>>>>> On Jun 2, 2014, at 1:48 AM, Remko Popma <remko.po...@gmail.com> wrote:
>>>>>>
>>>>>> Hm, not sure. Two things:
>>>>>>
>>>>>> That would require our existing users to modify their configurations.
>>>>>>
>>>>>> Also, currently the "name" attribute provides an identifier for its
>>>>>> element so that other elements can reference it. Isn't it clearer to
>>>>>> have a different attribute when referring to another element? I think
>>>>>> calling this attribute "ref" is very clear actually and I don't think
>>>>>> having the same name for attributes that refer and attributes attributes
>>>>>> that are being referred to is better.
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>>> On 2014/06/02, at 15:46, Gary Gregory <garydgreg...@gmail.com> wrote:
>>>>>>>
>>>>>>> In the following:
>>>>>>>
>>>>>>> <File name="File" fileName="${filename}">
>>>>>>> <PatternLayout>
>>>>>>> <Pattern>${pattern}</Pattern>
>>>>>>> </PatternLayout>
>>>>>>> </File>
>>>>>>> ...
>>>>>>> <Loggers>
>>>>>>> <Root level="Debug">
>>>>>>> <AppenderRef ref="File" />
>>>>>>> </Root>
>>>>>>> </Loggers>
>>>>>>>
>>>>>>> I propose to change:
>>>>>>>
>>>>>>> <AppenderRef ref="File" />
>>>>>>>
>>>>>>> to:
>>>>>>>
>>>>>>> <AppenderRef name="File" />
>>>>>>>
>>>>>>> It seems easier to read and connect these dots:
>>>>>>>
>>>>>>> <File name="File"
>>>>>>> ...
>>>>>>> <AppenderRef name="File" />
>>>>>>>
>>>>>>> Thoughts?
>>>>>>>
>>>>>>> Gary
>>>>>>>
>>>>>>> --
>>>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>> JUnit in Action, Second Edition
>>>>>>> Spring Batch in Action
>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>> Home: http://garygregory.com/
>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>
>>>>
>>>>
>>>> --
>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>>>> Java Persistence with Hibernate, Second Edition
>>>> JUnit in Action, Second Edition
>>>> Spring Batch in Action
>>>> Blog: http://garygregory.wordpress.com
>>>> Home: http://garygregory.com/
>>>> Tweet! http://twitter.com/GaryGregory
>>
>>
>>
>> --
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> Java Persistence with Hibernate, Second Edition
>> JUnit in Action, Second Edition
>> Spring Batch in Action
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
