The current config syntax is one of the big reasons why I want to use
log4j2 in production ASAP. I hate the old log4j configuration format, and
there's no way I'm going to use logback or JUL.
The builder stuff isn't a blocker for 2.0 as it's not really API related.
On 3 June 2014 01:38, Ralph Goers <rgo...@apache.org> wrote:
> 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
>>> <http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> 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
>> <http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> 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
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
>
--
Matt Sicker <boa...@gmail.com>
