You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Gary Gregory <ga...@gmail.com> on 2015/08/14 23:34:29 UTC
Version 2 outreach?
Something to think about after we get 2.4 out the door...
Do you think it appropriate for us to do some kind of outreach to other
Apache projects and say "hey, about about use log4j 2?"
Gary
--
E-Mail: garydgregory@gmail.com | ggregory@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
Re: Version 2 outreach?
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, Aug 14, 2015 at 5:27 PM, Ralph Goers <ra...@dslextreme.com>
wrote:
> Gary,
>
> Do you have something in mind? While not hard, it is a fair amount of
> work for an application to switch to a different logging API. Granted, it
> is mostly just changing the call to get a Logger. But most applications
> should also take advantage of the new parameter syntax as well.
>
I was thinking of something low key at first, especially if some of us know
other committers on these projects: "Hi John, you might have seen that
we've announced that log4j1 is EOL. Let us know if you'd like help or
advice on porting to version 2. We understand that you might not be able to
do so now or for a while, if at all. We have a porting FAQ here http://...
and we'd appreciate any feedback and we provide support on our ML of
course. If there are blockers for version 2 adoption, we'd like to know
about them! Thank you and so on."
>
> What was your experience with projects upgrading to commons lang3 vs
> commons lang?
>
Easy. All of the projects at work and FOSS were painless. It's a different
kind of library of course. Aside from a couple of deprecated classes that
were removed, migration was just a package name change.
> I know quite a few people are still using commons httpclient vs the new
> version, and that has been around a lot longer than Log4j 2.
>
For HttpComponents/HttpClient from 3 to 4, it's a little more tricky
because of API deprecation and other changes I can't recall ATM. It
required real work. Changes within r4 were a little easier. For the
upcoming r5, I'm not sure.
> What I really hope is that we stopped projects from switching from log4j 1
> to logback, although I am aware that many projects are using slf4j instead
> and letting their customers choose. Frankly, if I hadn’t found limitations
> (such as the ability to use Messages) in SLF4J I would have used that as
> the API for Log4j 2 (I am quite happy we didn’t).
>
The Log4j migration issues from Log4j 1 to 2 fall into two categories IMO:
Configuration and custom appenders. For me at work, our app server is still
on r1 because we decided to not put too much time into maintaining or
evolving the product and I have two newer products to work on, which I
started with Log4j 2 since day 0. Our app server tools would need to be
updated to automatically convert log4j 1 prop files to log4j 2 XML files,
not a trivial task. Our users click this and that in a GUI to configure
logging, so we have to do it all. Porting our appenders would be a week of
work or so, no big deal, but still a week not spent on other tasks.
I do see a need for a prop file porting tool but I am not sure how much of
a need that is in the whole wide world. That or have the compatibility
layer automatically understand prop files.
Gary
> Ralph
>
> On Aug 14, 2015, at 2:34 PM, Gary Gregory <ga...@gmail.com> wrote:
>
> Something to think about after we get 2.4 out the door...
>
> Do you think it appropriate for us to do some kind of outreach to other
> Apache projects and say "hey, about about use log4j 2?"
>
> Gary
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@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: garydgregory@gmail.com | ggregory@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
Re: Version 2 outreach?
Posted by Mikael Ståldal <mi...@magine.com>.
Perhaps the Zookeeper project should split out a client library module
(which should only depend on SLF4J-API).
On Mon, Aug 17, 2015 at 12:07 PM, Ralph Goers <ra...@dslextreme.com>
wrote:
> If you will note, Christian put in a plug for Log4j 2 quite some time ago
> in that Jira issue. From reading the issue it seems to me that Zookeeper
> must be using some convoluted processes in their build with all the
> problems they had getting patches to apply. Also, they ship an executable
> binary, which makes it difficult to not include a logging implementation.
> Flume also does this - which reminds me to open an issue with them.
>
> Ralph
>
> On Aug 17, 2015, at 1:40 AM, Mikael Ståldal <mi...@magine.com>
> wrote:
>
> It's OK if a library uses SLF4J properly. However, some libraries (even
> Apache ones) uses SLF4J improperly by having a mandatory dependency on a
> specific implementation (logj4 1 or logback) in their project. Such as
> Zookeeper:
>
>
> https://repo1.maven.org/maven2/org/apache/zookeeper/zookeeper/3.4.6/zookeeper-3.4.6.pom
>
> This is very unfortunately since Zookeeper is a dependency for quite a lot
> of other projects, and causes quite a lot of headache if you want to use
> Log4j 2 (you have to exclude dependencies). There is an old JIRA ticket for
> it, but it has not been prioritized:
> https://issues.apache.org/jira/browse/ZOOKEEPER-1371
>
> On Sat, Aug 15, 2015 at 2:27 AM, Ralph Goers <ra...@dslextreme.com>
> wrote:
>
>> Gary,
>>
>> Do you have something in mind? While not hard, it is a fair amount of
>> work for an application to switch to a different logging API. Granted, it
>> is mostly just changing the call to get a Logger. But most applications
>> should also take advantage of the new parameter syntax as well.
>>
>> What was your experience with projects upgrading to commons lang3 vs
>> commons lang? I know quite a few people are still using commons httpclient
>> vs the new version, and that has been around a lot longer than Log4j 2.
>> What I really hope is that we stopped projects from switching from log4j 1
>> to logback, although I am aware that many projects are using slf4j instead
>> and letting their customers choose. Frankly, if I hadn’t found limitations
>> (such as the ability to use Messages) in SLF4J I would have used that as
>> the API for Log4j 2 (I am quite happy we didn’t).
>>
>> Ralph
>>
>> On Aug 14, 2015, at 2:34 PM, Gary Gregory <ga...@gmail.com> wrote:
>>
>> Something to think about after we get 2.4 out the door...
>>
>> Do you think it appropriate for us to do some kind of outreach to other
>> Apache projects and say "hey, about about use log4j 2?"
>>
>> Gary
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@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
>>
>>
>>
>
>
> --
> [image: MagineTV]
>
> *Mikael Ståldal*
> Senior backend developer
>
> *Magine TV*
> mikael.staldal@magine.com
> Regeringsgatan 25 | 111 53 Stockholm, Sweden | www.magine.com
>
> Privileged and/or Confidential Information may be contained in this
> message. If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not
> copy or deliver this message to anyone. In such case,
> you should destroy this message and kindly notify the sender by reply
> email.
>
>
--
[image: MagineTV]
*Mikael Ståldal*
Senior backend developer
*Magine TV*
mikael.staldal@magine.com
Regeringsgatan 25 | 111 53 Stockholm, Sweden | www.magine.com
Privileged and/or Confidential Information may be contained in this
message. If you are not the addressee indicated in this message
(or responsible for delivery of the message to such a person), you may not
copy or deliver this message to anyone. In such case,
you should destroy this message and kindly notify the sender by reply
email.
Re: Version 2 outreach?
Posted by Ralph Goers <ra...@dslextreme.com>.
If you will note, Christian put in a plug for Log4j 2 quite some time ago in that Jira issue. From reading the issue it seems to me that Zookeeper must be using some convoluted processes in their build with all the problems they had getting patches to apply. Also, they ship an executable binary, which makes it difficult to not include a logging implementation. Flume also does this - which reminds me to open an issue with them.
Ralph
> On Aug 17, 2015, at 1:40 AM, Mikael Ståldal <mi...@magine.com> wrote:
>
> It's OK if a library uses SLF4J properly. However, some libraries (even Apache ones) uses SLF4J improperly by having a mandatory dependency on a specific implementation (logj4 1 or logback) in their project. Such as Zookeeper:
>
> https://repo1.maven.org/maven2/org/apache/zookeeper/zookeeper/3.4.6/zookeeper-3.4.6.pom
>
> This is very unfortunately since Zookeeper is a dependency for quite a lot of other projects, and causes quite a lot of headache if you want to use Log4j 2 (you have to exclude dependencies). There is an old JIRA ticket for it, but it has not been prioritized: https://issues.apache.org/jira/browse/ZOOKEEPER-1371
>
>> On Sat, Aug 15, 2015 at 2:27 AM, Ralph Goers <ra...@dslextreme.com> wrote:
>> Gary,
>>
>> Do you have something in mind? While not hard, it is a fair amount of work for an application to switch to a different logging API. Granted, it is mostly just changing the call to get a Logger. But most applications should also take advantage of the new parameter syntax as well.
>>
>> What was your experience with projects upgrading to commons lang3 vs commons lang? I know quite a few people are still using commons httpclient vs the new version, and that has been around a lot longer than Log4j 2. What I really hope is that we stopped projects from switching from log4j 1 to logback, although I am aware that many projects are using slf4j instead and letting their customers choose. Frankly, if I hadn’t found limitations (such as the ability to use Messages) in SLF4J I would have used that as the API for Log4j 2 (I am quite happy we didn’t).
>>
>> Ralph
>>
>>> On Aug 14, 2015, at 2:34 PM, Gary Gregory <ga...@gmail.com> wrote:
>>>
>>> Something to think about after we get 2.4 out the door...
>>>
>>> Do you think it appropriate for us to do some kind of outreach to other Apache projects and say "hey, about about use log4j 2?"
>>>
>>> Gary
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@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
>
>
>
> --
>
>
> Mikael Ståldal
> Senior backend developer
>
> Magine TV
> mikael.staldal@magine.com
> Regeringsgatan 25 | 111 53 Stockholm, Sweden | www.magine.com
>
> Privileged and/or Confidential Information may be contained in this message. If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not copy or deliver this message to anyone. In such case,
> you should destroy this message and kindly notify the sender by reply email.
Re: Version 2 outreach?
Posted by Mikael Ståldal <mi...@magine.com>.
It's OK if a library uses SLF4J properly. However, some libraries (even
Apache ones) uses SLF4J improperly by having a mandatory dependency on a
specific implementation (logj4 1 or logback) in their project. Such as
Zookeeper:
https://repo1.maven.org/maven2/org/apache/zookeeper/zookeeper/3.4.6/zookeeper-3.4.6.pom
This is very unfortunately since Zookeeper is a dependency for quite a lot
of other projects, and causes quite a lot of headache if you want to use
Log4j 2 (you have to exclude dependencies). There is an old JIRA ticket for
it, but it has not been prioritized:
https://issues.apache.org/jira/browse/ZOOKEEPER-1371
On Sat, Aug 15, 2015 at 2:27 AM, Ralph Goers <ra...@dslextreme.com>
wrote:
> Gary,
>
> Do you have something in mind? While not hard, it is a fair amount of
> work for an application to switch to a different logging API. Granted, it
> is mostly just changing the call to get a Logger. But most applications
> should also take advantage of the new parameter syntax as well.
>
> What was your experience with projects upgrading to commons lang3 vs
> commons lang? I know quite a few people are still using commons httpclient
> vs the new version, and that has been around a lot longer than Log4j 2.
> What I really hope is that we stopped projects from switching from log4j 1
> to logback, although I am aware that many projects are using slf4j instead
> and letting their customers choose. Frankly, if I hadn’t found limitations
> (such as the ability to use Messages) in SLF4J I would have used that as
> the API for Log4j 2 (I am quite happy we didn’t).
>
> Ralph
>
> On Aug 14, 2015, at 2:34 PM, Gary Gregory <ga...@gmail.com> wrote:
>
> Something to think about after we get 2.4 out the door...
>
> Do you think it appropriate for us to do some kind of outreach to other
> Apache projects and say "hey, about about use log4j 2?"
>
> Gary
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@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
>
>
>
--
[image: MagineTV]
*Mikael Ståldal*
Senior backend developer
*Magine TV*
mikael.staldal@magine.com
Regeringsgatan 25 | 111 53 Stockholm, Sweden | www.magine.com
Privileged and/or Confidential Information may be contained in this
message. If you are not the addressee indicated in this message
(or responsible for delivery of the message to such a person), you may not
copy or deliver this message to anyone. In such case,
you should destroy this message and kindly notify the sender by reply
email.
Re: Version 2 outreach?
Posted by Ralph Goers <ra...@dslextreme.com>.
Gary,
Do you have something in mind? While not hard, it is a fair amount of work for an application to switch to a different logging API. Granted, it is mostly just changing the call to get a Logger. But most applications should also take advantage of the new parameter syntax as well.
What was your experience with projects upgrading to commons lang3 vs commons lang? I know quite a few people are still using commons httpclient vs the new version, and that has been around a lot longer than Log4j 2. What I really hope is that we stopped projects from switching from log4j 1 to logback, although I am aware that many projects are using slf4j instead and letting their customers choose. Frankly, if I hadn’t found limitations (such as the ability to use Messages) in SLF4J I would have used that as the API for Log4j 2 (I am quite happy we didn’t).
Ralph
> On Aug 14, 2015, at 2:34 PM, Gary Gregory <ga...@gmail.com> wrote:
>
> Something to think about after we get 2.4 out the door...
>
> Do you think it appropriate for us to do some kind of outreach to other Apache projects and say "hey, about about use log4j 2?"
>
> Gary
>
> --
> E-Mail: garydgregory@gmail.com <ma...@gmail.com> | ggregory@apache.org <ma...@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 <http://garygregory.wordpress.com/>
> Home: http://garygregory.com/ <http://garygregory.com/>
> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
Re: Version 2 outreach?
Posted by Xen <xe...@dds.nl>.
"I simply don’t have time to read long emails that a) don’t ask me how
to solve a specific problem, b) don’t ask for a specific feature to be
implemented, c) don’t ask me how to explain how something works or d)
don’t say “What can I do to help”."
All of what you say basically boils down to the fact that you want to
simply relax and not have to think about hard stuff. It is a hobby
project so to speak (to be assuming again) but there is no reflection in
their. No thinking about WHAT you are doing. You are doing it, but you
don't think about what it is.
b) I can't ask you for a specific feature yet because I have yet to
discover and develop what it needs to be. That's why I am spending my
time with Log4J, to improve it. If I just wanted to use it and nothing
else, well I would not have. It is too flawed for that, from my point of
view (sorry about that).
c) I'm doing that as I go along but I also need to communicate
d) I already know how I can help. You don't have to tell me.
Well, that's about it, for now again, at least.
Op 15-8-2015 om 2:27 schreef Ralph Goers:
> Bart, We spent over 2 years asking for feedback during which we had
> 13 releases prior to the GA release. We changed, many, many things.
> While you are free to criticize Log4j 2 it really doesn’t accomplish
> much unless you provide concrete detail on what should be changed and
> then expend some effort to do that.
>
> Projects in the Apache Software Foundation are run by what is
> affectionately called a “do-ocracy” - If you see something broken you
> fix it, if there is a feature you want you create it. Creating Jira
> issues and posting emails is great but in the end doesn’t accomplish
> much if no one does anything about it. Everyone who works on Apache
> projects is a volunteer. We do it because we choose to and because we
> want to, not because we have to.
>
> The bottom line is that I have a day job that takes more than 40 hours
> per week of my time. I have a family that requires my attention. I
> want to write code and solve people’s problems when I have the time to
> work on Log4j. I simply don’t have time to read long emails that a)
> don’t ask me how to solve a specific problem, b) don’t ask for a
> specific feature to be implemented, c) don’t ask me how to explain how
> something works or d) don’t say “What can I do to help”.
>
> Please don’t take responses to you as people being rude. Please take
> them as we are all busy and want to use our time effectively.
>
> Ralph
>
>> On Aug 14, 2015, at 3:02 PM, Xen <xen@dds.nl <ma...@dds.nl>> wrote:
>>
>> I just think... trying to persuade people like that is very needy.
>>
>> Ralph (Goers) doesn't give me the impression like he's needy like
>> that ;-).
>>
>> It is clear that the new version is a bit out of tune with the goals
>> these other projects might have. The requirements for a logging
>> package should be a lowest common denominator thing. If the product
>> is good, the other projects should notice anyway and take notice
>> themselves. I would focus on documentation and clarity. You're a bit
>> at odds with the times I think. Do you have the interests of your
>> users in mind, or of someone else? That's what makes it hard to give
>> a recommendation because it's just impossible. I mean "to become more
>> popular". If you feel the need to advertize or say "hey, don't forget
>> about us" so badly, that just means....
>>
>> Well anybody can figure that out for himself I guess. But I was
>> looking at a topic called Update trunk to Java 7 from last May and it
>> didn't seem like their was an urgent need to do so.
>>
>> Well it means you are on the wrong tract or not feeling confident.
>>
>> Maybe you really feel like you need a call for attention, but.... ...
>> .. . . . . .. .....
>>
>> Everybody already knows you lol. Your name is well-known. It just
>> seems like everyone is stuck using 1.2. Stuckerdiestuckstuckstuck.
>> You might want to send out for an honest appraisal or feedback.
>>
>> Ask the question of whether Log4J 2 meets their goals. Ask the
>> question of whether 2.3 meets or met their goals. Ask the question of
>> whether 2.4 meets or will meet their goals. Ask what they want from a
>> logging package. Don't forget to mention the issues: Java 7. Public
>> vs. Core -- do they like that? Are they impressed by a separation of
>> public versus implementation API? If they have experience with the
>> product, do they feel the need to use Core functionality that is not
>> normally directly accessible from Public?. Did they feel their needs
>> were respected when the move to 2 was made? Do they feel the EOL of
>> v1 has been a necessary or required or helpful thing?. What are their
>> needs and interests? How do they feel about having to use two jars? I
>> would seriously consider asking these questions, all of them.
>>
>> So don't ask for uptake, ask for feedback. I think that is the best
>> suggestion or advice I can offer. Ask them whether you are on the
>> right path. Ask this of your fellow Apache projects. Do that and you
>> will do well, or better, in the future. If such a thing as 'better'
>> would exist, but you can always do better than what you were before.
>>
>> And that's true of everyone everywhere. That's just true of life.
>>
>> Regards, B.
>>
>>
>> Op 14-8-2015 om 23:34 schreef Gary Gregory:
>>> Something to think about after we get 2.4 out the door...
>>>
>>> Do you think it appropriate for us to do some kind of outreach to
>>> other Apache projects and say "hey, about about use log4j 2?"
>>>
>>> Gary
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com <ma...@gmail.com> |
>>> ggregory@apache.org <ma...@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
>>> <http://garygregory.wordpress.com/>
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>
>
Re: Version 2 outreach?
Posted by Xen <xe...@dds.nl>.
Let's say that I'm just writing a piece of insight on it ;-). I think
writing code without thought is akin to getting married without
consciousness of who it is and where she lives ;-).
Op 16-8-2015 om 0:09 schreef Ralph Goers:
> My plan is to write some code and then ask for feedback. That seems to
> have worked well for us in the past.
>
> Sent from my iPad
>
> On Aug 15, 2015, at 8:36 AM, Gary Gregory <garydgregory@gmail.com
> <ma...@gmail.com>> wrote:
>
>> On Sat, Aug 15, 2015 at 4:38 AM, Xen <xen@dds.nl <ma...@dds.nl>>
>> wrote:
>> <snip>
>>
>> Currently I /can't/ work on Log4J because I have supplied a patch
>> or at least a request for comments on the Jira and I haven't had
>> any feedback on that. So how am I supposed to "go ahead and do
>> stuff?". Okay it was also because for a few days my emails didn't
>> get through.
>>
>>
>> <snip>
>>
>> I have asked in one of my emails whether there was a need for
>> additional Builder classes. I got no response to that, so I went
>> ahead and devised one of my own that I think would be handy, the
>> most obvious one. I supplied a Jira (and sent an email, but it
>> didn't get through) and now I'm just still in limbo.
>>
>>
>> <snip>
>>
>> I think we are also in limbo so to speak as to what to do WRT
>> providing a programmatic interface for configuration. We have factory
>> methods, a few builder classes, but probably not a clear road map. We
>> all need to think about the big picture before we continue sprinkling
>> builder classes all over the place.
>>
>> Should such an API be part of the Core or a new log4j-config module
>> where all configuration code would sit? We probably still do not want
>> it as part of the public API? Should the config API aim to configure
>> the Core or any supported logging back-end? Surely we would only
>> start with the Core and worry about the rest later. Or should we? I'm
>> asking a lot of questions I know.
>>
>> How do we even discuss this via emails? That's a lot of writing! Is
>> there are better way to discuss this instead?
>>
>> Gary
>>
>>
>>
>>
>>
>>
>> Op 15-8-2015 om 2:27 schreef Ralph Goers:
>>> Bart, We spent over 2 years asking for feedback during which we
>>> had 13 releases prior to the GA release. We changed, many, many
>>> things. While you are free to criticize Log4j 2 it really
>>> doesn’t accomplish much unless you provide concrete detail on
>>> what should be changed and then expend some effort to do that.
>>>
>>> Projects in the Apache Software Foundation are run by what is
>>> affectionately called a “do-ocracy” - If you see something
>>> broken you fix it, if there is a feature you want you create
>>> it. Creating Jira issues and posting emails is great but in the
>>> end doesn’t accomplish much if no one does anything about it.
>>> Everyone who works on Apache projects is a volunteer. We do it
>>> because we choose to and because we want to, not because we have to.
>>>
>>> The bottom line is that I have a day job that takes more than 40
>>> hours per week of my time. I have a family that requires my
>>> attention. I want to write code and solve people’s problems when
>>> I have the time to work on Log4j. I simply don’t have time to
>>> read long emails that a) don’t ask me how to solve a specific
>>> problem, b) don’t ask for a specific feature to be implemented,
>>> c) don’t ask me how to explain how something works or d) don’t
>>> say “What can I do to help”.
>>>
>>> Please don’t take responses to you as people being rude. Please
>>> take them as we are all busy and want to use our time effectively.
>>>
>>> Ralph
>>>
>>>> On Aug 14, 2015, at 3:02 PM, Xen <xen@dds.nl
>>>> <ma...@dds.nl>> wrote:
>>>>
>>>> I just think... trying to persuade people like that is very needy.
>>>>
>>>> Ralph (Goers) doesn't give me the impression like he's needy
>>>> like that ;-).
>>>>
>>>> It is clear that the new version is a bit out of tune with the
>>>> goals these other projects might have. The requirements for a
>>>> logging package should be a lowest common denominator thing. If
>>>> the product is good, the other projects should notice anyway
>>>> and take notice themselves. I would focus on documentation and
>>>> clarity. You're a bit at odds with the times I think. Do you
>>>> have the interests of your users in mind, or of someone else?
>>>> That's what makes it hard to give a recommendation because it's
>>>> just impossible. I mean "to become more popular". If you feel
>>>> the need to advertize or say "hey, don't forget about us" so
>>>> badly, that just means....
>>>>
>>>> Well anybody can figure that out for himself I guess. But I was
>>>> looking at a topic called Update trunk to Java 7 from last May
>>>> and it didn't seem like their was an urgent need to do so.
>>>>
>>>> Well it means you are on the wrong tract or not feeling confident.
>>>>
>>>> Maybe you really feel like you need a call for attention,
>>>> but.... ... .. . . . . .. .....
>>>>
>>>> Everybody already knows you lol. Your name is well-known. It
>>>> just seems like everyone is stuck using 1.2.
>>>> Stuckerdiestuckstuckstuck. You might want to send out for an
>>>> honest appraisal or feedback.
>>>>
>>>> Ask the question of whether Log4J 2 meets their goals. Ask the
>>>> question of whether 2.3 meets or met their goals. Ask the
>>>> question of whether 2.4 meets or will meet their goals. Ask
>>>> what they want from a logging package. Don't forget to mention
>>>> the issues: Java 7. Public vs. Core -- do they like that? Are
>>>> they impressed by a separation of public versus implementation
>>>> API? If they have experience with the product, do they feel the
>>>> need to use Core functionality that is not normally directly
>>>> accessible from Public?. Did they feel their needs were
>>>> respected when the move to 2 was made? Do they feel the EOL of
>>>> v1 has been a necessary or required or helpful thing?. What are
>>>> their needs and interests? How do they feel about having to use
>>>> two jars? I would seriously consider asking these questions,
>>>> all of them.
>>>>
>>>> So don't ask for uptake, ask for feedback. I think that is the
>>>> best suggestion or advice I can offer. Ask them whether you are
>>>> on the right path. Ask this of your fellow Apache projects. Do
>>>> that and you will do well, or better, in the future. If such a
>>>> thing as 'better' would exist, but you can always do better
>>>> than what you were before.
>>>>
>>>> And that's true of everyone everywhere. That's just true of life.
>>>>
>>>> Regards, B.
>>>>
>>>>
>>>> Op 14-8-2015 om 23:34 schreef Gary Gregory:
>>>>> Something to think about after we get 2.4 out the door...
>>>>>
>>>>> Do you think it appropriate for us to do some kind of outreach
>>>>> to other Apache projects and say "hey, about about use log4j 2?"
>>>>>
>>>>> Gary
>>>>>
>>>>> --
>>>>> E-Mail: garydgregory@gmail.com <ma...@gmail.com>
>>>>> | ggregory@apache.org <ma...@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
>>>>> <http://garygregory.wordpress.com/>
>>>>> Home: http://garygregory.com/
>>>>> Tweet! http://twitter.com/GaryGregory
>>>>
>>>
>>
>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com <ma...@gmail.com> |
>> ggregory@apache.org <ma...@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
>> <http://garygregory.wordpress.com/>
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
Re: Version 2 outreach?
Posted by Ralph Goers <ra...@dslextreme.com>.
My plan is to write some code and then ask for feedback. That seems to have worked well for us in the past.
Sent from my iPad
> On Aug 15, 2015, at 8:36 AM, Gary Gregory <ga...@gmail.com> wrote:
>
>> On Sat, Aug 15, 2015 at 4:38 AM, Xen <xe...@dds.nl> wrote:
>> <snip>
>>
>> Currently I /can't/ work on Log4J because I have supplied a patch or at least a request for comments on the Jira and I haven't had any feedback on that. So how am I supposed to "go ahead and do stuff?". Okay it was also because for a few days my emails didn't get through.
>
> <snip>
>
>> I have asked in one of my emails whether there was a need for additional Builder classes. I got no response to that, so I went ahead and devised one of my own that I think would be handy, the most obvious one. I supplied a Jira (and sent an email, but it didn't get through) and now I'm just still in limbo.
>
> <snip>
>
> I think we are also in limbo so to speak as to what to do WRT providing a programmatic interface for configuration. We have factory methods, a few builder classes, but probably not a clear road map. We all need to think about the big picture before we continue sprinkling builder classes all over the place.
>
> Should such an API be part of the Core or a new log4j-config module where all configuration code would sit? We probably still do not want it as part of the public API? Should the config API aim to configure the Core or any supported logging back-end? Surely we would only start with the Core and worry about the rest later. Or should we? I'm asking a lot of questions I know.
>
> How do we even discuss this via emails? That's a lot of writing! Is there are better way to discuss this instead?
>
> Gary
>
>
>>
>>
>>
>>
>> Op 15-8-2015 om 2:27 schreef Ralph Goers:
>>> Bart, We spent over 2 years asking for feedback during which we had 13 releases prior to the GA release. We changed, many, many things. While you are free to criticize Log4j 2 it really doesn’t accomplish much unless you provide concrete detail on what should be changed and then expend some effort to do that.
>>>
>>> Projects in the Apache Software Foundation are run by what is affectionately called a “do-ocracy” - If you see something broken you fix it, if there is a feature you want you create it. Creating Jira issues and posting emails is great but in the end doesn’t accomplish much if no one does anything about it. Everyone who works on Apache projects is a volunteer. We do it because we choose to and because we want to, not because we have to.
>>>
>>> The bottom line is that I have a day job that takes more than 40 hours per week of my time. I have a family that requires my attention. I want to write code and solve people’s problems when I have the time to work on Log4j. I simply don’t have time to read long emails that a) don’t ask me how to solve a specific problem, b) don’t ask for a specific feature to be implemented, c) don’t ask me how to explain how something works or d) don’t say “What can I do to help”.
>>>
>>> Please don’t take responses to you as people being rude. Please take them as we are all busy and want to use our time effectively.
>>>
>>> Ralph
>>>
>>>> On Aug 14, 2015, at 3:02 PM, Xen <xe...@dds.nl> wrote:
>>>>
>>>> I just think... trying to persuade people like that is very needy.
>>>>
>>>> Ralph (Goers) doesn't give me the impression like he's needy like that ;-).
>>>>
>>>> It is clear that the new version is a bit out of tune with the goals these other projects might have. The requirements for a logging package should be a lowest common denominator thing. If the product is good, the other projects should notice anyway and take notice themselves. I would focus on documentation and clarity. You're a bit at odds with the times I think. Do you have the interests of your users in mind, or of someone else? That's what makes it hard to give a recommendation because it's just impossible. I mean "to become more popular". If you feel the need to advertize or say "hey, don't forget about us" so badly, that just means....
>>>>
>>>> Well anybody can figure that out for himself I guess. But I was looking at a topic called Update trunk to Java 7 from last May and it didn't seem like their was an urgent need to do so.
>>>>
>>>> Well it means you are on the wrong tract or not feeling confident.
>>>>
>>>> Maybe you really feel like you need a call for attention, but.... ... .. . . . . .. .....
>>>>
>>>> Everybody already knows you lol. Your name is well-known. It just seems like everyone is stuck using 1.2. Stuckerdiestuckstuckstuck. You might want to send out for an honest appraisal or feedback.
>>>>
>>>> Ask the question of whether Log4J 2 meets their goals. Ask the question of whether 2.3 meets or met their goals. Ask the question of whether 2.4 meets or will meet their goals. Ask what they want from a logging package. Don't forget to mention the issues: Java 7. Public vs. Core -- do they like that? Are they impressed by a separation of public versus implementation API? If they have experience with the product, do they feel the need to use Core functionality that is not normally directly accessible from Public?. Did they feel their needs were respected when the move to 2 was made? Do they feel the EOL of v1 has been a necessary or required or helpful thing?. What are their needs and interests? How do they feel about having to use two jars? I would seriously consider asking these questions, all of them.
>>>>
>>>> So don't ask for uptake, ask for feedback. I think that is the best suggestion or advice I can offer. Ask them whether you are on the right path. Ask this of your fellow Apache projects. Do that and you will do well, or better, in the future. If such a thing as 'better' would exist, but you can always do better than what you were before.
>>>>
>>>> And that's true of everyone everywhere. That's just true of life.
>>>>
>>>> Regards, B.
>>>>
>>>>
>>>> Op 14-8-2015 om 23:34 schreef Gary Gregory:
>>>>> Something to think about after we get 2.4 out the door...
>>>>>
>>>>> Do you think it appropriate for us to do some kind of outreach to other Apache projects and say "hey, about about use log4j 2?"
>>>>>
>>>>> Gary
>>>>>
>>>>> --
>>>>> E-Mail: garydgregory@gmail.com | ggregory@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: garydgregory@gmail.com | ggregory@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
Re: Version 2 outreach?
Posted by Xen <xe...@dds.nl>.
I can't summarize if you are not willing to do your work I can't do much
else.
Bye.
Op 17-8-2015 om 12:09 schreef Ralph Goers:
> Just letting you know I did NOT read your email beyond the first 2
> paragraphs. It is just way too long. Please summarize if you have
> something important to say.
>
> Ralph
>
> On Aug 16, 2015, at 1:29 AM, Xen <xen@dds.nl <ma...@dds.nl>> wrote:
>
>> Op 15-8-2015 om 17:36 schreef Gary Gregory:
>>
>>> I think we are also in limbo so to speak as to what to do WRT
>>> providing a programmatic interface for configuration. We have
>>> factory methods, a few builder classes, but probably not a clear
>>> road map. We all need to think about the big picture before we
>>> continue sprinkling builder classes all over the place.
>>>
>>> Should such an API be part of the Core or a new log4j-config module
>>> where all configuration code would sit? We probably still do not
>>> want it as part of the public API? Should the config API aim to
>>> configure the Core or any supported logging back-end? Surely we
>>> would only start with the Core and worry about the rest later. Or
>>> should we? I'm asking a lot of questions I know.
>>>
>>> How do we even discuss this via emails? That's a lot of writing! Is
>>> there are better way to discuss this instead?
>>>
>>> Gary
>>
>> Actually first thing I think additional builder classes can't hurt
>> really because they don't really change the API in any way except by
>> creating a convenience that Core-modifiers can use and there is very
>> little chance at this point of them needing to be removed again.
>>
>> Also removing them can't be hard unless they have been in there for a
>> while and code has been built against it. What of course the "public
>> API" sees to avoid.
>>
>> But which it of course doesn't do, maybe for the majority of
>> corporate users, but certainly not for people like me. (I read a
>> wildly megalomanous advert for a software developer today that
>> basically required perfect programming skills from knowing every
>> important language to being "fluid in cross-browser issues" to being
>> wonderfully communicative to taking pride in writing
>> /standards-compliant code/.). Well if standards-complicance is not
>> using the Core API directly, then maybe everything you've said and
>> done is true ;-).
>>
>> Seriously.
>>
>> Anyway. The questions.
>>
>> From what I /see/ happening is that there is going to be some effort
>> in having a nicer interface that does not really need to use
>> individual builders. On the other hand I don't know why other code
>> shouldn't use it but if you derive fields/inputs/values from a config
>> file, then maybe calling individual builder methods is not useful and
>> a create method is better suited. I generally think at this point
>> that you should leave that like that.
>>
>> So programmatic control, me being a layman, depends on two things:
>>
>> - would it really be something that the core developers want? In that
>> case the error message from not having a config file should
>> leave/depart. If config files stop being fully completely totally
>> solely centric, then the initialization code (this is just
>> ConfigurationFactory.java) should not give an error, however it could
>> still be a warning an info or even a debug, as they don't make it
>> through to the StatusLogger in the default config. So the obvious
>> first thing to do is to supply a patch to change that ERROR level to
>> WARN.
>>
>> - at that point you are really 'bug' free to do either
>> XML/JSON/whatever config, or programmatic config. The second thing
>> that is important then is whether you want to keep focussing solely
>> on ConfigurationFactories or whether you want an application to be
>> able to for instance create some personal Logging.init() method or
>> whatever to initialize the system programmatically. The difference is
>> at that point: do we SubClass a ConfigurationFactory (and craft a
>> configuration in it using programmatic control) or do we SubClass a
>> ConfigurationFactory as well as an AbstractConfiguration that will
>> then use programmatic control (or even other means) inside its
>> constructor/initializer, or do we agree or find outselves in
>> agreement with just using a DefaultConfiguration as it is returned
>> and adjusting that?.
>>
>> Those are three different levels of involvement.
>>
>> 1. Free to use the API from the outside.
>> 2. Need to subclass a factory to do it from within (as if you are
>> part of the core yourself now)
>> 3. Need to subclass a factory and even create a new /type/ of
>> configuration (as if you are really deeply mired into the core now).
>>
>> Currently my program that I haven't worked on for days now ;-)...
>>
>> Has just created its own package ( .log ) with a class (Logging) that
>> does everything I need to do configuration wise. At that point, for
>> instance, I am at the choice of whether to stay outside as much as I
>> can, or to let myself be absorbed into Core by subclassing a factory.
>> Currently my .log package does have a factory but it is to avoid the
>> ERROR level message for not having a configuration file.
>>
>> Customizing something really requires staying outside as you deal
>> with the system, because otherwise you ar really writing a form of
>> plugin and you are /extending/ the system just as a way of
>> configuring it.
>>
>> I don't know about the Configurator I must say, it didn't or doesn't
>> seem to do (mostly didn't) the things I wanted from it / from the system.
>>
>> Now of course the endeavour by that can't remember his name to create
>> a ConfigurationBuilder would fit probably the mark of extending the
>> system in order that another won't have to do it anymore.
>>
>> But you have to make these two choices, I can't do it for you:
>>
>> 1. Do you want programmatic configuration to be an equivalent or
>> near-equivalent to config-file based control?
>> 2. Do you want it to be an interface-only element (outside access to
>> configuration methods) a core element that requires factory
>> substantiation or a core element that requires factory substantiation
>> and configuration descendent substantiation?.
>>
>> I think the rest of your choices will follow automatically once
>> you've made these choices and become clear on them. I cannot really
>> say anything about it because my preferences are already known and I
>> like to deal with an interface only, and this was the original goal
>> of the public / separatist API. I am currently actually /doing/ the
>> first of these three things, and so I answer these two questions with
>> a "yes" and a "the first".
>>
>> But the rest is up to you, you have to decide, I can't work with you
>> if you don't because it will be up in the air and you will do
>> something random.
>>
>> Regards...
>>
>> B.
Suggestion for factory extension for programmatic contol (idea)
Posted by Xen <xe...@dds.nl>.
To propose some concrete idea then.
A plugin or extension that would allow programmatic control/config would
have to do at least two things:
- provide a Factory that plugs into core and that enables the easier
control/config.
- provide a Configuration that embodies this.
- provide an interface to both that makes it "public API"
Picture:
http://www.xen.dds.nl/f/i/diagrams/log4j-coreplug1.png
Lol that took me about an hour and a half to construct that picture with
my leet Inkscape skills and no mouse.
Maybe even two hours.
Just so that your precious time won't be wasted in having to read
something unattractive.
I hope you get the idea. There should be a plugin to the core that
enables an interface for the public in which public configuration is
possible. Meaning, the plugin should extend the "API" (I call it
"interface" in the image because API has a different meaning with you).
Since your public API is rather strictly defined, this is hard.
An official Configuration/Builder thing (there could be multiple) would
provide a programming interface that might differ from one version
(offering) to another but would all the same provide elements such that:
- there are methods to construct the configuration
- there is a method to retrieve the configuration builder interface itself
- the same interface/class that yielded the configuration builder to
you, has a method to take what you created with it and put it in place
- this is akin to switching a configuration.
I think those are the essentials.
CustomConfigurationBuilder ccb = CustomConfigurationBuilder.newInstance();
ccb.doStuff();
CCB.setConfiguration( ccb.build() );
or
CustomConfigurationBuilder ccb = CustomConfigurationBuilder.newInstance();
ccb.doStuff();
CCB.install( ccb );
but you have factories
CustomConfigurationFactory ccf = CustomConfigurationFactory.newInstance();
ccf.doStuff();
LogManager.setFactory (ccf); // ugly.
or
CustomConfigurationFactory ccf = CustomConfigurationFactory.newInstance();
CustomConfigurationBuilder ccb = ccf.newBuilder();
ccb.doStuff();
ccf.install( ccb );
LogManager.setFactory( ccf ); // better.
or
CustomConfigurationFactory ccf = CustomConfigurationFactory.newInstance();
CustomConfigurationBuilder ccb = ccf.getBuilder();
ccb.doStuff();
ccf.useBuilder();
LogManager.setFactory( ccf ); // dunno
Ideally you can retrieve the configuration yourself because you might
want to keep multiple copies around:
CustomConfigurationBuilder ccb = CCB.newInstance();
Configuration conf = ccb.doStuff().doStuff().doStuff().build();
CustomConfigurationFactory ccf = new CCF();
ccf.setConfiguration( conf );
LogManager.setFactory( ccf );
later on:
CustomConfigurationBuilder ccb = CCB.newInstance();
Configuration conf2 = ccb.doStuff().doStuff().doStuff().build();
loggerContext.setConfiguration( conf2 ); /// does not exist.
It's all weird.
Question: (I'll put a Jira for this) :
https://issues.apache.org/jira/browse/LOG4J2-1095
Check the attached image. Image:
https://issues.apache.org/jira/secure/attachment/12750883/12750883_log4j-xen-configurationbuilder-uml.jpg
I think our ConfigurationBuilder should build a Specification, the
Specification is fed to the Factory, and the Factory is fed to the
system but it can also reward a direct Configuration.
The specification should be in manual hands.
Other than that the system is perfect I think. Comments on the Jira.
Regards, B.
ccf.doStuff();
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Version 2 outreach?
Posted by Xen <xe...@dds.nl>.
Here is the same message with two paragraphs taken out that are numbered
and that you would have seen had you scrolled down:
You need to determine what level of involvement is required for anyone
doing programmatic customization:
1. Free to use the API from the outside.
2. Need to subclass a factory to do it from within (as if you are part
of the core yourself now)
3. Need to subclass a factory and even create a new /type/ of
configuration (as if you are really deeply mired into the core now).
You have two choices to make:
1. Do you want programmatic configuration to be an equivalent or
near-equivalent to config-file based control?
2. Do you want it to be an interface-only element (outside access to
configuration methods) a core element that requires factory
substantiation or a core element that requires factory substantiation
and configuration descendent substantiation?.
The second choice refers to the first three points.
So the summary of the cut-out summary is:
a. Do you even want real programmatic configuration
b. If you do, do you want it to be as an interface-only thing, as a
core-thing that requires Factory subclassing, or as a core-thing that
requires Factory and Configuration subclassing.
And the summary of that is:
/You must make a principle decisions about these areas if you wish to
continue in any clear way and know what you have to do beyond this point.
/At least that is my belief. Bye, and see ya.
Op 17-8-2015 om 12:09 schreef Ralph Goers:
> Just letting you know I did NOT read your email beyond the first 2
> paragraphs. It is just way too long. Please summarize if you have
> something important to say.
>
> Ralph
>
> On Aug 16, 2015, at 1:29 AM, Xen <xen@dds.nl <ma...@dds.nl>> wrote:
>
>> Op 15-8-2015 om 17:36 schreef Gary Gregory:
>>
>>> I think we are also in limbo so to speak as to what to do WRT
>>> providing a programmatic interface for configuration. We have
>>> factory methods, a few builder classes, but probably not a clear
>>> road map. We all need to think about the big picture before we
>>> continue sprinkling builder classes all over the place.
>>>
>>> Should such an API be part of the Core or a new log4j-config module
>>> where all configuration code would sit? We probably still do not
>>> want it as part of the public API? Should the config API aim to
>>> configure the Core or any supported logging back-end? Surely we
>>> would only start with the Core and worry about the rest later. Or
>>> should we? I'm asking a lot of questions I know.
>>>
>>> How do we even discuss this via emails? That's a lot of writing! Is
>>> there are better way to discuss this instead?
>>>
>>> Gary
>>
>> Actually first thing I think additional builder classes can't hurt
>> really because they don't really change the API in any way except by
>> creating a convenience that Core-modifiers can use and there is very
>> little chance at this point of them needing to be removed again.
>>
>> Also removing them can't be hard unless they have been in there for a
>> while and code has been built against it. What of course the "public
>> API" sees to avoid.
>>
>> But which it of course doesn't do, maybe for the majority of
>> corporate users, but certainly not for people like me. (I read a
>> wildly megalomanous advert for a software developer today that
>> basically required perfect programming skills from knowing every
>> important language to being "fluid in cross-browser issues" to being
>> wonderfully communicative to taking pride in writing
>> /standards-compliant code/.). Well if standards-complicance is not
>> using the Core API directly, then maybe everything you've said and
>> done is true ;-).
>>
>> Seriously.
>>
>> Anyway. The questions.
>>
>> From what I /see/ happening is that there is going to be some effort
>> in having a nicer interface that does not really need to use
>> individual builders. On the other hand I don't know why other code
>> shouldn't use it but if you derive fields/inputs/values from a config
>> file, then maybe calling individual builder methods is not useful and
>> a create method is better suited. I generally think at this point
>> that you should leave that like that.
>>
>> So programmatic control, me being a layman, depends on two things:
>>
>> - would it really be something that the core developers want? In that
>> case the error message from not having a config file should
>> leave/depart. If config files stop being fully completely totally
>> solely centric, then the initialization code (this is just
>> ConfigurationFactory.java) should not give an error, however it could
>> still be a warning an info or even a debug, as they don't make it
>> through to the StatusLogger in the default config. So the obvious
>> first thing to do is to supply a patch to change that ERROR level to
>> WARN.
>>
>> - at that point you are really 'bug' free to do either
>> XML/JSON/whatever config, or programmatic config. The second thing
>> that is important then is whether you want to keep focussing solely
>> on ConfigurationFactories or whether you want an application to be
>> able to for instance create some personal Logging.init() method or
>> whatever to initialize the system programmatically. The difference is
>> at that point: do we SubClass a ConfigurationFactory (and craft a
>> configuration in it using programmatic control) or do we SubClass a
>> ConfigurationFactory as well as an AbstractConfiguration that will
>> then use programmatic control (or even other means) inside its
>> constructor/initializer, or do we agree or find outselves in
>> agreement with just using a DefaultConfiguration as it is returned
>> and adjusting that?.
>>
>> Those are three different levels of involvement.
>>
>> 1. Free to use the API from the outside.
>> 2. Need to subclass a factory to do it from within (as if you are
>> part of the core yourself now)
>> 3. Need to subclass a factory and even create a new /type/ of
>> configuration (as if you are really deeply mired into the core now).
>>
>> Currently my program that I haven't worked on for days now ;-)...
>>
>> Has just created its own package ( .log ) with a class (Logging) that
>> does everything I need to do configuration wise. At that point, for
>> instance, I am at the choice of whether to stay outside as much as I
>> can, or to let myself be absorbed into Core by subclassing a factory.
>> Currently my .log package does have a factory but it is to avoid the
>> ERROR level message for not having a configuration file.
>>
>> Customizing something really requires staying outside as you deal
>> with the system, because otherwise you ar really writing a form of
>> plugin and you are /extending/ the system just as a way of
>> configuring it.
>>
>> I don't know about the Configurator I must say, it didn't or doesn't
>> seem to do (mostly didn't) the things I wanted from it / from the system.
>>
>> Now of course the endeavour by that can't remember his name to create
>> a ConfigurationBuilder would fit probably the mark of extending the
>> system in order that another won't have to do it anymore.
>>
>> But you have to make these two choices, I can't do it for you:
>>
>> 1. Do you want programmatic configuration to be an equivalent or
>> near-equivalent to config-file based control?
>> 2. Do you want it to be an interface-only element (outside access to
>> configuration methods) a core element that requires factory
>> substantiation or a core element that requires factory substantiation
>> and configuration descendent substantiation?.
>>
>> I think the rest of your choices will follow automatically once
>> you've made these choices and become clear on them. I cannot really
>> say anything about it because my preferences are already known and I
>> like to deal with an interface only, and this was the original goal
>> of the public / separatist API. I am currently actually /doing/ the
>> first of these three things, and so I answer these two questions with
>> a "yes" and a "the first".
>>
>> But the rest is up to you, you have to decide, I can't work with you
>> if you don't because it will be up in the air and you will do
>> something random.
>>
>> Regards...
>>
>> B.
Re: Version 2 outreach?
Posted by Ralph Goers <ra...@dslextreme.com>.
Just letting you know I did NOT read your email beyond the first 2 paragraphs. It is just way too long. Please summarize if you have something important to say.
Ralph
> On Aug 16, 2015, at 1:29 AM, Xen <xe...@dds.nl> wrote:
>
> Op 15-8-2015 om 17:36 schreef Gary Gregory:
>
>> I think we are also in limbo so to speak as to what to do WRT providing a programmatic interface for configuration. We have factory methods, a few builder classes, but probably not a clear road map. We all need to think about the big picture before we continue sprinkling builder classes all over the place.
>>
>> Should such an API be part of the Core or a new log4j-config module where all configuration code would sit? We probably still do not want it as part of the public API? Should the config API aim to configure the Core or any supported logging back-end? Surely we would only start with the Core and worry about the rest later. Or should we? I'm asking a lot of questions I know.
>>
>> How do we even discuss this via emails? That's a lot of writing! Is there are better way to discuss this instead?
>>
>> Gary
>
> Actually first thing I think additional builder classes can't hurt really because they don't really change the API in any way except by creating a convenience that Core-modifiers can use and there is very little chance at this point of them needing to be removed again.
>
> Also removing them can't be hard unless they have been in there for a while and code has been built against it. What of course the "public API" sees to avoid.
>
> But which it of course doesn't do, maybe for the majority of corporate users, but certainly not for people like me. (I read a wildly megalomanous advert for a software developer today that basically required perfect programming skills from knowing every important language to being "fluid in cross-browser issues" to being wonderfully communicative to taking pride in writing /standards-compliant code/.). Well if standards-complicance is not using the Core API directly, then maybe everything you've said and done is true ;-).
>
> Seriously.
>
> Anyway. The questions.
>
> From what I /see/ happening is that there is going to be some effort in having a nicer interface that does not really need to use individual builders. On the other hand I don't know why other code shouldn't use it but if you derive fields/inputs/values from a config file, then maybe calling individual builder methods is not useful and a create method is better suited. I generally think at this point that you should leave that like that.
>
> So programmatic control, me being a layman, depends on two things:
>
> - would it really be something that the core developers want? In that case the error message from not having a config file should leave/depart. If config files stop being fully completely totally solely centric, then the initialization code (this is just ConfigurationFactory.java) should not give an error, however it could still be a warning an info or even a debug, as they don't make it through to the StatusLogger in the default config. So the obvious first thing to do is to supply a patch to change that ERROR level to WARN.
>
> - at that point you are really 'bug' free to do either XML/JSON/whatever config, or programmatic config. The second thing that is important then is whether you want to keep focussing solely on ConfigurationFactories or whether you want an application to be able to for instance create some personal Logging.init() method or whatever to initialize the system programmatically. The difference is at that point: do we SubClass a ConfigurationFactory (and craft a configuration in it using programmatic control) or do we SubClass a ConfigurationFactory as well as an AbstractConfiguration that will then use programmatic control (or even other means) inside its constructor/initializer, or do we agree or find outselves in agreement with just using a DefaultConfiguration as it is returned and adjusting that?.
>
> Those are three different levels of involvement.
>
> 1. Free to use the API from the outside.
> 2. Need to subclass a factory to do it from within (as if you are part of the core yourself now)
> 3. Need to subclass a factory and even create a new /type/ of configuration (as if you are really deeply mired into the core now).
>
> Currently my program that I haven't worked on for days now ;-)...
>
> Has just created its own package ( .log ) with a class (Logging) that does everything I need to do configuration wise. At that point, for instance, I am at the choice of whether to stay outside as much as I can, or to let myself be absorbed into Core by subclassing a factory. Currently my .log package does have a factory but it is to avoid the ERROR level message for not having a configuration file.
>
> Customizing something really requires staying outside as you deal with the system, because otherwise you ar really writing a form of plugin and you are extending the system just as a way of configuring it.
>
> I don't know about the Configurator I must say, it didn't or doesn't seem to do (mostly didn't) the things I wanted from it / from the system.
>
> Now of course the endeavour by that can't remember his name to create a ConfigurationBuilder would fit probably the mark of extending the system in order that another won't have to do it anymore.
>
> But you have to make these two choices, I can't do it for you:
>
> 1. Do you want programmatic configuration to be an equivalent or near-equivalent to config-file based control?
> 2. Do you want it to be an interface-only element (outside access to configuration methods) a core element that requires factory substantiation or a core element that requires factory substantiation and configuration descendent substantiation?.
>
> I think the rest of your choices will follow automatically once you've made these choices and become clear on them. I cannot really say anything about it because my preferences are already known and I like to deal with an interface only, and this was the original goal of the public / separatist API. I am currently actually doing the first of these three things, and so I answer these two questions with a "yes" and a "the first".
>
> But the rest is up to you, you have to decide, I can't work with you if you don't because it will be up in the air and you will do something random.
>
> Regards...
>
> B.
Re: Version 2 outreach?
Posted by Xen <xe...@dds.nl>.
Op 15-8-2015 om 17:36 schreef Gary Gregory:
> I think we are also in limbo so to speak as to what to do WRT
> providing a programmatic interface for configuration. We have factory
> methods, a few builder classes, but probably not a clear road map. We
> all need to think about the big picture before we continue sprinkling
> builder classes all over the place.
>
> Should such an API be part of the Core or a new log4j-config module
> where all configuration code would sit? We probably still do not want
> it as part of the public API? Should the config API aim to configure
> the Core or any supported logging back-end? Surely we would only start
> with the Core and worry about the rest later. Or should we? I'm asking
> a lot of questions I know.
>
> How do we even discuss this via emails? That's a lot of writing! Is
> there are better way to discuss this instead?
>
> Gary
Actually first thing I think additional builder classes can't hurt
really because they don't really change the API in any way except by
creating a convenience that Core-modifiers can use and there is very
little chance at this point of them needing to be removed again.
Also removing them can't be hard unless they have been in there for a
while and code has been built against it. What of course the "public
API" sees to avoid.
But which it of course doesn't do, maybe for the majority of corporate
users, but certainly not for people like me. (I read a wildly
megalomanous advert for a software developer today that basically
required perfect programming skills from knowing every important
language to being "fluid in cross-browser issues" to being wonderfully
communicative to taking pride in writing /standards-compliant code/.).
Well if standards-complicance is not using the Core API directly, then
maybe everything you've said and done is true ;-).
Seriously.
Anyway. The questions.
From what I /see/ happening is that there is going to be some effort in
having a nicer interface that does not really need to use individual
builders. On the other hand I don't know why other code shouldn't use it
but if you derive fields/inputs/values from a config file, then maybe
calling individual builder methods is not useful and a create method is
better suited. I generally think at this point that you should leave
that like that.
So programmatic control, me being a layman, depends on two things:
- would it really be something that the core developers want? In that
case the error message from not having a config file should
leave/depart. If config files stop being fully completely totally solely
centric, then the initialization code (this is just
ConfigurationFactory.java) should not give an error, however it could
still be a warning an info or even a debug, as they don't make it
through to the StatusLogger in the default config. So the obvious first
thing to do is to supply a patch to change that ERROR level to WARN.
- at that point you are really 'bug' free to do either XML/JSON/whatever
config, or programmatic config. The second thing that is important then
is whether you want to keep focussing solely on ConfigurationFactories
or whether you want an application to be able to for instance create
some personal Logging.init() method or whatever to initialize the system
programmatically. The difference is at that point: do we SubClass a
ConfigurationFactory (and craft a configuration in it using programmatic
control) or do we SubClass a ConfigurationFactory as well as an
AbstractConfiguration that will then use programmatic control (or even
other means) inside its constructor/initializer, or do we agree or find
outselves in agreement with just using a DefaultConfiguration as it is
returned and adjusting that?.
Those are three different levels of involvement.
1. Free to use the API from the outside.
2. Need to subclass a factory to do it from within (as if you are part
of the core yourself now)
3. Need to subclass a factory and even create a new /type/ of
configuration (as if you are really deeply mired into the core now).
Currently my program that I haven't worked on for days now ;-)...
Has just created its own package ( .log ) with a class (Logging) that
does everything I need to do configuration wise. At that point, for
instance, I am at the choice of whether to stay outside as much as I
can, or to let myself be absorbed into Core by subclassing a factory.
Currently my .log package does have a factory but it is to avoid the
ERROR level message for not having a configuration file.
Customizing something really requires staying outside as you deal with
the system, because otherwise you ar really writing a form of plugin and
you are /extending/ the system just as a way of configuring it.
I don't know about the Configurator I must say, it didn't or doesn't
seem to do (mostly didn't) the things I wanted from it / from the system.
Now of course the endeavour by that can't remember his name to create a
ConfigurationBuilder would fit probably the mark of extending the system
in order that another won't have to do it anymore.
But you have to make these two choices, I can't do it for you:
1. Do you want programmatic configuration to be an equivalent or
near-equivalent to config-file based control?
2. Do you want it to be an interface-only element (outside access to
configuration methods) a core element that requires factory
substantiation or a core element that requires factory substantiation
and configuration descendent substantiation?.
I think the rest of your choices will follow automatically once you've
made these choices and become clear on them. I cannot really say
anything about it because my preferences are already known and I like to
deal with an interface only, and this was the original goal of the
public / separatist API. I am currently actually /doing/ the first of
these three things, and so I answer these two questions with a "yes" and
a "the first".
But the rest is up to you, you have to decide, I can't work with you if
you don't because it will be up in the air and you will do something random.
Regards...
B.
Re: Version 2 outreach?
Posted by Gary Gregory <ga...@gmail.com>.
On Sat, Aug 15, 2015 at 4:38 AM, Xen <xe...@dds.nl> wrote:
<snip>
> Currently I /can't/ work on Log4J because I have supplied a patch or at
> least a request for comments on the Jira and I haven't had any feedback on
> that. So how am I supposed to "go ahead and do stuff?". Okay it was also
> because for a few days my emails didn't get through.
>
<snip>
> I have asked in one of my emails whether there was a need for additional
> Builder classes. I got no response to that, so I went ahead and devised one
> of my own that I think would be handy, the most obvious one. I supplied a
> Jira (and sent an email, but it didn't get through) and now I'm just still
> in limbo.
>
<snip>
I think we are also in limbo so to speak as to what to do WRT providing a
programmatic interface for configuration. We have factory methods, a few
builder classes, but probably not a clear road map. We all need to think
about the big picture before we continue sprinkling builder classes all
over the place.
Should such an API be part of the Core or a new log4j-config module where
all configuration code would sit? We probably still do not want it as part
of the public API? Should the config API aim to configure the Core or any
supported logging back-end? Surely we would only start with the Core and
worry about the rest later. Or should we? I'm asking a lot of questions I
know.
How do we even discuss this via emails? That's a lot of writing! Is there
are better way to discuss this instead?
Gary
>
>
>
> Op 15-8-2015 om 2:27 schreef Ralph Goers:
>
> Bart, We spent over 2 years asking for feedback during which we had 13
> releases prior to the GA release. We changed, many, many things. While you
> are free to criticize Log4j 2 it really doesn’t accomplish much unless you
> provide concrete detail on what should be changed and then expend some
> effort to do that.
>
> Projects in the Apache Software Foundation are run by what is
> affectionately called a “do-ocracy” - If you see something broken you fix
> it, if there is a feature you want you create it. Creating Jira issues and
> posting emails is great but in the end doesn’t accomplish much if no one
> does anything about it. Everyone who works on Apache projects is a
> volunteer. We do it because we choose to and because we want to, not
> because we have to.
>
> The bottom line is that I have a day job that takes more than 40 hours per
> week of my time. I have a family that requires my attention. I want to
> write code and solve people’s problems when I have the time to work on
> Log4j. I simply don’t have time to read long emails that a) don’t ask me
> how to solve a specific problem, b) don’t ask for a specific feature to be
> implemented, c) don’t ask me how to explain how something works or d) don’t
> say “What can I do to help”.
>
> Please don’t take responses to you as people being rude. Please take them
> as we are all busy and want to use our time effectively.
>
> Ralph
>
> On Aug 14, 2015, at 3:02 PM, Xen < <xe...@dds.nl> wrote:
>
> I just think... trying to persuade people like that is very needy.
>
> Ralph (Goers) doesn't give me the impression like he's needy like that ;-).
>
> It is clear that the new version is a bit out of tune with the goals these
> other projects might have. The requirements for a logging package should be
> a lowest common denominator thing. If the product is good, the other
> projects should notice anyway and take notice themselves. I would focus on
> documentation and clarity. You're a bit at odds with the times I think. Do
> you have the interests of your users in mind, or of someone else? That's
> what makes it hard to give a recommendation because it's just impossible. I
> mean "to become more popular". If you feel the need to advertize or say
> "hey, don't forget about us" so badly, that just means....
>
> Well anybody can figure that out for himself I guess. But I was looking at
> a topic called Update trunk to Java 7 from last May and it didn't seem like
> their was an urgent need to do so.
>
> Well it means you are on the wrong tract or not feeling confident.
>
> Maybe you really feel like you need a call for attention, but.... ... .. .
> . . . .. .....
>
> Everybody already knows you lol. Your name is well-known. It just seems
> like everyone is stuck using 1.2. Stuckerdiestuckstuckstuck. You might want
> to send out for an honest appraisal or feedback.
>
> Ask the question of whether Log4J 2 meets their goals. Ask the question of
> whether 2.3 meets or met their goals. Ask the question of whether 2.4 meets
> or will meet their goals. Ask what they want from a logging package. Don't
> forget to mention the issues: Java 7. Public vs. Core -- do they like that?
> Are they impressed by a separation of public versus implementation API? If
> they have experience with the product, do they feel the need to use Core
> functionality that is not normally directly accessible from Public?. Did
> they feel their needs were respected when the move to 2 was made? Do they
> feel the EOL of v1 has been a necessary or required or helpful thing?. What
> are their needs and interests? How do they feel about having to use two
> jars? I would seriously consider asking these questions, all of them.
>
> So don't ask for uptake, ask for feedback. I think that is the best
> suggestion or advice I can offer. Ask them whether you are on the right
> path. Ask this of your fellow Apache projects. Do that and you will do
> well, or better, in the future. If such a thing as 'better' would exist,
> but you can always do better than what you were before.
>
> And that's true of everyone everywhere. That's just true of life.
>
> Regards, B.
>
>
> Op 14-8-2015 om 23:34 schreef Gary Gregory:
>
> Something to think about after we get 2.4 out the door...
>
> Do you think it appropriate for us to do some kind of outreach to other
> Apache projects and say "hey, about about use log4j 2?"
>
> Gary
>
> --
> E-Mail: <ga...@gmail.com>garydgregory@gmail.com | ggregory@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: garydgregory@gmail.com | ggregory@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
Re: Version 2 outreach?
Posted by Gary Gregory <ga...@gmail.com>.
On Sat, Aug 15, 2015 at 4:38 AM, Xen <xe...@dds.nl> wrote:
> That doesn't really mean anything. I'm just saying that today feedback
> might be handy instead of that neediness.
>
> Sorry to say, but I have an interest in this project as well of course,
> and If I seem rude, it's just because I want things to be clear for me and
> for you as well. Maybe that is presumptuous or out of my league or anything
> of that kind -- can't find a better word right now.
>
> Maybe you'd consider that outrageous, I don't know, but to get back:.
>
> I am writing these emails to help you /SAVE/ time because I think and feel
> and know that if you do /ineffective things/ you will in the end not have
> spent your time well.
>
I hope you see the irony of this sentence in light of Ralph's previous
message ;-)
Gary
> You might be "effectively" be spending your time on a disaster course, to
> put it real bluntly, it's not what I mean. You might be effectively doing
> something that in the end doesn't really work out. Then your "effective
> time spent" will still have been very ineffectively spent. You'd agree with
> that, right?.
>
> You wouldn't want to be spending your time on some effort and in the end
> all this time or most of it would have gone to waste because a few years
> down the road you run into a problem (such as lack of uptake/enthusiasm)
> and you can't understand why people are not using your program and in the
> end there were some things you didn't understand at the time.... it could
> be right? .... and you may find you need to revamp a whole lot because it
> is starting to dawn on you.
>
> I know I am being offensive, I can't find a better way to express myself
> about this.. pardon my mind and my illness.
>
> Currently I /can't/ work on Log4J because I have supplied a patch or at
> least a request for comments on the Jira and I haven't had any feedback on
> that. So how am I supposed to "go ahead and do stuff?". Okay it was also
> because for a few days my emails didn't get through.
>
> So you're basically criticising my lack of "do-ocracy lovingness" but I've
> spent at least a number of hours coding and exploring and I just haven't
> had the feedback yet to go on, to do something else.
>
> The code is sitting there in my Git folder and I don't know what to do
> with it, I can't commit it or push it I'd have to fork on Github or
> whatever. This is due to my newness with open source versioning control.
>
> I have asked in one of my emails whether there was a need for additional
> Builder classes. I got no response to that, so I went ahead and devised one
> of my own that I think would be handy, the most obvious one. I supplied a
> Jira (and sent an email, but it didn't get through) and now I'm just still
> in limbo.
>
> Then I spend the time in between to give feedback on what you are doing
> and how you are doing it, and from what I see that is effective and what is
> not effective, and I say some things about it. But most people in open
> source do not consider thinking about effectiveness to be an effective way
> to spend your time, and I guess you are the same.
>
> And how should I know about your family and how you choose to spend your
> time? If you have obligations you don't want, that's none of my business.
>
> I have an illness that basically takes a lot of time from me and causes me
> not to be able to have or hold or try to get any kind of job, nor can I
> finish my studies. That is also none of your business, the way it is stated.
>
> If you can't spend the time reflecting on your endeavours and your
> efforts, well that is your problem not mine. And you also should not ask me
> to make it my problem -- that you don't have time for that.
>
> I am giving the pristinely helpful advice to not go /begging/ yes BEGGING
> for affection from other open source teams. That is basically what Gary
> (And yes I am overreaching my bounds, because I do not know any of you yet)
> (or still) (or whatever) and I am taking the liberty to call you by first
> name as if I know you. Hurt me for it. Please do.
>
> That's basically what mr. Gregory is trying to do. I am just saying it
> might not be as pristinely helpful to do it. To do that. I know I am
> interfering with your business - what am I to it?..
>
> But this is a pubic mailing list and I guess that's the nature of things.
>
> So sorry if I seem to be wasting my time on this. I guess I am, but that
> depends on how welcome or effective it is in getting something through or
> making someone happy, so to say.
>
> I'm just a sorry figure that can't do anything in life. I have no skills
> and no abilities, I try to learn some and I fail.
>
> a) I am asking you to solve a specific problem but the specific problem is
> the architectural problem of the dissinuation of API and Core. Lol. New
> word. You can feel what it means I guess. The problem is that I had to
> spend ample amounts of time just to get through the barrier of learning
> ANYthing about what was hiding behind that public API. This is a real
> problem and a documentation issue at the same time. You can't really expect
> any new user to go through all of this effort or pain just to get
> acquainted with the system. I am spending MY time such that the NEXT user
> will not have to deal with that as I have. The core-api separation is a
> problem in that it tries to dissuade, by its very nature, the user of even
> *Learning* about the core, when the core is very much vital to the
> operation of the machine if you want to have it your way. In other words, I
> do not consider the API as it is presented (the public face) to be anything
> any regular user should have to contend with or feel happy about. Hard
> words perhaps, after all it is your love and brainchild. But I was left in
> the dark, and it was cold. And it took me studying the source of
> ConfigurationFactory (mostly) to begin to understand how I could get the
> system to effectively do what I want. So that public API that is meant to
> make life easier and to shield people from difficult things actually makes
> life much more difficult the moment that public API is not enough, and it
> would really be "not enough" for most people if they are true to
> themselves. By making it a black and white proposition you are forcing
> people to do much more work than if the separation (the shielding) had not
> been made in the first place. So effectively, you might even say.....
>
> Let's call it a time-waster.
>
> Let's just say you have failed in your goal to design something that would
> make a user be content with what the public API was offering and hence
> create a condition in which that user would not need to reach for the Core
> API. This is not the fact. This is not the case. I'm saying it is not the
> case that an average user will not want to reach beyond the public API. I'm
> saying you failed in that.
>
> Pretty immensely I must say.
>
> I am saying that you have shielded the (new) user so much that he/she
> feels he is getting shielded from the stuff he needs. And I'm saying that
> this may be (and is) one of the reasons that people are not all too
> enthusiast of getting on the bandwagon because people sense this.
>
> What you claim as advantage is only 50% advantage and it is 50%
> disadvantage. The API is meant to remain consistent between (major/minor)
> versions but now you are already thinking of getting to a version 3 that
> will change the public API. So where has been the benefit of the public
> API? Has the core changed so much? It was only a short time ago that you
> was still with version 1.2, I believe.
>
> I mean sorry if I'm being rough but I also don't have the time to be nicer
> than this, I have better things to do also.
>
> I have no stats of course on usage numbers and perhaps neither do you I
> don't know. From what I hear and see there are still very many people on
> the older version. They would want to upgrade but really they don't. There
> is something or multiple things holding them back, which makes the time
> required (that you speak of) a bad investment. For what would be the
> benefits? There are really none?....
>
> You are wondering why, or you are asking people to upgrade, but the
> investment seems to simply not pay off. It has a bad RoI.
>
> Me, I am even wondering, as a new user, whether 1.2 would not have been a
> better choice. I sense that there are some... less pretty things to 1.2
> that would hold me off. There are probably some things that really
> preferred an improvement or change, I don't know. I sense that you
> yourselves are not entirely happy with what you ended up with. You feel it,
> you know it. You can keep up the pretense (because you can't let people
> know you have second thoughts) (or they'd think: if *they* are not even
> happy, how could we be?) but everyone feels it and in the end that
> determines your success. It's not what you say, but what you do.
>
> And if you are unhappy with something people will know it regardless,
> whether you say it or not? So why not just publicly say it? At least then
> you'll be understood and people will understand you and you will move
> VASTLY closer to a solution or resolution in almost NO TIME AT ALL. Sorry
> for the caps.
>
> I am saying that admitting to your own flaws (as the way I should as
> well... ?.) puts you in the position where they start to evaporate almost
> instantly. The moment you step into real communication with your
> 'customers' those customers will stop staying at a distance and you and
> they will move closer to each other, both, very rapidly. That's just the
> way it works. That's what counselling is meant for. Maybe I'm an unwanted
> or unwelcome counsellor, so be it ;-).
>
>
>
>
> Op 15-8-2015 om 2:27 schreef Ralph Goers:
>
> Bart, We spent over 2 years asking for feedback during which we had 13
> releases prior to the GA release. We changed, many, many things. While you
> are free to criticize Log4j 2 it really doesn’t accomplish much unless you
> provide concrete detail on what should be changed and then expend some
> effort to do that.
>
> Projects in the Apache Software Foundation are run by what is
> affectionately called a “do-ocracy” - If you see something broken you fix
> it, if there is a feature you want you create it. Creating Jira issues and
> posting emails is great but in the end doesn’t accomplish much if no one
> does anything about it. Everyone who works on Apache projects is a
> volunteer. We do it because we choose to and because we want to, not
> because we have to.
>
> The bottom line is that I have a day job that takes more than 40 hours per
> week of my time. I have a family that requires my attention. I want to
> write code and solve people’s problems when I have the time to work on
> Log4j. I simply don’t have time to read long emails that a) don’t ask me
> how to solve a specific problem, b) don’t ask for a specific feature to be
> implemented, c) don’t ask me how to explain how something works or d) don’t
> say “What can I do to help”.
>
> Please don’t take responses to you as people being rude. Please take them
> as we are all busy and want to use our time effectively.
>
> Ralph
>
> On Aug 14, 2015, at 3:02 PM, Xen < <xe...@dds.nl> wrote:
>
> I just think... trying to persuade people like that is very needy.
>
> Ralph (Goers) doesn't give me the impression like he's needy like that ;-).
>
> It is clear that the new version is a bit out of tune with the goals these
> other projects might have. The requirements for a logging package should be
> a lowest common denominator thing. If the product is good, the other
> projects should notice anyway and take notice themselves. I would focus on
> documentation and clarity. You're a bit at odds with the times I think. Do
> you have the interests of your users in mind, or of someone else? That's
> what makes it hard to give a recommendation because it's just impossible. I
> mean "to become more popular". If you feel the need to advertize or say
> "hey, don't forget about us" so badly, that just means....
>
> Well anybody can figure that out for himself I guess. But I was looking at
> a topic called Update trunk to Java 7 from last May and it didn't seem like
> their was an urgent need to do so.
>
> Well it means you are on the wrong tract or not feeling confident.
>
> Maybe you really feel like you need a call for attention, but.... ... .. .
> . . . .. .....
>
> Everybody already knows you lol. Your name is well-known. It just seems
> like everyone is stuck using 1.2. Stuckerdiestuckstuckstuck. You might want
> to send out for an honest appraisal or feedback.
>
> Ask the question of whether Log4J 2 meets their goals. Ask the question of
> whether 2.3 meets or met their goals. Ask the question of whether 2.4 meets
> or will meet their goals. Ask what they want from a logging package. Don't
> forget to mention the issues: Java 7. Public vs. Core -- do they like that?
> Are they impressed by a separation of public versus implementation API? If
> they have experience with the product, do they feel the need to use Core
> functionality that is not normally directly accessible from Public?. Did
> they feel their needs were respected when the move to 2 was made? Do they
> feel the EOL of v1 has been a necessary or required or helpful thing?. What
> are their needs and interests? How do they feel about having to use two
> jars? I would seriously consider asking these questions, all of them.
>
> So don't ask for uptake, ask for feedback. I think that is the best
> suggestion or advice I can offer. Ask them whether you are on the right
> path. Ask this of your fellow Apache projects. Do that and you will do
> well, or better, in the future. If such a thing as 'better' would exist,
> but you can always do better than what you were before.
>
> And that's true of everyone everywhere. That's just true of life.
>
> Regards, B.
>
>
> Op 14-8-2015 om 23:34 schreef Gary Gregory:
>
> Something to think about after we get 2.4 out the door...
>
> Do you think it appropriate for us to do some kind of outreach to other
> Apache projects and say "hey, about about use log4j 2?"
>
> Gary
>
> --
> E-Mail: <ga...@gmail.com>garydgregory@gmail.com | ggregory@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: garydgregory@gmail.com | ggregory@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
Re: Version 2 outreach?
Posted by Xen <xe...@dds.nl>.
Op 15-8-2015 om 17:26 schreef Gary Gregory:
>
> I am sorry to read that you are ill. I hope get better soon.
>
Heh, you don't know half of half of half of half ;-). But thanks for the
comment and the sweet words.
Op 15-8-2015 om 17:27 schreef Gary Gregory:
> On Sat, Aug 15, 2015 at 4:38 AM, Xen <xen@dds.nl <ma...@dds.nl>>
> wrote:
>
> I am writing these emails to help you /SAVE/ time because I think
> and feel and know that if you do /ineffective things/ you will in
> the end not have spent your time well.
>
>
> I hope you see the irony of this sentence in light of Ralph's previous
> message ;-)
>
> Gary
Haha, no the irony is exactly in reverse. The irony is that Ralph (and
others) think I am wasting his time, while from my perspective and the
actual truth of what I do, I would not be doing it if it was a time
waster. I generally don't run into "doing a lot of stuff for no reason
just because I don't take the time to stop and stare" these days.
Just because someone doesn't see the value of what I do doesn't mean it
is not there. If that was the case I could stop doing everything I've
ever done, because mostly other people, whomever they are, generally
don't agree with my endeavours -- whether it is a father who wants me to
have a 'real' job or an OSS person who thinks his time is better spent
burgeoning on in the same direction without ever stopping to see if it
is still the right direction to go.
Most people in OSS (of FOSS) I would say, are /stuck in a MOVEMENT/.
Re: Version 2 outreach?
Posted by Gary Gregory <ga...@gmail.com>.
On Sat, Aug 15, 2015 at 4:38 AM, Xen <xe...@dds.nl> wrote:
> That doesn't really mean anything. I'm just saying that today feedback
> might be handy instead of that neediness.
>
> Sorry to say, but I have an interest in this project as well of course,
> and If I seem rude, it's just because I want things to be clear for me and
> for you as well. Maybe that is presumptuous or out of my league or anything
> of that kind -- can't find a better word right now.
>
> Maybe you'd consider that outrageous, I don't know, but to get back:.
>
> I am writing these emails to help you /SAVE/ time because I think and feel
> and know that if you do /ineffective things/ you will in the end not have
> spent your time well. You might be "effectively" be spending your time on a
> disaster course, to put it real bluntly, it's not what I mean. You might be
> effectively doing something that in the end doesn't really work out. Then
> your "effective time spent" will still have been very ineffectively spent.
> You'd agree with that, right?.
>
> You wouldn't want to be spending your time on some effort and in the end
> all this time or most of it would have gone to waste because a few years
> down the road you run into a problem (such as lack of uptake/enthusiasm)
> and you can't understand why people are not using your program and in the
> end there were some things you didn't understand at the time.... it could
> be right? .... and you may find you need to revamp a whole lot because it
> is starting to dawn on you.
>
> I know I am being offensive, I can't find a better way to express myself
> about this.. pardon my mind and my illness.
>
> Currently I /can't/ work on Log4J because I have supplied a patch or at
> least a request for comments on the Jira and I haven't had any feedback on
> that. So how am I supposed to "go ahead and do stuff?". Okay it was also
> because for a few days my emails didn't get through.
>
> So you're basically criticising my lack of "do-ocracy lovingness" but I've
> spent at least a number of hours coding and exploring and I just haven't
> had the feedback yet to go on, to do something else.
>
> The code is sitting there in my Git folder and I don't know what to do
> with it, I can't commit it or push it I'd have to fork on Github or
> whatever. This is due to my newness with open source versioning control.
>
> I have asked in one of my emails whether there was a need for additional
> Builder classes. I got no response to that, so I went ahead and devised one
> of my own that I think would be handy, the most obvious one. I supplied a
> Jira (and sent an email, but it didn't get through) and now I'm just still
> in limbo.
>
> Then I spend the time in between to give feedback on what you are doing
> and how you are doing it, and from what I see that is effective and what is
> not effective, and I say some things about it. But most people in open
> source do not consider thinking about effectiveness to be an effective way
> to spend your time, and I guess you are the same.
>
> And how should I know about your family and how you choose to spend your
> time? If you have obligations you don't want, that's none of my business.
>
> I have an illness that basically takes a lot of time from me and causes me
> not to be able to have or hold or try to get any kind of job, nor can I
> finish my studies. That is also none of your business, the way it is stated.
>
I am sorry to read that you are ill. I hope get better soon.
Gary
>
> If you can't spend the time reflecting on your endeavours and your
> efforts, well that is your problem not mine. And you also should not ask me
> to make it my problem -- that you don't have time for that.
>
> I am giving the pristinely helpful advice to not go /begging/ yes BEGGING
> for affection from other open source teams. That is basically what Gary
> (And yes I am overreaching my bounds, because I do not know any of you yet)
> (or still) (or whatever) and I am taking the liberty to call you by first
> name as if I know you. Hurt me for it. Please do.
>
> That's basically what mr. Gregory is trying to do. I am just saying it
> might not be as pristinely helpful to do it. To do that. I know I am
> interfering with your business - what am I to it?..
>
> But this is a pubic mailing list and I guess that's the nature of things.
>
> So sorry if I seem to be wasting my time on this. I guess I am, but that
> depends on how welcome or effective it is in getting something through or
> making someone happy, so to say.
>
> I'm just a sorry figure that can't do anything in life. I have no skills
> and no abilities, I try to learn some and I fail.
>
> a) I am asking you to solve a specific problem but the specific problem is
> the architectural problem of the dissinuation of API and Core. Lol. New
> word. You can feel what it means I guess. The problem is that I had to
> spend ample amounts of time just to get through the barrier of learning
> ANYthing about what was hiding behind that public API. This is a real
> problem and a documentation issue at the same time. You can't really expect
> any new user to go through all of this effort or pain just to get
> acquainted with the system. I am spending MY time such that the NEXT user
> will not have to deal with that as I have. The core-api separation is a
> problem in that it tries to dissuade, by its very nature, the user of even
> *Learning* about the core, when the core is very much vital to the
> operation of the machine if you want to have it your way. In other words, I
> do not consider the API as it is presented (the public face) to be anything
> any regular user should have to contend with or feel happy about. Hard
> words perhaps, after all it is your love and brainchild. But I was left in
> the dark, and it was cold. And it took me studying the source of
> ConfigurationFactory (mostly) to begin to understand how I could get the
> system to effectively do what I want. So that public API that is meant to
> make life easier and to shield people from difficult things actually makes
> life much more difficult the moment that public API is not enough, and it
> would really be "not enough" for most people if they are true to
> themselves. By making it a black and white proposition you are forcing
> people to do much more work than if the separation (the shielding) had not
> been made in the first place. So effectively, you might even say.....
>
> Let's call it a time-waster.
>
> Let's just say you have failed in your goal to design something that would
> make a user be content with what the public API was offering and hence
> create a condition in which that user would not need to reach for the Core
> API. This is not the fact. This is not the case. I'm saying it is not the
> case that an average user will not want to reach beyond the public API. I'm
> saying you failed in that.
>
> Pretty immensely I must say.
>
> I am saying that you have shielded the (new) user so much that he/she
> feels he is getting shielded from the stuff he needs. And I'm saying that
> this may be (and is) one of the reasons that people are not all too
> enthusiast of getting on the bandwagon because people sense this.
>
> What you claim as advantage is only 50% advantage and it is 50%
> disadvantage. The API is meant to remain consistent between (major/minor)
> versions but now you are already thinking of getting to a version 3 that
> will change the public API. So where has been the benefit of the public
> API? Has the core changed so much? It was only a short time ago that you
> was still with version 1.2, I believe.
>
> I mean sorry if I'm being rough but I also don't have the time to be nicer
> than this, I have better things to do also.
>
> I have no stats of course on usage numbers and perhaps neither do you I
> don't know. From what I hear and see there are still very many people on
> the older version. They would want to upgrade but really they don't. There
> is something or multiple things holding them back, which makes the time
> required (that you speak of) a bad investment. For what would be the
> benefits? There are really none?....
>
> You are wondering why, or you are asking people to upgrade, but the
> investment seems to simply not pay off. It has a bad RoI.
>
> Me, I am even wondering, as a new user, whether 1.2 would not have been a
> better choice. I sense that there are some... less pretty things to 1.2
> that would hold me off. There are probably some things that really
> preferred an improvement or change, I don't know. I sense that you
> yourselves are not entirely happy with what you ended up with. You feel it,
> you know it. You can keep up the pretense (because you can't let people
> know you have second thoughts) (or they'd think: if *they* are not even
> happy, how could we be?) but everyone feels it and in the end that
> determines your success. It's not what you say, but what you do.
>
> And if you are unhappy with something people will know it regardless,
> whether you say it or not? So why not just publicly say it? At least then
> you'll be understood and people will understand you and you will move
> VASTLY closer to a solution or resolution in almost NO TIME AT ALL. Sorry
> for the caps.
>
> I am saying that admitting to your own flaws (as the way I should as
> well... ?.) puts you in the position where they start to evaporate almost
> instantly. The moment you step into real communication with your
> 'customers' those customers will stop staying at a distance and you and
> they will move closer to each other, both, very rapidly. That's just the
> way it works. That's what counselling is meant for. Maybe I'm an unwanted
> or unwelcome counsellor, so be it ;-).
>
>
>
>
> Op 15-8-2015 om 2:27 schreef Ralph Goers:
>
> Bart, We spent over 2 years asking for feedback during which we had 13
> releases prior to the GA release. We changed, many, many things. While you
> are free to criticize Log4j 2 it really doesn’t accomplish much unless you
> provide concrete detail on what should be changed and then expend some
> effort to do that.
>
> Projects in the Apache Software Foundation are run by what is
> affectionately called a “do-ocracy” - If you see something broken you fix
> it, if there is a feature you want you create it. Creating Jira issues and
> posting emails is great but in the end doesn’t accomplish much if no one
> does anything about it. Everyone who works on Apache projects is a
> volunteer. We do it because we choose to and because we want to, not
> because we have to.
>
> The bottom line is that I have a day job that takes more than 40 hours per
> week of my time. I have a family that requires my attention. I want to
> write code and solve people’s problems when I have the time to work on
> Log4j. I simply don’t have time to read long emails that a) don’t ask me
> how to solve a specific problem, b) don’t ask for a specific feature to be
> implemented, c) don’t ask me how to explain how something works or d) don’t
> say “What can I do to help”.
>
> Please don’t take responses to you as people being rude. Please take them
> as we are all busy and want to use our time effectively.
>
> Ralph
>
> On Aug 14, 2015, at 3:02 PM, Xen < <xe...@dds.nl> wrote:
>
> I just think... trying to persuade people like that is very needy.
>
> Ralph (Goers) doesn't give me the impression like he's needy like that ;-).
>
> It is clear that the new version is a bit out of tune with the goals these
> other projects might have. The requirements for a logging package should be
> a lowest common denominator thing. If the product is good, the other
> projects should notice anyway and take notice themselves. I would focus on
> documentation and clarity. You're a bit at odds with the times I think. Do
> you have the interests of your users in mind, or of someone else? That's
> what makes it hard to give a recommendation because it's just impossible. I
> mean "to become more popular". If you feel the need to advertize or say
> "hey, don't forget about us" so badly, that just means....
>
> Well anybody can figure that out for himself I guess. But I was looking at
> a topic called Update trunk to Java 7 from last May and it didn't seem like
> their was an urgent need to do so.
>
> Well it means you are on the wrong tract or not feeling confident.
>
> Maybe you really feel like you need a call for attention, but.... ... .. .
> . . . .. .....
>
> Everybody already knows you lol. Your name is well-known. It just seems
> like everyone is stuck using 1.2. Stuckerdiestuckstuckstuck. You might want
> to send out for an honest appraisal or feedback.
>
> Ask the question of whether Log4J 2 meets their goals. Ask the question of
> whether 2.3 meets or met their goals. Ask the question of whether 2.4 meets
> or will meet their goals. Ask what they want from a logging package. Don't
> forget to mention the issues: Java 7. Public vs. Core -- do they like that?
> Are they impressed by a separation of public versus implementation API? If
> they have experience with the product, do they feel the need to use Core
> functionality that is not normally directly accessible from Public?. Did
> they feel their needs were respected when the move to 2 was made? Do they
> feel the EOL of v1 has been a necessary or required or helpful thing?. What
> are their needs and interests? How do they feel about having to use two
> jars? I would seriously consider asking these questions, all of them.
>
> So don't ask for uptake, ask for feedback. I think that is the best
> suggestion or advice I can offer. Ask them whether you are on the right
> path. Ask this of your fellow Apache projects. Do that and you will do
> well, or better, in the future. If such a thing as 'better' would exist,
> but you can always do better than what you were before.
>
> And that's true of everyone everywhere. That's just true of life.
>
> Regards, B.
>
>
> Op 14-8-2015 om 23:34 schreef Gary Gregory:
>
> Something to think about after we get 2.4 out the door...
>
> Do you think it appropriate for us to do some kind of outreach to other
> Apache projects and say "hey, about about use log4j 2?"
>
> Gary
>
> --
> E-Mail: <ga...@gmail.com>garydgregory@gmail.com | ggregory@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: garydgregory@gmail.com | ggregory@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
Re: Version 2 outreach?
Posted by Xen <xe...@dds.nl>.
That doesn't really mean anything. I'm just saying that today feedback
might be handy instead of that neediness.
Sorry to say, but I have an interest in this project as well of course,
and If I seem rude, it's just because I want things to be clear for me
and for you as well. Maybe that is presumptuous or out of my league or
anything of that kind -- can't find a better word right now.
Maybe you'd consider that outrageous, I don't know, but to get back:.
I am writing these emails to help you /SAVE/ time because I think and
feel and know that if you do /ineffective things/ you will in the end
not have spent your time well. You might be "effectively" be spending
your time on a disaster course, to put it real bluntly, it's not what I
mean. You might be effectively doing something that in the end doesn't
really work out. Then your "effective time spent" will still have been
very ineffectively spent. You'd agree with that, right?.
You wouldn't want to be spending your time on some effort and in the end
all this time or most of it would have gone to waste because a few years
down the road you run into a problem (such as lack of uptake/enthusiasm)
and you can't understand why people are not using your program and in
the end there were some things you didn't understand at the time.... it
could be right? .... and you may find you need to revamp a whole lot
because it is starting to dawn on you.
I know I am being offensive, I can't find a better way to express myself
about this.. pardon my mind and my illness.
Currently I /can't/ work on Log4J because I have supplied a patch or at
least a request for comments on the Jira and I haven't had any feedback
on that. So how am I supposed to "go ahead and do stuff?". Okay it was
also because for a few days my emails didn't get through.
So you're basically criticising my lack of "do-ocracy lovingness" but
I've spent at least a number of hours coding and exploring and I just
haven't had the feedback yet to go on, to do something else.
The code is sitting there in my Git folder and I don't know what to do
with it, I can't commit it or push it I'd have to fork on Github or
whatever. This is due to my newness with open source versioning control.
I have asked in one of my emails whether there was a need for additional
Builder classes. I got no response to that, so I went ahead and devised
one of my own that I think would be handy, the most obvious one. I
supplied a Jira (and sent an email, but it didn't get through) and now
I'm just still in limbo.
Then I spend the time in between to give feedback on what you are doing
and how you are doing it, and from what I see that is effective and what
is not effective, and I say some things about it. But most people in
open source do not consider thinking about effectiveness to be an
effective way to spend your time, and I guess you are the same.
And how should I know about your family and how you choose to spend your
time? If you have obligations you don't want, that's none of my business.
I have an illness that basically takes a lot of time from me and causes
me not to be able to have or hold or try to get any kind of job, nor can
I finish my studies. That is also none of your business, the way it is
stated.
If you can't spend the time reflecting on your endeavours and your
efforts, well that is your problem not mine. And you also should not ask
me to make it my problem -- that you don't have time for that.
I am giving the pristinely helpful advice to not go /begging/ yes
BEGGING for affection from other open source teams. That is basically
what Gary (And yes I am overreaching my bounds, because I do not know
any of you yet) (or still) (or whatever) and I am taking the liberty to
call you by first name as if I know you. Hurt me for it. Please do.
That's basically what mr. Gregory is trying to do. I am just saying it
might not be as pristinely helpful to do it. To do that. I know I am
interfering with your business - what am I to it?..
But this is a pubic mailing list and I guess that's the nature of things.
So sorry if I seem to be wasting my time on this. I guess I am, but that
depends on how welcome or effective it is in getting something through
or making someone happy, so to say.
I'm just a sorry figure that can't do anything in life. I have no skills
and no abilities, I try to learn some and I fail.
a) I am asking you to solve a specific problem but the specific problem
is the architectural problem of the dissinuation of API and Core. Lol.
New word. You can feel what it means I guess. The problem is that I had
to spend ample amounts of time just to get through the barrier of
learning ANYthing about what was hiding behind that public API. This is
a real problem and a documentation issue at the same time. You can't
really expect any new user to go through all of this effort or pain just
to get acquainted with the system. I am spending MY time such that the
NEXT user will not have to deal with that as I have. The core-api
separation is a problem in that it tries to dissuade, by its very
nature, the user of even /Learning/ about the core, when the core is
very much vital to the operation of the machine if you want to have it
your way. In other words, I do not consider the API as it is presented
(the public face) to be anything any regular user should have to contend
with or feel happy about. Hard words perhaps, after all it is your love
and brainchild. But I was left in the dark, and it was cold. And it took
me studying the source of ConfigurationFactory (mostly) to begin to
understand how I could get the system to effectively do what I want. So
that public API that is meant to make life easier and to shield people
from difficult things actually makes life much more difficult the moment
that public API is not enough, and it would really be "not enough" for
most people if they are true to themselves. By making it a black and
white proposition you are forcing people to do much more work than if
the separation (the shielding) had not been made in the first place. So
effectively, you might even say.....
Let's call it a time-waster.
Let's just say you have failed in your goal to design something that
would make a user be content with what the public API was offering and
hence create a condition in which that user would not need to reach for
the Core API. This is not the fact. This is not the case. I'm saying it
is not the case that an average user will not want to reach beyond the
public API. I'm saying you failed in that.
Pretty immensely I must say.
I am saying that you have shielded the (new) user so much that he/she
feels he is getting shielded from the stuff he needs. And I'm saying
that this may be (and is) one of the reasons that people are not all too
enthusiast of getting on the bandwagon because people sense this.
What you claim as advantage is only 50% advantage and it is 50%
disadvantage. The API is meant to remain consistent between
(major/minor) versions but now you are already thinking of getting to a
version 3 that will change the public API. So where has been the benefit
of the public API? Has the core changed so much? It was only a short
time ago that you was still with version 1.2, I believe.
I mean sorry if I'm being rough but I also don't have the time to be
nicer than this, I have better things to do also.
I have no stats of course on usage numbers and perhaps neither do you I
don't know. From what I hear and see there are still very many people on
the older version. They would want to upgrade but really they don't.
There is something or multiple things holding them back, which makes the
time required (that you speak of) a bad investment. For what would be
the benefits? There are really none?....
You are wondering why, or you are asking people to upgrade, but the
investment seems to simply not pay off. It has a bad RoI.
Me, I am even wondering, as a new user, whether 1.2 would not have been
a better choice. I sense that there are some... less pretty things to
1.2 that would hold me off. There are probably some things that really
preferred an improvement or change, I don't know. I sense that you
yourselves are not entirely happy with what you ended up with. You feel
it, you know it. You can keep up the pretense (because you can't let
people know you have second thoughts) (or they'd think: if /they/ are
not even happy, how could we be?) but everyone feels it and in the end
that determines your success. It's not what you say, but what you do.
And if you are unhappy with something people will know it regardless,
whether you say it or not? So why not just publicly say it? At least
then you'll be understood and people will understand you and you will
move VASTLY closer to a solution or resolution in almost NO TIME AT ALL.
Sorry for the caps.
I am saying that admitting to your own flaws (as the way I should as
well... ?.) puts you in the position where they start to evaporate
almost instantly. The moment you step into real communication with your
'customers' those customers will stop staying at a distance and you and
they will move closer to each other, both, very rapidly. That's just the
way it works. That's what counselling is meant for. Maybe I'm an
unwanted or unwelcome counsellor, so be it ;-).
Op 15-8-2015 om 2:27 schreef Ralph Goers:
> Bart, We spent over 2 years asking for feedback during which we had
> 13 releases prior to the GA release. We changed, many, many things.
> While you are free to criticize Log4j 2 it really doesn’t accomplish
> much unless you provide concrete detail on what should be changed and
> then expend some effort to do that.
>
> Projects in the Apache Software Foundation are run by what is
> affectionately called a “do-ocracy” - If you see something broken you
> fix it, if there is a feature you want you create it. Creating Jira
> issues and posting emails is great but in the end doesn’t accomplish
> much if no one does anything about it. Everyone who works on Apache
> projects is a volunteer. We do it because we choose to and because we
> want to, not because we have to.
>
> The bottom line is that I have a day job that takes more than 40 hours
> per week of my time. I have a family that requires my attention. I
> want to write code and solve people’s problems when I have the time to
> work on Log4j. I simply don’t have time to read long emails that a)
> don’t ask me how to solve a specific problem, b) don’t ask for a
> specific feature to be implemented, c) don’t ask me how to explain how
> something works or d) don’t say “What can I do to help”.
>
> Please don’t take responses to you as people being rude. Please take
> them as we are all busy and want to use our time effectively.
>
> Ralph
>
>> On Aug 14, 2015, at 3:02 PM, Xen <xen@dds.nl <ma...@dds.nl>> wrote:
>>
>> I just think... trying to persuade people like that is very needy.
>>
>> Ralph (Goers) doesn't give me the impression like he's needy like
>> that ;-).
>>
>> It is clear that the new version is a bit out of tune with the goals
>> these other projects might have. The requirements for a logging
>> package should be a lowest common denominator thing. If the product
>> is good, the other projects should notice anyway and take notice
>> themselves. I would focus on documentation and clarity. You're a bit
>> at odds with the times I think. Do you have the interests of your
>> users in mind, or of someone else? That's what makes it hard to give
>> a recommendation because it's just impossible. I mean "to become more
>> popular". If you feel the need to advertize or say "hey, don't forget
>> about us" so badly, that just means....
>>
>> Well anybody can figure that out for himself I guess. But I was
>> looking at a topic called Update trunk to Java 7 from last May and it
>> didn't seem like their was an urgent need to do so.
>>
>> Well it means you are on the wrong tract or not feeling confident.
>>
>> Maybe you really feel like you need a call for attention, but.... ...
>> .. . . . . .. .....
>>
>> Everybody already knows you lol. Your name is well-known. It just
>> seems like everyone is stuck using 1.2. Stuckerdiestuckstuckstuck.
>> You might want to send out for an honest appraisal or feedback.
>>
>> Ask the question of whether Log4J 2 meets their goals. Ask the
>> question of whether 2.3 meets or met their goals. Ask the question of
>> whether 2.4 meets or will meet their goals. Ask what they want from a
>> logging package. Don't forget to mention the issues: Java 7. Public
>> vs. Core -- do they like that? Are they impressed by a separation of
>> public versus implementation API? If they have experience with the
>> product, do they feel the need to use Core functionality that is not
>> normally directly accessible from Public?. Did they feel their needs
>> were respected when the move to 2 was made? Do they feel the EOL of
>> v1 has been a necessary or required or helpful thing?. What are their
>> needs and interests? How do they feel about having to use two jars? I
>> would seriously consider asking these questions, all of them.
>>
>> So don't ask for uptake, ask for feedback. I think that is the best
>> suggestion or advice I can offer. Ask them whether you are on the
>> right path. Ask this of your fellow Apache projects. Do that and you
>> will do well, or better, in the future. If such a thing as 'better'
>> would exist, but you can always do better than what you were before.
>>
>> And that's true of everyone everywhere. That's just true of life.
>>
>> Regards, B.
>>
>>
>> Op 14-8-2015 om 23:34 schreef Gary Gregory:
>>> Something to think about after we get 2.4 out the door...
>>>
>>> Do you think it appropriate for us to do some kind of outreach to
>>> other Apache projects and say "hey, about about use log4j 2?"
>>>
>>> Gary
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com <ma...@gmail.com> |
>>> ggregory@apache.org <ma...@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
>>> <http://garygregory.wordpress.com/>
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>
>
Re: Version 2 outreach?
Posted by Ralph Goers <ra...@dslextreme.com>.
Bart, We spent over 2 years asking for feedback during which we had 13 releases prior to the GA release. We changed, many, many things. While you are free to criticize Log4j 2 it really doesn’t accomplish much unless you provide concrete detail on what should be changed and then expend some effort to do that.
Projects in the Apache Software Foundation are run by what is affectionately called a “do-ocracy” - If you see something broken you fix it, if there is a feature you want you create it. Creating Jira issues and posting emails is great but in the end doesn’t accomplish much if no one does anything about it. Everyone who works on Apache projects is a volunteer. We do it because we choose to and because we want to, not because we have to.
The bottom line is that I have a day job that takes more than 40 hours per week of my time. I have a family that requires my attention. I want to write code and solve people’s problems when I have the time to work on Log4j. I simply don’t have time to read long emails that a) don’t ask me how to solve a specific problem, b) don’t ask for a specific feature to be implemented, c) don’t ask me how to explain how something works or d) don’t say “What can I do to help”.
Please don’t take responses to you as people being rude. Please take them as we are all busy and want to use our time effectively.
Ralph
> On Aug 14, 2015, at 3:02 PM, Xen <xe...@dds.nl> wrote:
>
> I just think... trying to persuade people like that is very needy.
>
> Ralph (Goers) doesn't give me the impression like he's needy like that ;-).
>
> It is clear that the new version is a bit out of tune with the goals these other projects might have. The requirements for a logging package should be a lowest common denominator thing. If the product is good, the other projects should notice anyway and take notice themselves. I would focus on documentation and clarity. You're a bit at odds with the times I think. Do you have the interests of your users in mind, or of someone else? That's what makes it hard to give a recommendation because it's just impossible. I mean "to become more popular". If you feel the need to advertize or say "hey, don't forget about us" so badly, that just means....
>
> Well anybody can figure that out for himself I guess. But I was looking at a topic called Update trunk to Java 7 from last May and it didn't seem like their was an urgent need to do so.
>
> Well it means you are on the wrong tract or not feeling confident.
>
> Maybe you really feel like you need a call for attention, but.... ... .. . . . . .. .....
>
> Everybody already knows you lol. Your name is well-known. It just seems like everyone is stuck using 1.2. Stuckerdiestuckstuckstuck. You might want to send out for an honest appraisal or feedback.
>
> Ask the question of whether Log4J 2 meets their goals. Ask the question of whether 2.3 meets or met their goals. Ask the question of whether 2.4 meets or will meet their goals. Ask what they want from a logging package. Don't forget to mention the issues: Java 7. Public vs. Core -- do they like that? Are they impressed by a separation of public versus implementation API? If they have experience with the product, do they feel the need to use Core functionality that is not normally directly accessible from Public?. Did they feel their needs were respected when the move to 2 was made? Do they feel the EOL of v1 has been a necessary or required or helpful thing?. What are their needs and interests? How do they feel about having to use two jars? I would seriously consider asking these questions, all of them.
>
> So don't ask for uptake, ask for feedback. I think that is the best suggestion or advice I can offer. Ask them whether you are on the right path. Ask this of your fellow Apache projects. Do that and you will do well, or better, in the future. If such a thing as 'better' would exist, but you can always do better than what you were before.
>
> And that's true of everyone everywhere. That's just true of life.
>
> Regards, B.
>
>
> Op 14-8-2015 om 23:34 schreef Gary Gregory:
>> Something to think about after we get 2.4 out the door...
>>
>> Do you think it appropriate for us to do some kind of outreach to other Apache projects and say "hey, about about use log4j 2?"
>>
>> Gary
>>
>> --
>> E-Mail: garydgregory@gmail.com <ma...@gmail.com> | ggregory@apache.org <ma...@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 <http://garygregory.wordpress.com/>
>> Home: http://garygregory.com/ <http://garygregory.com/>
>> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
Re: Version 2 outreach?
Posted by Xen <xe...@dds.nl>.
I just think... trying to persuade people like that is very needy.
Ralph (Goers) doesn't give me the impression like he's needy like that ;-).
It is clear that the new version is a bit out of tune with the goals
these other projects might have. The requirements for a logging package
should be a lowest common denominator thing. If the product is good, the
other projects should notice anyway and take notice themselves. I would
focus on documentation and clarity. You're a bit at odds with the times
I think. Do you have the interests of your users in mind, or of someone
else? That's what makes it hard to give a recommendation because it's
just impossible. I mean "to become more popular". If you feel the need
to advertize or say "hey, don't forget about us" so badly, that just
means....
Well anybody can figure that out for himself I guess. But I was looking
at a topic called Update trunk to Java 7 from last May and it didn't
seem like their was an urgent need to do so.
Well it means you are on the wrong tract or not feeling confident.
Maybe you really feel like you need a call for attention, but.... ... ..
. . . . .. .....
Everybody already knows you lol. Your name is well-known. It just seems
like everyone is stuck using 1.2. Stuckerdiestuckstuckstuck. You might
want to send out for an honest appraisal or feedback.
Ask the question of whether Log4J 2 meets their goals. Ask the question
of whether 2.3 meets or met their goals. Ask the question of whether 2.4
meets or will meet their goals. Ask what they want from a logging
package. Don't forget to mention the issues: Java 7. Public vs. Core --
do they like that? Are they impressed by a separation of public versus
implementation API? If they have experience with the product, do they
feel the need to use Core functionality that is not normally directly
accessible from Public?. Did they feel their needs were respected when
the move to 2 was made? Do they feel the EOL of v1 has been a necessary
or required or helpful thing?. What are their needs and interests? How
do they feel about having to use two jars? I would seriously consider
asking these questions, all of them.
So don't ask for uptake, ask for feedback. I think that is the best
suggestion or advice I can offer. Ask them whether you are on the right
path. Ask this of your fellow Apache projects. Do that and you will do
well, or better, in the future. If such a thing as 'better' would exist,
but you can always do better than what you were before.
And that's true of everyone everywhere. That's just true of life.
Regards, B.
Op 14-8-2015 om 23:34 schreef Gary Gregory:
> Something to think about after we get 2.4 out the door...
>
> Do you think it appropriate for us to do some kind of outreach to
> other Apache projects and say "hey, about about use log4j 2?"
>
> Gary
>
> --
> E-Mail: garydgregory@gmail.com <ma...@gmail.com> |
> ggregory@apache.org <ma...@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
> <http://garygregory.wordpress.com/>
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory