1. I liked AbstractLogger better, too.
2. Let's do that single transferable vote thing over the ML instead of
STEVE.
3. I was saying that log4j2's configuration file formats are far superior
to any others I've seen out there.
4. If there's any way to improve the config file format, it might be in the
JSON/YAML versions, but I haven't really looked at those closely at all.
But an example might be that I'd like to use something like:
"appenders": [
"console": { ... attributes ... },
... other appenders
]
And not something like
"appenders": [
"appender": {
... attributes
},
"appender": {
... more attributes
}
]
Basically, make it natural like the XML config is.
On 3 June 2014 03:29, Remko Popma <remko.po...@gmail.com> wrote:
> 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
>>> <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>
