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 2016/09/01 18:40:00 UTC
Deprecated factory methods replaced by builders.
Hi,
When can we delete factory methods that are deprecated by builders?
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: Deprecated factory methods replaced by builders.
Posted by Remko Popma <re...@gmail.com>.
That may be the simplest solution. We can think more on what to do with
this in a subsequent release.
On Wed, Sep 7, 2016 at 1:31 AM, Matt Sicker <bo...@gmail.com> wrote:
> Should we revert those commits? There's still time.
>
> On 3 September 2016 at 01:12, Ralph Goers <ra...@dslextreme.com>
> wrote:
>
>> Perhaps we shouldn’t have.
>>
>> Ralph
>>
>> On Sep 2, 2016, at 7:46 PM, Matt Sicker <bo...@gmail.com> wrote:
>>
>> We've already removed several deprecated factories in this upcoming
>> release, though.
>>
>> On 2 September 2016 at 06:28, Mikael Ståldal <mi...@magine.com>
>> wrote:
>>
>>> I agree with Remko, let's keep them unless they are in the way. We can
>>> remove all of them in Log4j 3.0.
>>>
>>> On Fri, Sep 2, 2016 at 1:31 AM, Remko Popma <re...@gmail.com>
>>> wrote:
>>>
>>>> It was mentioned on a mailing list or twitter conversation with
>>>> maintainers of another Apache project that one of the reasons they hesitate
>>>> to migrate to Log4j is that they worry we will break binary compatibility.
>>>>
>>>> Removing the factory methods just because we deprecated them seems a
>>>> bit harsh.
>>>> It's not like it's a huge maintenance effort to keep them.
>>>>
>>>> I would not remove the deprecated factory methods unless they actively
>>>> prevent us from doing something we want to do.
>>>>
>>>> Remko
>>>> Sent from my iPhone
>>>>
>>>> On 2016/09/02, at 6:29, Ralph Goers <ra...@dslextreme.com> wrote:
>>>>
>>>> Well, Java seems to have a policy of waiting at least 10 years, if
>>>> ever….
>>>>
>>>> Seriously, I don’t think 1 minor release is enough as that might very
>>>> well be the next release. I’d say 2 minor releases and at least 6 months.
>>>>
>>>> Ralph
>>>>
>>>> On Sep 1, 2016, at 1:42 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>
>>>> I think that when you add a builder and deprecate the factory, you
>>>> should remove it in the next 2.x release. Otherwise, deprecation has no
>>>> point if there's no version with the deprecation specified.
>>>>
>>>> On 1 September 2016 at 13:40, Gary Gregory <ga...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> When can we delete factory methods that are deprecated by builders?
>>>>>
>>>>> Gary
>>>>>
>>>>> --
>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>> <gg...@apache.org>
>>>>> Java Persistence with Hibernate, Second Edition
>>>>> <http://www.manning.com/bauer3/>
>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>> Blog: http://garygregory.wordpress.com
>>>>> Home: http://garygregory.com/
>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <bo...@gmail.com>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> [image: MagineTV]
>>>
>>> *Mikael Ståldal*
>>> Senior software developer
>>>
>>> *Magine TV*
>>> mikael.staldal@magine.com
>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>> <http://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.
>>>
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>>
>>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
Re: Deprecated factory methods replaced by builders.
Posted by Gary Gregory <ga...@gmail.com>.
For Core util's NullOutputStream, I deprecated NULL_OUTPUT_STREAM in favor
of getInstance(). It seems OK to delete NULL_OUTPUT_STREAM altogether IMO.
Thoughts from others?
Gary
On Wed, Sep 7, 2016 at 8:52 PM, Matt Sicker <bo...@gmail.com> wrote:
> I agree that util packages are out of scope for BC. That's especially true
> in log4j-api where everything else has BC concerns.
>
> On 7 September 2016 at 21:14, Gary Gregory <ga...@gmail.com> wrote:
>
>> I do not think NullOutputStream.NULL_OUTPUT_STREAM is a good example
>> because the Core util package is or should out of bounds for BC. I thought
>> we had "agreed" on that.
>>
>> Gary
>>
>> On Wed, Sep 7, 2016 at 5:29 PM, Remko Popma <re...@gmail.com>
>> wrote:
>>
>>> We should make an effort not to break compatibility unless it's
>>> unavoidable. There is usually a way to accomplish things without breaking
>>> BC.
>>>
>>> This is doubly true for plugins but should be our policy in general.
>>>
>>> We should not make breaking changes for aesthetic reasons. For example,
>>> NullOutputStream.NULL_OUTPUT_STREAM would have been better named
>>> INSTANCE, but this is one thing I would not change at this stage.
>>>
>>> One of the reasons people (I think on the Spark mailing list) mentioned
>>> for putting off upgrading from Log4j 1.2 to Log4j 2 was worries we would
>>> make breaking changes.
>>>
>>>
>>> Sent from my iPhone
>>>
>>> On 2016/09/08, at 8:03, Gary Gregory <ga...@gmail.com> wrote:
>>>
>>> On Wed, Sep 7, 2016 at 1:02 PM, Ralph Goers <ra...@dslextreme.com>
>>> wrote:
>>>
>>>> We really need to document what we want to strive to maintain
>>>> compatibility with in core. Basic components like Appenders and their
>>>> managers, Filters, Layouts, & Lookups or pretty much any Plugin type would
>>>> be at the top of my list.
>>>>
>>>
>>> Bleh, then we need to mark methods in some @tag-way in Javadocs.
>>>
>>> Gary
>>>
>>>>
>>>> Ralph
>>>>
>>>> On Sep 7, 2016, at 11:05 AM, Gary Gregory <ga...@gmail.com>
>>>> wrote:
>>>>
>>>> On Wed, Sep 7, 2016 at 11:41 AM, Remko Popma <re...@gmail.com>
>>>> wrote:
>>>>
>>>>> We should do this before starting the 2.7 release.
>>>>> If we are serious about being the replacement for Log4j 1.2 we should
>>>>> not break user code for no good reason.
>>>>>
>>>>
>>>> What does this have to do with 1.2?
>>>>
>>>> Gary
>>>>
>>>>>
>>>>> On Wed, Sep 7, 2016 at 7:25 AM, Remko Popma <re...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> I think that would be good.
>>>>>>
>>>>>> Based on the number of Jira tickets being filed we are beginning to
>>>>>> see increased uptake. Programmatic configuration is used surprisingly
>>>>>> often. Leaving the factory methods in with some reasonable default for the
>>>>>> missing parameters ensures existing users can smoothly upgrade.
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> On 2016/09/07, at 3:03, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>
>>>>>> All the commits that removed deprecated factory methods it sounds
>>>>>> like.
>>>>>>
>>>>>> On 6 September 2016 at 13:00, Gary Gregory <ga...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> On Tue, Sep 6, 2016 at 12:31 PM, Matt Sicker <bo...@gmail.com> wrot
>>>>>>> e:
>>>>>>>
>>>>>>>> Should we revert those commits? There's still time.
>>>>>>>>
>>>>>>>
>>>>>>> What commit? Do you mean to add back factory methods?
>>>>>>>
>>>>>>> Gary
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> On 3 September 2016 at 01:12, Ralph Goers <ralph.goers@dslextreme.
>>>>>>>> com> wrote:
>>>>>>>>
>>>>>>>>> Perhaps we shouldn’t have.
>>>>>>>>>
>>>>>>>>> Ralph
>>>>>>>>>
>>>>>>>>> On Sep 2, 2016, at 7:46 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> We've already removed several deprecated factories in this
>>>>>>>>> upcoming release, though.
>>>>>>>>>
>>>>>>>>> On 2 September 2016 at 06:28, Mikael Ståldal <
>>>>>>>>> mikael.staldal@magine.com> wrote:
>>>>>>>>>
>>>>>>>>>> I agree with Remko, let's keep them unless they are in the way.
>>>>>>>>>> We can remove all of them in Log4j 3.0.
>>>>>>>>>>
>>>>>>>>>> On Fri, Sep 2, 2016 at 1:31 AM, Remko Popma <
>>>>>>>>>> remko.popma@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> It was mentioned on a mailing list or twitter conversation with
>>>>>>>>>>> maintainers of another Apache project that one of the reasons they hesitate
>>>>>>>>>>> to migrate to Log4j is that they worry we will break binary compatibility.
>>>>>>>>>>>
>>>>>>>>>>> Removing the factory methods just because we deprecated them
>>>>>>>>>>> seems a bit harsh.
>>>>>>>>>>> It's not like it's a huge maintenance effort to keep them.
>>>>>>>>>>>
>>>>>>>>>>> I would not remove the deprecated factory methods unless they
>>>>>>>>>>> actively prevent us from doing something we want to do.
>>>>>>>>>>>
>>>>>>>>>>> Remko
>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>
>>>>>>>>>>> On 2016/09/02, at 6:29, Ralph Goers <ra...@dslextreme.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Well, Java seems to have a policy of waiting at least 10 years,
>>>>>>>>>>> if ever….
>>>>>>>>>>>
>>>>>>>>>>> Seriously, I don’t think 1 minor release is enough as that might
>>>>>>>>>>> very well be the next release. I’d say 2 minor releases and at least 6
>>>>>>>>>>> months.
>>>>>>>>>>>
>>>>>>>>>>> Ralph
>>>>>>>>>>>
>>>>>>>>>>> On Sep 1, 2016, at 1:42 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> I think that when you add a builder and deprecate the factory,
>>>>>>>>>>> you should remove it in the next 2.x release. Otherwise, deprecation has no
>>>>>>>>>>> point if there's no version with the deprecation specified.
>>>>>>>>>>>
>>>>>>>>>>> On 1 September 2016 at 13:40, Gary Gregory <
>>>>>>>>>>> garydgregory@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> When can we delete factory methods that are deprecated by
>>>>>>>>>>>> builders?
>>>>>>>>>>>>
>>>>>>>>>>>> Gary
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>>>>>> <gg...@apache.org>
>>>>>>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>>>>>>> <http://www.manning.com/bauer3/>
>>>>>>>>>>>> JUnit in Action, Second Edition
>>>>>>>>>>>> <http://www.manning.com/tahchiev/>
>>>>>>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>>>>>> Home: http://garygregory.com/
>>>>>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> [image: MagineTV]
>>>>>>>>>>
>>>>>>>>>> *Mikael Ståldal*
>>>>>>>>>> Senior software developer
>>>>>>>>>>
>>>>>>>>>> *Magine TV*
>>>>>>>>>> mikael.staldal@magine.com
>>>>>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>>>>>>>> <http://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.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>> <gg...@apache.org>
>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>> <http://www.manning.com/bauer3/>
>>>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>> Home: http://garygregory.com/
>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>> <gg...@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
>>>
>>>
>>
>>
>> --
>> 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
>>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
--
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: Deprecated factory methods replaced by builders.
Posted by Ralph Goers <ra...@dslextreme.com>.
What about them? Do they fit into the category of anything I have described? No.
Ralph
> On Sep 7, 2016, at 10:18 PM, Gary Gregory <ga...@gmail.com> wrote:
>
> What about code in the Core util package?
>
> Gary
>
>> On Wed, Sep 7, 2016 at 10:06 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>> Everything is internal, but as I said previously, there are things where we do want to try to maintain compatibility - plugins being one of them. Also as I said, we really need to document where anyone making customizations is at risk and where they aren’t.
>>
>> Ralph
>>
>>> On Sep 7, 2016, at 9:22 PM, Gary Gregory <ga...@gmail.com> wrote:
>>>
>>>> On Wed, Sep 7, 2016 at 9:17 PM, Remko Popma <re...@gmail.com> wrote:
>>>> Okay.
>>>> Shall we introduce an @Internal annotation?
>>>
>>> Please no, everything in Core is internal. I think we need to start with English sentences before we get caught up on details of how to communicate that to users.
>>>
>>> Gary
>>>
>>>>
>>>> Sent from my iPhone
>>>>
>>>>> On 2016/09/08, at 12:52, Matt Sicker <bo...@gmail.com> wrote:
>>>>>
>>>>> I agree that util packages are out of scope for BC. That's especially true in log4j-api where everything else has BC concerns.
>>>>>
>>>>>> On 7 September 2016 at 21:14, Gary Gregory <ga...@gmail.com> wrote:
>>>>>> I do not think NullOutputStream.NULL_OUTPUT_STREAM is a good example because the Core util package is or should out of bounds for BC. I thought we had "agreed" on that.
>>>>>>
>>>>>> Gary
>>>>>>
>>>>>>> On Wed, Sep 7, 2016 at 5:29 PM, Remko Popma <re...@gmail.com> wrote:
>>>>>>> We should make an effort not to break compatibility unless it's unavoidable. There is usually a way to accomplish things without breaking BC.
>>>>>>>
>>>>>>> This is doubly true for plugins but should be our policy in general.
>>>>>>>
>>>>>>> We should not make breaking changes for aesthetic reasons. For example, NullOutputStream.NULL_OUTPUT_STREAM would have been better named INSTANCE, but this is one thing I would not change at this stage.
>>>>>>>
>>>>>>> One of the reasons people (I think on the Spark mailing list) mentioned for putting off upgrading from Log4j 1.2 to Log4j 2 was worries we would make breaking changes.
>>>>>>>
>>>>>>>
>>>>>>> Sent from my iPhone
>>>>>>>
>>>>>>>> On 2016/09/08, at 8:03, Gary Gregory <ga...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> On Wed, Sep 7, 2016 at 1:02 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>>>>>>>>> We really need to document what we want to strive to maintain compatibility with in core. Basic components like Appenders and their managers, Filters, Layouts, & Lookups or pretty much any Plugin type would be at the top of my list.
>>>>>>>>
>>>>>>>> Bleh, then we need to mark methods in some @tag-way in Javadocs.
>>>>>>>>
>>>>>>>> Gary
>>>>>>>>>
>>>>>>>>> Ralph
>>>>>>>>>
>>>>>>>>>> On Sep 7, 2016, at 11:05 AM, Gary Gregory <ga...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> On Wed, Sep 7, 2016 at 11:41 AM, Remko Popma <re...@gmail.com> wrote:
>>>>>>>>>>> We should do this before starting the 2.7 release.
>>>>>>>>>>> If we are serious about being the replacement for Log4j 1.2 we should not break user code for no good reason.
>>>>>>>>>>
>>>>>>>>>> What does this have to do with 1.2?
>>>>>>>>>>
>>>>>>>>>> Gary
>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Sep 7, 2016 at 7:25 AM, Remko Popma <re...@gmail.com> wrote:
>>>>>>>>>>>> I think that would be good.
>>>>>>>>>>>>
>>>>>>>>>>>> Based on the number of Jira tickets being filed we are beginning to see increased uptake. Programmatic configuration is used surprisingly often. Leaving the factory methods in with some reasonable default for the missing parameters ensures existing users can smoothly upgrade.
>>>>>>>>>>>>
>>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>
>>>>>>>>>>>>> On 2016/09/07, at 3:03, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> All the commits that removed deprecated factory methods it sounds like.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 6 September 2016 at 13:00, Gary Gregory <ga...@gmail.com> wrote:
>>>>>>>>>>>>>>> On Tue, Sep 6, 2016 at 12:31 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>>>>>> Should we revert those commits? There's still time.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> What commit? Do you mean to add back factory methods?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Gary
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 3 September 2016 at 01:12, Ralph Goers <ra...@dslextreme.com> wrote:
>>>>>>>>>>>>>>>> Perhaps we shouldn’t have.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Sep 2, 2016, at 7:46 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> We've already removed several deprecated factories in this upcoming release, though.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 2 September 2016 at 06:28, Mikael Ståldal <mi...@magine.com> wrote:
>>>>>>>>>>>>>>>>>> I agree with Remko, let's keep them unless they are in the way. We can remove all of them in Log4j 3.0.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Fri, Sep 2, 2016 at 1:31 AM, Remko Popma <re...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>> It was mentioned on a mailing list or twitter conversation with maintainers of another Apache project that one of the reasons they hesitate to migrate to Log4j is that they worry we will break binary compatibility.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Removing the factory methods just because we deprecated them seems a bit harsh.
>>>>>>>>>>>>>>>>>>> It's not like it's a huge maintenance effort to keep them.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I would not remove the deprecated factory methods unless they actively prevent us from doing something we want to do.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Remko
>>>>>>>>>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 2016/09/02, at 6:29, Ralph Goers <ra...@dslextreme.com> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Well, Java seems to have a policy of waiting at least 10 years, if ever….
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Seriously, I don’t think 1 minor release is enough as that might very well be the next release. I’d say 2 minor releases and at least 6 months.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On Sep 1, 2016, at 1:42 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I think that when you add a builder and deprecate the factory, you should remove it in the next 2.x release. Otherwise, deprecation has no point if there's no version with the deprecation specified.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 1 September 2016 at 13:40, Gary Gregory <ga...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> When can we delete factory methods that are deprecated by builders?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Mikael Ståldal
>>>>>>>>>>>>>>>>>> Senior software developer
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Magine TV
>>>>>>>>>>>>>>>>>> mikael.staldal@magine.com
>>>>>>>>>>>>>>>>>> Grev Turegatan 3 | 114 46 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.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker <bo...@gmail.com>
>>>
>>>
>>>
>>> --
>>> 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: Deprecated factory methods replaced by builders.
Posted by Gary Gregory <ga...@gmail.com>.
What about code in the Core util package?
Gary
On Wed, Sep 7, 2016 at 10:06 PM, Ralph Goers <ra...@dslextreme.com>
wrote:
> Everything is internal, but as I said previously, there are things where
> we do want to try to maintain compatibility - plugins being one of them.
> Also as I said, we really need to document where anyone making
> customizations is at risk and where they aren’t.
>
> Ralph
>
> On Sep 7, 2016, at 9:22 PM, Gary Gregory <ga...@gmail.com> wrote:
>
> On Wed, Sep 7, 2016 at 9:17 PM, Remko Popma <re...@gmail.com> wrote:
>
>> Okay.
>> Shall we introduce an @Internal annotation?
>>
>
> Please no, everything in Core is internal. I think we need to start with
> English sentences before we get caught up on details of how to communicate
> that to users.
>
> Gary
>
>
>>
>> Sent from my iPhone
>>
>> On 2016/09/08, at 12:52, Matt Sicker <bo...@gmail.com> wrote:
>>
>> I agree that util packages are out of scope for BC. That's especially
>> true in log4j-api where everything else has BC concerns.
>>
>> On 7 September 2016 at 21:14, Gary Gregory <ga...@gmail.com>
>> wrote:
>>
>>> I do not think NullOutputStream.NULL_OUTPUT_STREAM is a good example
>>> because the Core util package is or should out of bounds for BC. I thought
>>> we had "agreed" on that.
>>>
>>> Gary
>>>
>>> On Wed, Sep 7, 2016 at 5:29 PM, Remko Popma <re...@gmail.com>
>>> wrote:
>>>
>>>> We should make an effort not to break compatibility unless it's
>>>> unavoidable. There is usually a way to accomplish things without breaking
>>>> BC.
>>>>
>>>> This is doubly true for plugins but should be our policy in general.
>>>>
>>>> We should not make breaking changes for aesthetic reasons. For example,
>>>> NullOutputStream.NULL_OUTPUT_STREAM would have been better named
>>>> INSTANCE, but this is one thing I would not change at this stage.
>>>>
>>>> One of the reasons people (I think on the Spark mailing list) mentioned
>>>> for putting off upgrading from Log4j 1.2 to Log4j 2 was worries we would
>>>> make breaking changes.
>>>>
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On 2016/09/08, at 8:03, Gary Gregory <ga...@gmail.com> wrote:
>>>>
>>>> On Wed, Sep 7, 2016 at 1:02 PM, Ralph Goers <ralph.goers@dslextreme.com
>>>> > wrote:
>>>>
>>>>> We really need to document what we want to strive to maintain
>>>>> compatibility with in core. Basic components like Appenders and their
>>>>> managers, Filters, Layouts, & Lookups or pretty much any Plugin type would
>>>>> be at the top of my list.
>>>>>
>>>>
>>>> Bleh, then we need to mark methods in some @tag-way in Javadocs.
>>>>
>>>> Gary
>>>>
>>>>>
>>>>> Ralph
>>>>>
>>>>> On Sep 7, 2016, at 11:05 AM, Gary Gregory <ga...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> On Wed, Sep 7, 2016 at 11:41 AM, Remko Popma <re...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> We should do this before starting the 2.7 release.
>>>>>> If we are serious about being the replacement for Log4j 1.2 we should
>>>>>> not break user code for no good reason.
>>>>>>
>>>>>
>>>>> What does this have to do with 1.2?
>>>>>
>>>>> Gary
>>>>>
>>>>>>
>>>>>> On Wed, Sep 7, 2016 at 7:25 AM, Remko Popma <re...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I think that would be good.
>>>>>>>
>>>>>>> Based on the number of Jira tickets being filed we are beginning to
>>>>>>> see increased uptake. Programmatic configuration is used surprisingly
>>>>>>> often. Leaving the factory methods in with some reasonable default for the
>>>>>>> missing parameters ensures existing users can smoothly upgrade.
>>>>>>>
>>>>>>> Sent from my iPhone
>>>>>>>
>>>>>>> On 2016/09/07, at 3:03, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>
>>>>>>> All the commits that removed deprecated factory methods it sounds
>>>>>>> like.
>>>>>>>
>>>>>>> On 6 September 2016 at 13:00, Gary Gregory <ga...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On Tue, Sep 6, 2016 at 12:31 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Should we revert those commits? There's still time.
>>>>>>>>>
>>>>>>>>
>>>>>>>> What commit? Do you mean to add back factory methods?
>>>>>>>>
>>>>>>>> Gary
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 3 September 2016 at 01:12, Ralph Goers <ralph.goers@dslextreme.
>>>>>>>>> com> wrote:
>>>>>>>>>
>>>>>>>>>> Perhaps we shouldn’t have.
>>>>>>>>>>
>>>>>>>>>> Ralph
>>>>>>>>>>
>>>>>>>>>> On Sep 2, 2016, at 7:46 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> We've already removed several deprecated factories in this
>>>>>>>>>> upcoming release, though.
>>>>>>>>>>
>>>>>>>>>> On 2 September 2016 at 06:28, Mikael Ståldal <
>>>>>>>>>> mikael.staldal@magine.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> I agree with Remko, let's keep them unless they are in the way.
>>>>>>>>>>> We can remove all of them in Log4j 3.0.
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Sep 2, 2016 at 1:31 AM, Remko Popma <
>>>>>>>>>>> remko.popma@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> It was mentioned on a mailing list or twitter conversation with
>>>>>>>>>>>> maintainers of another Apache project that one of the reasons they hesitate
>>>>>>>>>>>> to migrate to Log4j is that they worry we will break binary compatibility.
>>>>>>>>>>>>
>>>>>>>>>>>> Removing the factory methods just because we deprecated them
>>>>>>>>>>>> seems a bit harsh.
>>>>>>>>>>>> It's not like it's a huge maintenance effort to keep them.
>>>>>>>>>>>>
>>>>>>>>>>>> I would not remove the deprecated factory methods unless they
>>>>>>>>>>>> actively prevent us from doing something we want to do.
>>>>>>>>>>>>
>>>>>>>>>>>> Remko
>>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>
>>>>>>>>>>>> On 2016/09/02, at 6:29, Ralph Goers <ra...@dslextreme.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Well, Java seems to have a policy of waiting at least 10 years,
>>>>>>>>>>>> if ever….
>>>>>>>>>>>>
>>>>>>>>>>>> Seriously, I don’t think 1 minor release is enough as that
>>>>>>>>>>>> might very well be the next release. I’d say 2 minor releases and at least
>>>>>>>>>>>> 6 months.
>>>>>>>>>>>>
>>>>>>>>>>>> Ralph
>>>>>>>>>>>>
>>>>>>>>>>>> On Sep 1, 2016, at 1:42 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> I think that when you add a builder and deprecate the factory,
>>>>>>>>>>>> you should remove it in the next 2.x release. Otherwise, deprecation has no
>>>>>>>>>>>> point if there's no version with the deprecation specified.
>>>>>>>>>>>>
>>>>>>>>>>>> On 1 September 2016 at 13:40, Gary Gregory <
>>>>>>>>>>>> garydgregory@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> When can we delete factory methods that are deprecated by
>>>>>>>>>>>>> builders?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Gary
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>>>>>>> <gg...@apache.org>
>>>>>>>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>>>>>>>> <http://www.manning.com/bauer3/>
>>>>>>>>>>>>> JUnit in Action, Second Edition
>>>>>>>>>>>>> <http://www.manning.com/tahchiev/>
>>>>>>>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>>>>>>> Home: http://garygregory.com/
>>>>>>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> [image: MagineTV]
>>>>>>>>>>>
>>>>>>>>>>> *Mikael Ståldal*
>>>>>>>>>>> Senior software developer
>>>>>>>>>>>
>>>>>>>>>>> *Magine TV*
>>>>>>>>>>> mikael.staldal@magine.com
>>>>>>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>>>>>>>>> <http://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.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>> <gg...@apache.org>
>>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>>> <http://www.manning.com/bauer3/>
>>>>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>> Home: http://garygregory.com/
>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>> <gg...@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
>>>> <gg...@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
>>> <gg...@apache.org>
>>> Java Persistence with Hibernate, Second Edition
>>> <http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> <gg...@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: Deprecated factory methods replaced by builders.
Posted by Ralph Goers <ra...@dslextreme.com>.
Everything is internal, but as I said previously, there are things where we do want to try to maintain compatibility - plugins being one of them. Also as I said, we really need to document where anyone making customizations is at risk and where they aren’t.
Ralph
> On Sep 7, 2016, at 9:22 PM, Gary Gregory <ga...@gmail.com> wrote:
>
> On Wed, Sep 7, 2016 at 9:17 PM, Remko Popma <remko.popma@gmail.com <ma...@gmail.com>> wrote:
> Okay.
> Shall we introduce an @Internal annotation?
>
> Please no, everything in Core is internal. I think we need to start with English sentences before we get caught up on details of how to communicate that to users.
>
> Gary
>
>
> Sent from my iPhone
>
> On 2016/09/08, at 12:52, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>
>> I agree that util packages are out of scope for BC. That's especially true in log4j-api where everything else has BC concerns.
>>
>> On 7 September 2016 at 21:14, Gary Gregory <garydgregory@gmail.com <ma...@gmail.com>> wrote:
>> I do not think NullOutputStream.NULL_OUTPUT_STREAM is a good example because the Core util package is or should out of bounds for BC. I thought we had "agreed" on that.
>>
>> Gary
>>
>> On Wed, Sep 7, 2016 at 5:29 PM, Remko Popma <remko.popma@gmail.com <ma...@gmail.com>> wrote:
>> We should make an effort not to break compatibility unless it's unavoidable. There is usually a way to accomplish things without breaking BC.
>>
>> This is doubly true for plugins but should be our policy in general.
>>
>> We should not make breaking changes for aesthetic reasons. For example, NullOutputStream.NULL_OUTPUT_STREAM would have been better named INSTANCE, but this is one thing I would not change at this stage.
>>
>> One of the reasons people (I think on the Spark mailing list) mentioned for putting off upgrading from Log4j 1.2 to Log4j 2 was worries we would make breaking changes.
>>
>>
>> Sent from my iPhone
>>
>> On 2016/09/08, at 8:03, Gary Gregory <garydgregory@gmail.com <ma...@gmail.com>> wrote:
>>
>>> On Wed, Sep 7, 2016 at 1:02 PM, Ralph Goers <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>>> We really need to document what we want to strive to maintain compatibility with in core. Basic components like Appenders and their managers, Filters, Layouts, & Lookups or pretty much any Plugin type would be at the top of my list.
>>>
>>> Bleh, then we need to mark methods in some @tag-way in Javadocs.
>>>
>>> Gary
>>>
>>> Ralph
>>>
>>>> On Sep 7, 2016, at 11:05 AM, Gary Gregory <garydgregory@gmail.com <ma...@gmail.com>> wrote:
>>>>
>>>> On Wed, Sep 7, 2016 at 11:41 AM, Remko Popma <remko.popma@gmail.com <ma...@gmail.com>> wrote:
>>>> We should do this before starting the 2.7 release.
>>>> If we are serious about being the replacement for Log4j 1.2 we should not break user code for no good reason.
>>>>
>>>> What does this have to do with 1.2?
>>>>
>>>> Gary
>>>>
>>>> On Wed, Sep 7, 2016 at 7:25 AM, Remko Popma <remko.popma@gmail.com <ma...@gmail.com>> wrote:
>>>> I think that would be good.
>>>>
>>>> Based on the number of Jira tickets being filed we are beginning to see increased uptake. Programmatic configuration is used surprisingly often. Leaving the factory methods in with some reasonable default for the missing parameters ensures existing users can smoothly upgrade.
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On 2016/09/07, at 3:03, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>>>>
>>>>> All the commits that removed deprecated factory methods it sounds like.
>>>>>
>>>>> On 6 September 2016 at 13:00, Gary Gregory <garydgregory@gmail.com <ma...@gmail.com>> wrote:
>>>>> On Tue, Sep 6, 2016 at 12:31 PM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>>>>> Should we revert those commits? There's still time.
>>>>>
>>>>> What commit? Do you mean to add back factory methods?
>>>>>
>>>>> Gary
>>>>>
>>>>>
>>>>> On 3 September 2016 at 01:12, Ralph Goers <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>>>>> Perhaps we shouldn’t have.
>>>>>
>>>>> Ralph
>>>>>
>>>>>> On Sep 2, 2016, at 7:46 PM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>>>>>>
>>>>>> We've already removed several deprecated factories in this upcoming release, though.
>>>>>>
>>>>>> On 2 September 2016 at 06:28, Mikael Ståldal <mikael.staldal@magine.com <ma...@magine.com>> wrote:
>>>>>> I agree with Remko, let's keep them unless they are in the way. We can remove all of them in Log4j 3.0.
>>>>>>
>>>>>> On Fri, Sep 2, 2016 at 1:31 AM, Remko Popma <remko.popma@gmail.com <ma...@gmail.com>> wrote:
>>>>>> It was mentioned on a mailing list or twitter conversation with maintainers of another Apache project that one of the reasons they hesitate to migrate to Log4j is that they worry we will break binary compatibility.
>>>>>>
>>>>>> Removing the factory methods just because we deprecated them seems a bit harsh.
>>>>>> It's not like it's a huge maintenance effort to keep them.
>>>>>>
>>>>>> I would not remove the deprecated factory methods unless they actively prevent us from doing something we want to do.
>>>>>>
>>>>>> Remko
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> On 2016/09/02, at 6:29, Ralph Goers <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>>>>>>
>>>>>>> Well, Java seems to have a policy of waiting at least 10 years, if ever….
>>>>>>>
>>>>>>> Seriously, I don’t think 1 minor release is enough as that might very well be the next release. I’d say 2 minor releases and at least 6 months.
>>>>>>>
>>>>>>> Ralph
>>>>>>>
>>>>>>>> On Sep 1, 2016, at 1:42 PM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>>>>>>>>
>>>>>>>> I think that when you add a builder and deprecate the factory, you should remove it in the next 2.x release. Otherwise, deprecation has no point if there's no version with the deprecation specified.
>>>>>>>>
>>>>>>>> On 1 September 2016 at 13:40, Gary Gregory <garydgregory@gmail.com <ma...@gmail.com>> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> When can we delete factory methods that are deprecated by builders?
>>>>>>>>
>>>>>>>> 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>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>>
>>>>>> Mikael Ståldal
>>>>>> Senior software developer
>>>>>>
>>>>>> Magine TV
>>>>>> mikael.staldal@magine.com <ma...@magine.com>
>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com <http://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.
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 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>
>>>
>>>
>>>
>>> --
>>> 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>
>>
>>
>> --
>> 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>
>>
>>
>> --
>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>
>
>
> --
> 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: Deprecated factory methods replaced by builders.
Posted by Gary Gregory <ga...@gmail.com>.
Note that I said "for removed code". Clirr will also complain about methods
added but I did not show that. Sadly, Clirr does not complain about methods
being added via a change in inheritance. Clirr is oooooooold...
Gary
On Thu, Sep 8, 2016 at 12:00 AM, Remko Popma <re...@gmail.com> wrote:
> Interesting, so Clirr does not detect the breaking change to
> TriggeringPolicy.
>
> Sent from my iPhone
>
> On 2016/09/08, at 13:32, Gary Gregory <ga...@gmail.com> wrote:
>
> FWIW, here is what Clirr finds for removed code:
>
> [ERROR] 7002: org.apache.logging.log4j.core.appender.ConsoleAppender$Builder:
> Method 'public org.apache.logging.log4j.core.appender.ConsoleAppender$Builder
> setFilter(org.apache.logging.log4j.core.Filter)' has been removed
> [ERROR] 7002: org.apache.logging.log4j.core.appender.ConsoleAppender$Builder:
> Method 'public org.apache.logging.log4j.core.appender.ConsoleAppender$Builder
> setIgnoreExceptions(boolean)' has been removed
> [ERROR] 7002: org.apache.logging.log4j.core.appender.ConsoleAppender$Builder:
> Method 'public org.apache.logging.log4j.core.appender.ConsoleAppender$Builder
> setLayout(org.apache.logging.log4j.core.Layout)' has been removed
> [ERROR] 7002: org.apache.logging.log4j.core.appender.ConsoleAppender$Builder:
> Method 'public org.apache.logging.log4j.core.appender.ConsoleAppender$Builder
> setName(java.lang.String)' has been removed
> [ERROR] 7002: org.apache.logging.log4j.core.appender.OutputStreamManager:
> Method 'protected void close()' has been removed
> [ERROR] 7002: org.apache.logging.log4j.core.appender.WriterManager:
> Method 'protected void close()' has been removed
> [ERROR] 8001: org.apache.logging.log4j.core.async.DaemonThreadFactory:
> Class org.apache.logging.log4j.core.async.DaemonThreadFactory removed
> [ERROR] 7002: org.apache.logging.log4j.core.config.LoggerConfig: Method
> 'public org.apache.logging.log4j.core.config.LoggerConfig
> createLogger(java.lang.String, org.apache.logging.log4j.Level,
> java.lang.String, java.lang.String, org.apache.logging.lo
> g4j.core.config.AppenderRef[], org.apache.logging.log4j.core.config.Property[],
> org.apache.logging.log4j.core.config.Configuration,
> org.apache.logging.log4j.core.Filter)' has been removed
> [ERROR] 7002: org.apache.logging.log4j.core.impl.ThrowableFormatOptions:
> Method 'public java.util.List getPackages()' has been removed
> [ERROR] 7002: org.apache.logging.log4j.core.net.TcpSocketManager: Method
> 'protected void close()' has been removed
> [ERROR] 7002: org.apache.logging.log4j.core.util.Assert: Method 'public
> java.lang.Object requireNonNull(java.lang.Object, java.lang.String)' has
> been removed
> [ERROR] 7002: org.apache.logging.log4j.core.util.Loader: Method 'public
> java.lang.Class loadClass(java.lang.String)' has been removed
>
> Gary
>
> On Wed, Sep 7, 2016 at 9:29 PM, Gary Gregory <ga...@gmail.com>
> wrote:
>
>> On Wed, Sep 7, 2016 at 9:26 PM, Matt Sicker <bo...@gmail.com> wrote:
>>
>>> This is actually why I suggested making an spi package long ago in core
>>> for public classes that would remain BC. Sadly, it's a little late for that
>>> now.
>>>
>>
>> It's never too late ;-)
>>
>> We could do that and call it 2.8 or surely for 3.0. BC for Core is not
>> 100% guaranteed, we just try to make life not too painful for SPI providers.
>>
>> Gary
>>
>>
>>>
>>> On 7 September 2016 at 23:22, Gary Gregory <ga...@gmail.com>
>>> wrote:
>>>
>>>> On Wed, Sep 7, 2016 at 9:17 PM, Remko Popma <re...@gmail.com>
>>>> wrote:
>>>>
>>>>> Okay.
>>>>> Shall we introduce an @Internal annotation?
>>>>>
>>>>
>>>> Please no, everything in Core is internal. I think we need to start
>>>> with English sentences before we get caught up on details of how to
>>>> communicate that to users.
>>>>
>>>> Gary
>>>>
>>>>
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On 2016/09/08, at 12:52, Matt Sicker <bo...@gmail.com> wrote:
>>>>>
>>>>> I agree that util packages are out of scope for BC. That's especially
>>>>> true in log4j-api where everything else has BC concerns.
>>>>>
>>>>> On 7 September 2016 at 21:14, Gary Gregory <ga...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> I do not think NullOutputStream.NULL_OUTPUT_STREAM is a good example
>>>>>> because the Core util package is or should out of bounds for BC. I thought
>>>>>> we had "agreed" on that.
>>>>>>
>>>>>> Gary
>>>>>>
>>>>>> On Wed, Sep 7, 2016 at 5:29 PM, Remko Popma <re...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> We should make an effort not to break compatibility unless it's
>>>>>>> unavoidable. There is usually a way to accomplish things without breaking
>>>>>>> BC.
>>>>>>>
>>>>>>> This is doubly true for plugins but should be our policy in general.
>>>>>>>
>>>>>>> We should not make breaking changes for aesthetic reasons. For
>>>>>>> example, NullOutputStream.NULL_OUTPUT_STREAM would have been better
>>>>>>> named INSTANCE, but this is one thing I would not change at this stage.
>>>>>>>
>>>>>>> One of the reasons people (I think on the Spark mailing list)
>>>>>>> mentioned for putting off upgrading from Log4j 1.2 to Log4j 2 was worries
>>>>>>> we would make breaking changes.
>>>>>>>
>>>>>>>
>>>>>>> Sent from my iPhone
>>>>>>>
>>>>>>> On 2016/09/08, at 8:03, Gary Gregory <ga...@gmail.com> wrote:
>>>>>>>
>>>>>>> On Wed, Sep 7, 2016 at 1:02 PM, Ralph Goers <
>>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>>
>>>>>>>> We really need to document what we want to strive to maintain
>>>>>>>> compatibility with in core. Basic components like Appenders and their
>>>>>>>> managers, Filters, Layouts, & Lookups or pretty much any Plugin type would
>>>>>>>> be at the top of my list.
>>>>>>>>
>>>>>>>
>>>>>>> Bleh, then we need to mark methods in some @tag-way in Javadocs.
>>>>>>>
>>>>>>> Gary
>>>>>>>
>>>>>>>>
>>>>>>>> Ralph
>>>>>>>>
>>>>>>>> On Sep 7, 2016, at 11:05 AM, Gary Gregory <ga...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> On Wed, Sep 7, 2016 at 11:41 AM, Remko Popma <remko.popma@gmail.com
>>>>>>>> > wrote:
>>>>>>>>
>>>>>>>>> We should do this before starting the 2.7 release.
>>>>>>>>> If we are serious about being the replacement for Log4j 1.2 we
>>>>>>>>> should not break user code for no good reason.
>>>>>>>>>
>>>>>>>>
>>>>>>>> What does this have to do with 1.2?
>>>>>>>>
>>>>>>>> Gary
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Sep 7, 2016 at 7:25 AM, Remko Popma <remko.popma@gmail.com
>>>>>>>>> > wrote:
>>>>>>>>>
>>>>>>>>>> I think that would be good.
>>>>>>>>>>
>>>>>>>>>> Based on the number of Jira tickets being filed we are beginning
>>>>>>>>>> to see increased uptake. Programmatic configuration is used surprisingly
>>>>>>>>>> often. Leaving the factory methods in with some reasonable default for the
>>>>>>>>>> missing parameters ensures existing users can smoothly upgrade.
>>>>>>>>>>
>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>
>>>>>>>>>> On 2016/09/07, at 3:03, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> All the commits that removed deprecated factory methods it sounds
>>>>>>>>>> like.
>>>>>>>>>>
>>>>>>>>>> On 6 September 2016 at 13:00, Gary Gregory <garydgregory@gmail.co
>>>>>>>>>> m> wrote:
>>>>>>>>>>
>>>>>>>>>>> On Tue, Sep 6, 2016 at 12:31 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Should we revert those commits? There's still time.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> What commit? Do you mean to add back factory methods?
>>>>>>>>>>>
>>>>>>>>>>> Gary
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 3 September 2016 at 01:12, Ralph Goers <
>>>>>>>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Perhaps we shouldn’t have.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Sep 2, 2016, at 7:46 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> We've already removed several deprecated factories in this
>>>>>>>>>>>>> upcoming release, though.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 2 September 2016 at 06:28, Mikael Ståldal <
>>>>>>>>>>>>> mikael.staldal@magine.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I agree with Remko, let's keep them unless they are in the
>>>>>>>>>>>>>> way. We can remove all of them in Log4j 3.0.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Fri, Sep 2, 2016 at 1:31 AM, Remko Popma <
>>>>>>>>>>>>>> remko.popma@gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It was mentioned on a mailing list or twitter conversation
>>>>>>>>>>>>>>> with maintainers of another Apache project that one of the reasons they
>>>>>>>>>>>>>>> hesitate to migrate to Log4j is that they worry we will break binary
>>>>>>>>>>>>>>> compatibility.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Removing the factory methods just because we deprecated
>>>>>>>>>>>>>>> them seems a bit harsh.
>>>>>>>>>>>>>>> It's not like it's a huge maintenance effort to keep them.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I would not remove the deprecated factory methods unless
>>>>>>>>>>>>>>> they actively prevent us from doing something we want to do.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Remko
>>>>>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 2016/09/02, at 6:29, Ralph Goers <
>>>>>>>>>>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Well, Java seems to have a policy of waiting at least 10
>>>>>>>>>>>>>>> years, if ever….
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Seriously, I don’t think 1 minor release is enough as that
>>>>>>>>>>>>>>> might very well be the next release. I’d say 2 minor releases and at least
>>>>>>>>>>>>>>> 6 months.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Sep 1, 2016, at 1:42 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I think that when you add a builder and deprecate the
>>>>>>>>>>>>>>> factory, you should remove it in the next 2.x release. Otherwise,
>>>>>>>>>>>>>>> deprecation has no point if there's no version with the deprecation
>>>>>>>>>>>>>>> specified.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 1 September 2016 at 13:40, Gary Gregory <
>>>>>>>>>>>>>>> garydgregory@gmail.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> When can we delete factory methods that are deprecated by
>>>>>>>>>>>>>>>> builders?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Gary
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>>>>>>>>>> <gg...@apache.org>
>>>>>>>>>>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>>>>>>>>>>> <http://www.manning.com/bauer3/>
>>>>>>>>>>>>>>>> JUnit in Action, Second Edition
>>>>>>>>>>>>>>>> <http://www.manning.com/tahchiev/>
>>>>>>>>>>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>>>>>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>>>>>>>>>> Home: http://garygregory.com/
>>>>>>>>>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> [image: MagineTV]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Mikael Ståldal*
>>>>>>>>>>>>>> Senior software developer
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Magine TV*
>>>>>>>>>>>>>> mikael.staldal@magine.com
>>>>>>>>>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden |
>>>>>>>>>>>>>> www.magine.com <http://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.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>>>>> <gg...@apache.org>
>>>>>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>>>>>> <http://www.manning.com/bauer3/>
>>>>>>>>>>> JUnit in Action, Second Edition
>>>>>>>>>>> <http://www.manning.com/tahchiev/>
>>>>>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>>>>> Home: http://garygregory.com/
>>>>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>> <gg...@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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker <bo...@gmail.com>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> 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
>>>>
>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>>
>>
>>
>>
>> --
>> 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
>
>
--
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: Deprecated factory methods replaced by builders.
Posted by Remko Popma <re...@gmail.com>.
Interesting, so Clirr does not detect the breaking change to TriggeringPolicy.
Sent from my iPhone
> On 2016/09/08, at 13:32, Gary Gregory <ga...@gmail.com> wrote:
>
> FWIW, here is what Clirr finds for removed code:
>
> [ERROR] 7002: org.apache.logging.log4j.core.appender.ConsoleAppender$Builder: Method 'public org.apache.logging.log4j.core.appender.ConsoleAppender$Builder setFilter(org.apache.logging.log4j.core.Filter)' has been removed
> [ERROR] 7002: org.apache.logging.log4j.core.appender.ConsoleAppender$Builder: Method 'public org.apache.logging.log4j.core.appender.ConsoleAppender$Builder setIgnoreExceptions(boolean)' has been removed
> [ERROR] 7002: org.apache.logging.log4j.core.appender.ConsoleAppender$Builder: Method 'public org.apache.logging.log4j.core.appender.ConsoleAppender$Builder setLayout(org.apache.logging.log4j.core.Layout)' has been removed
> [ERROR] 7002: org.apache.logging.log4j.core.appender.ConsoleAppender$Builder: Method 'public org.apache.logging.log4j.core.appender.ConsoleAppender$Builder setName(java.lang.String)' has been removed
> [ERROR] 7002: org.apache.logging.log4j.core.appender.OutputStreamManager: Method 'protected void close()' has been removed
> [ERROR] 7002: org.apache.logging.log4j.core.appender.WriterManager: Method 'protected void close()' has been removed
> [ERROR] 8001: org.apache.logging.log4j.core.async.DaemonThreadFactory: Class org.apache.logging.log4j.core.async.DaemonThreadFactory removed
> [ERROR] 7002: org.apache.logging.log4j.core.config.LoggerConfig: Method 'public org.apache.logging.log4j.core.config.LoggerConfig createLogger(java.lang.String, org.apache.logging.log4j.Level, java.lang.String, java.lang.String, org.apache.logging.lo
> g4j.core.config.AppenderRef[], org.apache.logging.log4j.core.config.Property[], org.apache.logging.log4j.core.config.Configuration, org.apache.logging.log4j.core.Filter)' has been removed
> [ERROR] 7002: org.apache.logging.log4j.core.impl.ThrowableFormatOptions: Method 'public java.util.List getPackages()' has been removed
> [ERROR] 7002: org.apache.logging.log4j.core.net.TcpSocketManager: Method 'protected void close()' has been removed
> [ERROR] 7002: org.apache.logging.log4j.core.util.Assert: Method 'public java.lang.Object requireNonNull(java.lang.Object, java.lang.String)' has been removed
> [ERROR] 7002: org.apache.logging.log4j.core.util.Loader: Method 'public java.lang.Class loadClass(java.lang.String)' has been removed
>
> Gary
>
>> On Wed, Sep 7, 2016 at 9:29 PM, Gary Gregory <ga...@gmail.com> wrote:
>>> On Wed, Sep 7, 2016 at 9:26 PM, Matt Sicker <bo...@gmail.com> wrote:
>>> This is actually why I suggested making an spi package long ago in core for public classes that would remain BC. Sadly, it's a little late for that now.
>>
>> It's never too late ;-)
>>
>> We could do that and call it 2.8 or surely for 3.0. BC for Core is not 100% guaranteed, we just try to make life not too painful for SPI providers.
>>
>> Gary
>>
>>>
>>>> On 7 September 2016 at 23:22, Gary Gregory <ga...@gmail.com> wrote:
>>>>> On Wed, Sep 7, 2016 at 9:17 PM, Remko Popma <re...@gmail.com> wrote:
>>>>> Okay.
>>>>> Shall we introduce an @Internal annotation?
>>>>
>>>> Please no, everything in Core is internal. I think we need to start with English sentences before we get caught up on details of how to communicate that to users.
>>>>
>>>> Gary
>>>>
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>>> On 2016/09/08, at 12:52, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>
>>>>>> I agree that util packages are out of scope for BC. That's especially true in log4j-api where everything else has BC concerns.
>>>>>>
>>>>>>> On 7 September 2016 at 21:14, Gary Gregory <ga...@gmail.com> wrote:
>>>>>>> I do not think NullOutputStream.NULL_OUTPUT_STREAM is a good example because the Core util package is or should out of bounds for BC. I thought we had "agreed" on that.
>>>>>>>
>>>>>>> Gary
>>>>>>>
>>>>>>>> On Wed, Sep 7, 2016 at 5:29 PM, Remko Popma <re...@gmail.com> wrote:
>>>>>>>> We should make an effort not to break compatibility unless it's unavoidable. There is usually a way to accomplish things without breaking BC.
>>>>>>>>
>>>>>>>> This is doubly true for plugins but should be our policy in general.
>>>>>>>>
>>>>>>>> We should not make breaking changes for aesthetic reasons. For example, NullOutputStream.NULL_OUTPUT_STREAM would have been better named INSTANCE, but this is one thing I would not change at this stage.
>>>>>>>>
>>>>>>>> One of the reasons people (I think on the Spark mailing list) mentioned for putting off upgrading from Log4j 1.2 to Log4j 2 was worries we would make breaking changes.
>>>>>>>>
>>>>>>>>
>>>>>>>> Sent from my iPhone
>>>>>>>>
>>>>>>>>> On 2016/09/08, at 8:03, Gary Gregory <ga...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> On Wed, Sep 7, 2016 at 1:02 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>>>>>>>>>> We really need to document what we want to strive to maintain compatibility with in core. Basic components like Appenders and their managers, Filters, Layouts, & Lookups or pretty much any Plugin type would be at the top of my list.
>>>>>>>>>
>>>>>>>>> Bleh, then we need to mark methods in some @tag-way in Javadocs.
>>>>>>>>>
>>>>>>>>> Gary
>>>>>>>>>>
>>>>>>>>>> Ralph
>>>>>>>>>>
>>>>>>>>>>> On Sep 7, 2016, at 11:05 AM, Gary Gregory <ga...@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Sep 7, 2016 at 11:41 AM, Remko Popma <re...@gmail.com> wrote:
>>>>>>>>>>>> We should do this before starting the 2.7 release.
>>>>>>>>>>>> If we are serious about being the replacement for Log4j 1.2 we should not break user code for no good reason.
>>>>>>>>>>>
>>>>>>>>>>> What does this have to do with 1.2?
>>>>>>>>>>>
>>>>>>>>>>> Gary
>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, Sep 7, 2016 at 7:25 AM, Remko Popma <re...@gmail.com> wrote:
>>>>>>>>>>>>> I think that would be good.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Based on the number of Jira tickets being filed we are beginning to see increased uptake. Programmatic configuration is used surprisingly often. Leaving the factory methods in with some reasonable default for the missing parameters ensures existing users can smoothly upgrade.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 2016/09/07, at 3:03, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> All the commits that removed deprecated factory methods it sounds like.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 6 September 2016 at 13:00, Gary Gregory <ga...@gmail.com> wrote:
>>>>>>>>>>>>>>>> On Tue, Sep 6, 2016 at 12:31 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>>>>>>> Should we revert those commits? There's still time.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> What commit? Do you mean to add back factory methods?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Gary
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 3 September 2016 at 01:12, Ralph Goers <ra...@dslextreme.com> wrote:
>>>>>>>>>>>>>>>>> Perhaps we shouldn’t have.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Sep 2, 2016, at 7:46 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> We've already removed several deprecated factories in this upcoming release, though.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 2 September 2016 at 06:28, Mikael Ståldal <mi...@magine.com> wrote:
>>>>>>>>>>>>>>>>>>> I agree with Remko, let's keep them unless they are in the way. We can remove all of them in Log4j 3.0.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Fri, Sep 2, 2016 at 1:31 AM, Remko Popma <re...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>> It was mentioned on a mailing list or twitter conversation with maintainers of another Apache project that one of the reasons they hesitate to migrate to Log4j is that they worry we will break binary compatibility.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Removing the factory methods just because we deprecated them seems a bit harsh.
>>>>>>>>>>>>>>>>>>>> It's not like it's a huge maintenance effort to keep them.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I would not remove the deprecated factory methods unless they actively prevent us from doing something we want to do.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Remko
>>>>>>>>>>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 2016/09/02, at 6:29, Ralph Goers <ra...@dslextreme.com> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Well, Java seems to have a policy of waiting at least 10 years, if ever….
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Seriously, I don’t think 1 minor release is enough as that might very well be the next release. I’d say 2 minor releases and at least 6 months.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On Sep 1, 2016, at 1:42 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I think that when you add a builder and deprecate the factory, you should remove it in the next 2.x release. Otherwise, deprecation has no point if there's no version with the deprecation specified.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 1 September 2016 at 13:40, Gary Gregory <ga...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> When can we delete factory methods that are deprecated by builders?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Mikael Ståldal
>>>>>>>>>>>>>>>>>>> Senior software developer
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Magine TV
>>>>>>>>>>>>>>>>>>> mikael.staldal@magine.com
>>>>>>>>>>>>>>>>>>> Grev Turegatan 3 | 114 46 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.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Matt Sicker <bo...@gmail.com>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 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
>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>
>>
>>
>>
>> --
>> 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: Deprecated factory methods replaced by builders.
Posted by Gary Gregory <ga...@gmail.com>.
mvn clirr:check
Please see http://www.mojohaus.org/clirr-maven-plugin/
Gary
On Mon, Sep 12, 2016 at 4:01 PM, Remko Popma <re...@gmail.com> wrote:
> How do I run clirr? I would like to ensure the breaking changes are
> reverted. If we have to redo a release because of this it would be wasting
> the release manager's time.
>
> On Thu, Sep 8, 2016 at 1:32 PM, Gary Gregory <ga...@gmail.com>
> wrote:
>
>> FWIW, here is what Clirr finds for removed code:
>>
>> [ERROR] 7002: org.apache.logging.log4j.core.
>> appender.ConsoleAppender$Builder: Method 'public
>> org.apache.logging.log4j.core.appender.ConsoleAppender$Builder
>> setFilter(org.apache.logging.log4j.core.Filter)' has been removed
>> [ERROR] 7002: org.apache.logging.log4j.core.
>> appender.ConsoleAppender$Builder: Method 'public
>> org.apache.logging.log4j.core.appender.ConsoleAppender$Builder
>> setIgnoreExceptions(boolean)' has been removed
>> [ERROR] 7002: org.apache.logging.log4j.core.
>> appender.ConsoleAppender$Builder: Method 'public
>> org.apache.logging.log4j.core.appender.ConsoleAppender$Builder
>> setLayout(org.apache.logging.log4j.core.Layout)' has been removed
>> [ERROR] 7002: org.apache.logging.log4j.core.
>> appender.ConsoleAppender$Builder: Method 'public
>> org.apache.logging.log4j.core.appender.ConsoleAppender$Builder
>> setName(java.lang.String)' has been removed
>> [ERROR] 7002: org.apache.logging.log4j.core.appender.OutputStreamManager:
>> Method 'protected void close()' has been removed
>> [ERROR] 7002: org.apache.logging.log4j.core.appender.WriterManager:
>> Method 'protected void close()' has been removed
>> [ERROR] 8001: org.apache.logging.log4j.core.async.DaemonThreadFactory:
>> Class org.apache.logging.log4j.core.async.DaemonThreadFactory removed
>> [ERROR] 7002: org.apache.logging.log4j.core.config.LoggerConfig: Method
>> 'public org.apache.logging.log4j.core.config.LoggerConfig
>> createLogger(java.lang.String, org.apache.logging.log4j.Level,
>> java.lang.String, java.lang.String, org.apache.logging.lo
>> g4j.core.config.AppenderRef[], org.apache.logging.log4j.core.config.Property[],
>> org.apache.logging.log4j.core.config.Configuration,
>> org.apache.logging.log4j.core.Filter)' has been removed
>> [ERROR] 7002: org.apache.logging.log4j.core.impl.ThrowableFormatOptions:
>> Method 'public java.util.List getPackages()' has been removed
>> [ERROR] 7002: org.apache.logging.log4j.core.net.TcpSocketManager: Method
>> 'protected void close()' has been removed
>> [ERROR] 7002: org.apache.logging.log4j.core.util.Assert: Method 'public
>> java.lang.Object requireNonNull(java.lang.Object, java.lang.String)' has
>> been removed
>> [ERROR] 7002: org.apache.logging.log4j.core.util.Loader: Method 'public
>> java.lang.Class loadClass(java.lang.String)' has been removed
>>
>> Gary
>>
>> On Wed, Sep 7, 2016 at 9:29 PM, Gary Gregory <ga...@gmail.com>
>> wrote:
>>
>>> On Wed, Sep 7, 2016 at 9:26 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>
>>>> This is actually why I suggested making an spi package long ago in core
>>>> for public classes that would remain BC. Sadly, it's a little late for that
>>>> now.
>>>>
>>>
>>> It's never too late ;-)
>>>
>>> We could do that and call it 2.8 or surely for 3.0. BC for Core is not
>>> 100% guaranteed, we just try to make life not too painful for SPI providers.
>>>
>>> Gary
>>>
>>>
>>>>
>>>> On 7 September 2016 at 23:22, Gary Gregory <ga...@gmail.com>
>>>> wrote:
>>>>
>>>>> On Wed, Sep 7, 2016 at 9:17 PM, Remko Popma <re...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Okay.
>>>>>> Shall we introduce an @Internal annotation?
>>>>>>
>>>>>
>>>>> Please no, everything in Core is internal. I think we need to start
>>>>> with English sentences before we get caught up on details of how to
>>>>> communicate that to users.
>>>>>
>>>>> Gary
>>>>>
>>>>>
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> On 2016/09/08, at 12:52, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>
>>>>>> I agree that util packages are out of scope for BC. That's especially
>>>>>> true in log4j-api where everything else has BC concerns.
>>>>>>
>>>>>> On 7 September 2016 at 21:14, Gary Gregory <ga...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I do not think NullOutputStream.NULL_OUTPUT_STREAM is a good
>>>>>>> example because the Core util package is or should out of bounds for BC. I
>>>>>>> thought we had "agreed" on that.
>>>>>>>
>>>>>>> Gary
>>>>>>>
>>>>>>> On Wed, Sep 7, 2016 at 5:29 PM, Remko Popma <re...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> We should make an effort not to break compatibility unless it's
>>>>>>>> unavoidable. There is usually a way to accomplish things without breaking
>>>>>>>> BC.
>>>>>>>>
>>>>>>>> This is doubly true for plugins but should be our policy in
>>>>>>>> general.
>>>>>>>>
>>>>>>>> We should not make breaking changes for aesthetic reasons. For
>>>>>>>> example, NullOutputStream.NULL_OUTPUT_STREAM would have been
>>>>>>>> better named INSTANCE, but this is one thing I would not change at this
>>>>>>>> stage.
>>>>>>>>
>>>>>>>> One of the reasons people (I think on the Spark mailing list)
>>>>>>>> mentioned for putting off upgrading from Log4j 1.2 to Log4j 2 was worries
>>>>>>>> we would make breaking changes.
>>>>>>>>
>>>>>>>>
>>>>>>>> Sent from my iPhone
>>>>>>>>
>>>>>>>> On 2016/09/08, at 8:03, Gary Gregory <ga...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> On Wed, Sep 7, 2016 at 1:02 PM, Ralph Goers <
>>>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>>>
>>>>>>>>> We really need to document what we want to strive to maintain
>>>>>>>>> compatibility with in core. Basic components like Appenders and their
>>>>>>>>> managers, Filters, Layouts, & Lookups or pretty much any Plugin type would
>>>>>>>>> be at the top of my list.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Bleh, then we need to mark methods in some @tag-way in Javadocs.
>>>>>>>>
>>>>>>>> Gary
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Ralph
>>>>>>>>>
>>>>>>>>> On Sep 7, 2016, at 11:05 AM, Gary Gregory <ga...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> On Wed, Sep 7, 2016 at 11:41 AM, Remko Popma <
>>>>>>>>> remko.popma@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> We should do this before starting the 2.7 release.
>>>>>>>>>> If we are serious about being the replacement for Log4j 1.2 we
>>>>>>>>>> should not break user code for no good reason.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> What does this have to do with 1.2?
>>>>>>>>>
>>>>>>>>> Gary
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, Sep 7, 2016 at 7:25 AM, Remko Popma <
>>>>>>>>>> remko.popma@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> I think that would be good.
>>>>>>>>>>>
>>>>>>>>>>> Based on the number of Jira tickets being filed we are beginning
>>>>>>>>>>> to see increased uptake. Programmatic configuration is used surprisingly
>>>>>>>>>>> often. Leaving the factory methods in with some reasonable default for the
>>>>>>>>>>> missing parameters ensures existing users can smoothly upgrade.
>>>>>>>>>>>
>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>
>>>>>>>>>>> On 2016/09/07, at 3:03, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> All the commits that removed deprecated factory methods it
>>>>>>>>>>> sounds like.
>>>>>>>>>>>
>>>>>>>>>>> On 6 September 2016 at 13:00, Gary Gregory <
>>>>>>>>>>> garydgregory@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Sep 6, 2016 at 12:31 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Should we revert those commits? There's still time.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> What commit? Do you mean to add back factory methods?
>>>>>>>>>>>>
>>>>>>>>>>>> Gary
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 3 September 2016 at 01:12, Ralph Goers <
>>>>>>>>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Perhaps we shouldn’t have.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Sep 2, 2016, at 7:46 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> We've already removed several deprecated factories in this
>>>>>>>>>>>>>> upcoming release, though.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 2 September 2016 at 06:28, Mikael Ståldal <
>>>>>>>>>>>>>> mikael.staldal@magine.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I agree with Remko, let's keep them unless they are in the
>>>>>>>>>>>>>>> way. We can remove all of them in Log4j 3.0.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Fri, Sep 2, 2016 at 1:31 AM, Remko Popma <
>>>>>>>>>>>>>>> remko.popma@gmail.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It was mentioned on a mailing list or twitter conversation
>>>>>>>>>>>>>>>> with maintainers of another Apache project that one of the reasons they
>>>>>>>>>>>>>>>> hesitate to migrate to Log4j is that they worry we will break binary
>>>>>>>>>>>>>>>> compatibility.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Removing the factory methods just because we deprecated
>>>>>>>>>>>>>>>> them seems a bit harsh.
>>>>>>>>>>>>>>>> It's not like it's a huge maintenance effort to keep them.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I would not remove the deprecated factory methods unless
>>>>>>>>>>>>>>>> they actively prevent us from doing something we want to do.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Remko
>>>>>>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 2016/09/02, at 6:29, Ralph Goers <
>>>>>>>>>>>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Well, Java seems to have a policy of waiting at least 10
>>>>>>>>>>>>>>>> years, if ever….
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Seriously, I don’t think 1 minor release is enough as that
>>>>>>>>>>>>>>>> might very well be the next release. I’d say 2 minor releases and at least
>>>>>>>>>>>>>>>> 6 months.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Sep 1, 2016, at 1:42 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I think that when you add a builder and deprecate the
>>>>>>>>>>>>>>>> factory, you should remove it in the next 2.x release. Otherwise,
>>>>>>>>>>>>>>>> deprecation has no point if there's no version with the deprecation
>>>>>>>>>>>>>>>> specified.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 1 September 2016 at 13:40, Gary Gregory <
>>>>>>>>>>>>>>>> garydgregory@gmail.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> When can we delete factory methods that are deprecated by
>>>>>>>>>>>>>>>>> builders?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Gary
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>>>>>>>>>>> <gg...@apache.org>
>>>>>>>>>>>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>>>>>>>>>>>> <http://www.manning.com/bauer3/>
>>>>>>>>>>>>>>>>> JUnit in Action, Second Edition
>>>>>>>>>>>>>>>>> <http://www.manning.com/tahchiev/>
>>>>>>>>>>>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>>>>>>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>>>>>>>>>>> Home: http://garygregory.com/
>>>>>>>>>>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> [image: MagineTV]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *Mikael Ståldal*
>>>>>>>>>>>>>>> Senior software developer
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *Magine TV*
>>>>>>>>>>>>>>> mikael.staldal@magine.com
>>>>>>>>>>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden |
>>>>>>>>>>>>>>> www.magine.com <http://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.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>>>>>> <gg...@apache.org>
>>>>>>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>>>>>>> <http://www.manning.com/bauer3/>
>>>>>>>>>>>> JUnit in Action, Second Edition
>>>>>>>>>>>> <http://www.manning.com/tahchiev/>
>>>>>>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>>>>>> Home: http://garygregory.com/
>>>>>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>>> <gg...@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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> 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
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <bo...@gmail.com>
>>>>
>>>
>>>
>>>
>>> --
>>> 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
>>
>
>
--
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: Deprecated factory methods replaced by builders.
Posted by Remko Popma <re...@gmail.com>.
How do I run clirr? I would like to ensure the breaking changes are
reverted. If we have to redo a release because of this it would be wasting
the release manager's time.
On Thu, Sep 8, 2016 at 1:32 PM, Gary Gregory <ga...@gmail.com> wrote:
> FWIW, here is what Clirr finds for removed code:
>
> [ERROR] 7002: org.apache.logging.log4j.core.appender.ConsoleAppender$Builder:
> Method 'public org.apache.logging.log4j.core.appender.ConsoleAppender$Builder
> setFilter(org.apache.logging.log4j.core.Filter)' has been removed
> [ERROR] 7002: org.apache.logging.log4j.core.appender.ConsoleAppender$Builder:
> Method 'public org.apache.logging.log4j.core.appender.ConsoleAppender$Builder
> setIgnoreExceptions(boolean)' has been removed
> [ERROR] 7002: org.apache.logging.log4j.core.appender.ConsoleAppender$Builder:
> Method 'public org.apache.logging.log4j.core.appender.ConsoleAppender$Builder
> setLayout(org.apache.logging.log4j.core.Layout)' has been removed
> [ERROR] 7002: org.apache.logging.log4j.core.appender.ConsoleAppender$Builder:
> Method 'public org.apache.logging.log4j.core.appender.ConsoleAppender$Builder
> setName(java.lang.String)' has been removed
> [ERROR] 7002: org.apache.logging.log4j.core.appender.OutputStreamManager:
> Method 'protected void close()' has been removed
> [ERROR] 7002: org.apache.logging.log4j.core.appender.WriterManager:
> Method 'protected void close()' has been removed
> [ERROR] 8001: org.apache.logging.log4j.core.async.DaemonThreadFactory:
> Class org.apache.logging.log4j.core.async.DaemonThreadFactory removed
> [ERROR] 7002: org.apache.logging.log4j.core.config.LoggerConfig: Method
> 'public org.apache.logging.log4j.core.config.LoggerConfig
> createLogger(java.lang.String, org.apache.logging.log4j.Level,
> java.lang.String, java.lang.String, org.apache.logging.lo
> g4j.core.config.AppenderRef[], org.apache.logging.log4j.core.config.Property[],
> org.apache.logging.log4j.core.config.Configuration,
> org.apache.logging.log4j.core.Filter)' has been removed
> [ERROR] 7002: org.apache.logging.log4j.core.impl.ThrowableFormatOptions:
> Method 'public java.util.List getPackages()' has been removed
> [ERROR] 7002: org.apache.logging.log4j.core.net.TcpSocketManager: Method
> 'protected void close()' has been removed
> [ERROR] 7002: org.apache.logging.log4j.core.util.Assert: Method 'public
> java.lang.Object requireNonNull(java.lang.Object, java.lang.String)' has
> been removed
> [ERROR] 7002: org.apache.logging.log4j.core.util.Loader: Method 'public
> java.lang.Class loadClass(java.lang.String)' has been removed
>
> Gary
>
> On Wed, Sep 7, 2016 at 9:29 PM, Gary Gregory <ga...@gmail.com>
> wrote:
>
>> On Wed, Sep 7, 2016 at 9:26 PM, Matt Sicker <bo...@gmail.com> wrote:
>>
>>> This is actually why I suggested making an spi package long ago in core
>>> for public classes that would remain BC. Sadly, it's a little late for that
>>> now.
>>>
>>
>> It's never too late ;-)
>>
>> We could do that and call it 2.8 or surely for 3.0. BC for Core is not
>> 100% guaranteed, we just try to make life not too painful for SPI providers.
>>
>> Gary
>>
>>
>>>
>>> On 7 September 2016 at 23:22, Gary Gregory <ga...@gmail.com>
>>> wrote:
>>>
>>>> On Wed, Sep 7, 2016 at 9:17 PM, Remko Popma <re...@gmail.com>
>>>> wrote:
>>>>
>>>>> Okay.
>>>>> Shall we introduce an @Internal annotation?
>>>>>
>>>>
>>>> Please no, everything in Core is internal. I think we need to start
>>>> with English sentences before we get caught up on details of how to
>>>> communicate that to users.
>>>>
>>>> Gary
>>>>
>>>>
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On 2016/09/08, at 12:52, Matt Sicker <bo...@gmail.com> wrote:
>>>>>
>>>>> I agree that util packages are out of scope for BC. That's especially
>>>>> true in log4j-api where everything else has BC concerns.
>>>>>
>>>>> On 7 September 2016 at 21:14, Gary Gregory <ga...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> I do not think NullOutputStream.NULL_OUTPUT_STREAM is a good example
>>>>>> because the Core util package is or should out of bounds for BC. I thought
>>>>>> we had "agreed" on that.
>>>>>>
>>>>>> Gary
>>>>>>
>>>>>> On Wed, Sep 7, 2016 at 5:29 PM, Remko Popma <re...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> We should make an effort not to break compatibility unless it's
>>>>>>> unavoidable. There is usually a way to accomplish things without breaking
>>>>>>> BC.
>>>>>>>
>>>>>>> This is doubly true for plugins but should be our policy in general.
>>>>>>>
>>>>>>> We should not make breaking changes for aesthetic reasons. For
>>>>>>> example, NullOutputStream.NULL_OUTPUT_STREAM would have been better
>>>>>>> named INSTANCE, but this is one thing I would not change at this stage.
>>>>>>>
>>>>>>> One of the reasons people (I think on the Spark mailing list)
>>>>>>> mentioned for putting off upgrading from Log4j 1.2 to Log4j 2 was worries
>>>>>>> we would make breaking changes.
>>>>>>>
>>>>>>>
>>>>>>> Sent from my iPhone
>>>>>>>
>>>>>>> On 2016/09/08, at 8:03, Gary Gregory <ga...@gmail.com> wrote:
>>>>>>>
>>>>>>> On Wed, Sep 7, 2016 at 1:02 PM, Ralph Goers <
>>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>>
>>>>>>>> We really need to document what we want to strive to maintain
>>>>>>>> compatibility with in core. Basic components like Appenders and their
>>>>>>>> managers, Filters, Layouts, & Lookups or pretty much any Plugin type would
>>>>>>>> be at the top of my list.
>>>>>>>>
>>>>>>>
>>>>>>> Bleh, then we need to mark methods in some @tag-way in Javadocs.
>>>>>>>
>>>>>>> Gary
>>>>>>>
>>>>>>>>
>>>>>>>> Ralph
>>>>>>>>
>>>>>>>> On Sep 7, 2016, at 11:05 AM, Gary Gregory <ga...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> On Wed, Sep 7, 2016 at 11:41 AM, Remko Popma <remko.popma@gmail.com
>>>>>>>> > wrote:
>>>>>>>>
>>>>>>>>> We should do this before starting the 2.7 release.
>>>>>>>>> If we are serious about being the replacement for Log4j 1.2 we
>>>>>>>>> should not break user code for no good reason.
>>>>>>>>>
>>>>>>>>
>>>>>>>> What does this have to do with 1.2?
>>>>>>>>
>>>>>>>> Gary
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Sep 7, 2016 at 7:25 AM, Remko Popma <remko.popma@gmail.com
>>>>>>>>> > wrote:
>>>>>>>>>
>>>>>>>>>> I think that would be good.
>>>>>>>>>>
>>>>>>>>>> Based on the number of Jira tickets being filed we are beginning
>>>>>>>>>> to see increased uptake. Programmatic configuration is used surprisingly
>>>>>>>>>> often. Leaving the factory methods in with some reasonable default for the
>>>>>>>>>> missing parameters ensures existing users can smoothly upgrade.
>>>>>>>>>>
>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>
>>>>>>>>>> On 2016/09/07, at 3:03, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> All the commits that removed deprecated factory methods it sounds
>>>>>>>>>> like.
>>>>>>>>>>
>>>>>>>>>> On 6 September 2016 at 13:00, Gary Gregory <garydgregory@gmail.co
>>>>>>>>>> m> wrote:
>>>>>>>>>>
>>>>>>>>>>> On Tue, Sep 6, 2016 at 12:31 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Should we revert those commits? There's still time.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> What commit? Do you mean to add back factory methods?
>>>>>>>>>>>
>>>>>>>>>>> Gary
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 3 September 2016 at 01:12, Ralph Goers <
>>>>>>>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Perhaps we shouldn’t have.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Sep 2, 2016, at 7:46 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> We've already removed several deprecated factories in this
>>>>>>>>>>>>> upcoming release, though.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 2 September 2016 at 06:28, Mikael Ståldal <
>>>>>>>>>>>>> mikael.staldal@magine.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I agree with Remko, let's keep them unless they are in the
>>>>>>>>>>>>>> way. We can remove all of them in Log4j 3.0.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Fri, Sep 2, 2016 at 1:31 AM, Remko Popma <
>>>>>>>>>>>>>> remko.popma@gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It was mentioned on a mailing list or twitter conversation
>>>>>>>>>>>>>>> with maintainers of another Apache project that one of the reasons they
>>>>>>>>>>>>>>> hesitate to migrate to Log4j is that they worry we will break binary
>>>>>>>>>>>>>>> compatibility.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Removing the factory methods just because we deprecated
>>>>>>>>>>>>>>> them seems a bit harsh.
>>>>>>>>>>>>>>> It's not like it's a huge maintenance effort to keep them.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I would not remove the deprecated factory methods unless
>>>>>>>>>>>>>>> they actively prevent us from doing something we want to do.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Remko
>>>>>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 2016/09/02, at 6:29, Ralph Goers <
>>>>>>>>>>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Well, Java seems to have a policy of waiting at least 10
>>>>>>>>>>>>>>> years, if ever….
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Seriously, I don’t think 1 minor release is enough as that
>>>>>>>>>>>>>>> might very well be the next release. I’d say 2 minor releases and at least
>>>>>>>>>>>>>>> 6 months.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Sep 1, 2016, at 1:42 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I think that when you add a builder and deprecate the
>>>>>>>>>>>>>>> factory, you should remove it in the next 2.x release. Otherwise,
>>>>>>>>>>>>>>> deprecation has no point if there's no version with the deprecation
>>>>>>>>>>>>>>> specified.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 1 September 2016 at 13:40, Gary Gregory <
>>>>>>>>>>>>>>> garydgregory@gmail.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> When can we delete factory methods that are deprecated by
>>>>>>>>>>>>>>>> builders?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Gary
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>>>>>>>>>> <gg...@apache.org>
>>>>>>>>>>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>>>>>>>>>>> <http://www.manning.com/bauer3/>
>>>>>>>>>>>>>>>> JUnit in Action, Second Edition
>>>>>>>>>>>>>>>> <http://www.manning.com/tahchiev/>
>>>>>>>>>>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>>>>>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>>>>>>>>>> Home: http://garygregory.com/
>>>>>>>>>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> [image: MagineTV]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Mikael Ståldal*
>>>>>>>>>>>>>> Senior software developer
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Magine TV*
>>>>>>>>>>>>>> mikael.staldal@magine.com
>>>>>>>>>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden |
>>>>>>>>>>>>>> www.magine.com <http://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.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>>>>> <gg...@apache.org>
>>>>>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>>>>>> <http://www.manning.com/bauer3/>
>>>>>>>>>>> JUnit in Action, Second Edition
>>>>>>>>>>> <http://www.manning.com/tahchiev/>
>>>>>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>>>>> Home: http://garygregory.com/
>>>>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>> <gg...@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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker <bo...@gmail.com>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> 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
>>>>
>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>>
>>
>>
>>
>> --
>> 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: Deprecated factory methods replaced by builders.
Posted by Gary Gregory <ga...@gmail.com>.
FWIW, here is what Clirr finds for removed code:
[ERROR] 7002:
org.apache.logging.log4j.core.appender.ConsoleAppender$Builder: Method
'public org.apache.logging.log4j.core.appender.ConsoleAppender$Builder
setFilter(org.apache.logging.log4j.core.Filter)' has been removed
[ERROR] 7002:
org.apache.logging.log4j.core.appender.ConsoleAppender$Builder: Method
'public org.apache.logging.log4j.core.appender.ConsoleAppender$Builder
setIgnoreExceptions(boolean)' has been removed
[ERROR] 7002:
org.apache.logging.log4j.core.appender.ConsoleAppender$Builder: Method
'public org.apache.logging.log4j.core.appender.ConsoleAppender$Builder
setLayout(org.apache.logging.log4j.core.Layout)' has been removed
[ERROR] 7002:
org.apache.logging.log4j.core.appender.ConsoleAppender$Builder: Method
'public org.apache.logging.log4j.core.appender.ConsoleAppender$Builder
setName(java.lang.String)' has been removed
[ERROR] 7002: org.apache.logging.log4j.core.appender.OutputStreamManager:
Method 'protected void close()' has been removed
[ERROR] 7002: org.apache.logging.log4j.core.appender.WriterManager: Method
'protected void close()' has been removed
[ERROR] 8001: org.apache.logging.log4j.core.async.DaemonThreadFactory:
Class org.apache.logging.log4j.core.async.DaemonThreadFactory removed
[ERROR] 7002: org.apache.logging.log4j.core.config.LoggerConfig: Method
'public org.apache.logging.log4j.core.config.LoggerConfig
createLogger(java.lang.String, org.apache.logging.log4j.Level,
java.lang.String, java.lang.String, org.apache.logging.lo
g4j.core.config.AppenderRef[],
org.apache.logging.log4j.core.config.Property[],
org.apache.logging.log4j.core.config.Configuration,
org.apache.logging.log4j.core.Filter)' has been removed
[ERROR] 7002: org.apache.logging.log4j.core.impl.ThrowableFormatOptions:
Method 'public java.util.List getPackages()' has been removed
[ERROR] 7002: org.apache.logging.log4j.core.net.TcpSocketManager: Method
'protected void close()' has been removed
[ERROR] 7002: org.apache.logging.log4j.core.util.Assert: Method 'public
java.lang.Object requireNonNull(java.lang.Object, java.lang.String)' has
been removed
[ERROR] 7002: org.apache.logging.log4j.core.util.Loader: Method 'public
java.lang.Class loadClass(java.lang.String)' has been removed
Gary
On Wed, Sep 7, 2016 at 9:29 PM, Gary Gregory <ga...@gmail.com> wrote:
> On Wed, Sep 7, 2016 at 9:26 PM, Matt Sicker <bo...@gmail.com> wrote:
>
>> This is actually why I suggested making an spi package long ago in core
>> for public classes that would remain BC. Sadly, it's a little late for that
>> now.
>>
>
> It's never too late ;-)
>
> We could do that and call it 2.8 or surely for 3.0. BC for Core is not
> 100% guaranteed, we just try to make life not too painful for SPI providers.
>
> Gary
>
>
>>
>> On 7 September 2016 at 23:22, Gary Gregory <ga...@gmail.com>
>> wrote:
>>
>>> On Wed, Sep 7, 2016 at 9:17 PM, Remko Popma <re...@gmail.com>
>>> wrote:
>>>
>>>> Okay.
>>>> Shall we introduce an @Internal annotation?
>>>>
>>>
>>> Please no, everything in Core is internal. I think we need to start with
>>> English sentences before we get caught up on details of how to communicate
>>> that to users.
>>>
>>> Gary
>>>
>>>
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On 2016/09/08, at 12:52, Matt Sicker <bo...@gmail.com> wrote:
>>>>
>>>> I agree that util packages are out of scope for BC. That's especially
>>>> true in log4j-api where everything else has BC concerns.
>>>>
>>>> On 7 September 2016 at 21:14, Gary Gregory <ga...@gmail.com>
>>>> wrote:
>>>>
>>>>> I do not think NullOutputStream.NULL_OUTPUT_STREAM is a good example
>>>>> because the Core util package is or should out of bounds for BC. I thought
>>>>> we had "agreed" on that.
>>>>>
>>>>> Gary
>>>>>
>>>>> On Wed, Sep 7, 2016 at 5:29 PM, Remko Popma <re...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> We should make an effort not to break compatibility unless it's
>>>>>> unavoidable. There is usually a way to accomplish things without breaking
>>>>>> BC.
>>>>>>
>>>>>> This is doubly true for plugins but should be our policy in general.
>>>>>>
>>>>>> We should not make breaking changes for aesthetic reasons. For
>>>>>> example, NullOutputStream.NULL_OUTPUT_STREAM would have been better
>>>>>> named INSTANCE, but this is one thing I would not change at this stage.
>>>>>>
>>>>>> One of the reasons people (I think on the Spark mailing list)
>>>>>> mentioned for putting off upgrading from Log4j 1.2 to Log4j 2 was worries
>>>>>> we would make breaking changes.
>>>>>>
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> On 2016/09/08, at 8:03, Gary Gregory <ga...@gmail.com> wrote:
>>>>>>
>>>>>> On Wed, Sep 7, 2016 at 1:02 PM, Ralph Goers <
>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>
>>>>>>> We really need to document what we want to strive to maintain
>>>>>>> compatibility with in core. Basic components like Appenders and their
>>>>>>> managers, Filters, Layouts, & Lookups or pretty much any Plugin type would
>>>>>>> be at the top of my list.
>>>>>>>
>>>>>>
>>>>>> Bleh, then we need to mark methods in some @tag-way in Javadocs.
>>>>>>
>>>>>> Gary
>>>>>>
>>>>>>>
>>>>>>> Ralph
>>>>>>>
>>>>>>> On Sep 7, 2016, at 11:05 AM, Gary Gregory <ga...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> On Wed, Sep 7, 2016 at 11:41 AM, Remko Popma <re...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> We should do this before starting the 2.7 release.
>>>>>>>> If we are serious about being the replacement for Log4j 1.2 we
>>>>>>>> should not break user code for no good reason.
>>>>>>>>
>>>>>>>
>>>>>>> What does this have to do with 1.2?
>>>>>>>
>>>>>>> Gary
>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Sep 7, 2016 at 7:25 AM, Remko Popma <re...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> I think that would be good.
>>>>>>>>>
>>>>>>>>> Based on the number of Jira tickets being filed we are beginning
>>>>>>>>> to see increased uptake. Programmatic configuration is used surprisingly
>>>>>>>>> often. Leaving the factory methods in with some reasonable default for the
>>>>>>>>> missing parameters ensures existing users can smoothly upgrade.
>>>>>>>>>
>>>>>>>>> Sent from my iPhone
>>>>>>>>>
>>>>>>>>> On 2016/09/07, at 3:03, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> All the commits that removed deprecated factory methods it sounds
>>>>>>>>> like.
>>>>>>>>>
>>>>>>>>> On 6 September 2016 at 13:00, Gary Gregory <garydgregory@gmail.com
>>>>>>>>> > wrote:
>>>>>>>>>
>>>>>>>>>> On Tue, Sep 6, 2016 at 12:31 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Should we revert those commits? There's still time.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> What commit? Do you mean to add back factory methods?
>>>>>>>>>>
>>>>>>>>>> Gary
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 3 September 2016 at 01:12, Ralph Goers <
>>>>>>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Perhaps we shouldn’t have.
>>>>>>>>>>>>
>>>>>>>>>>>> Ralph
>>>>>>>>>>>>
>>>>>>>>>>>> On Sep 2, 2016, at 7:46 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> We've already removed several deprecated factories in this
>>>>>>>>>>>> upcoming release, though.
>>>>>>>>>>>>
>>>>>>>>>>>> On 2 September 2016 at 06:28, Mikael Ståldal <
>>>>>>>>>>>> mikael.staldal@magine.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> I agree with Remko, let's keep them unless they are in the
>>>>>>>>>>>>> way. We can remove all of them in Log4j 3.0.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Fri, Sep 2, 2016 at 1:31 AM, Remko Popma <
>>>>>>>>>>>>> remko.popma@gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> It was mentioned on a mailing list or twitter conversation
>>>>>>>>>>>>>> with maintainers of another Apache project that one of the reasons they
>>>>>>>>>>>>>> hesitate to migrate to Log4j is that they worry we will break binary
>>>>>>>>>>>>>> compatibility.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Removing the factory methods just because we deprecated them
>>>>>>>>>>>>>> seems a bit harsh.
>>>>>>>>>>>>>> It's not like it's a huge maintenance effort to keep them.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I would not remove the deprecated factory methods unless they
>>>>>>>>>>>>>> actively prevent us from doing something we want to do.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Remko
>>>>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 2016/09/02, at 6:29, Ralph Goers <
>>>>>>>>>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Well, Java seems to have a policy of waiting at least 10
>>>>>>>>>>>>>> years, if ever….
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Seriously, I don’t think 1 minor release is enough as that
>>>>>>>>>>>>>> might very well be the next release. I’d say 2 minor releases and at least
>>>>>>>>>>>>>> 6 months.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Sep 1, 2016, at 1:42 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I think that when you add a builder and deprecate the
>>>>>>>>>>>>>> factory, you should remove it in the next 2.x release. Otherwise,
>>>>>>>>>>>>>> deprecation has no point if there's no version with the deprecation
>>>>>>>>>>>>>> specified.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 1 September 2016 at 13:40, Gary Gregory <
>>>>>>>>>>>>>> garydgregory@gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> When can we delete factory methods that are deprecated by
>>>>>>>>>>>>>>> builders?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Gary
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>>>>>>>>> <gg...@apache.org>
>>>>>>>>>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>>>>>>>>>> <http://www.manning.com/bauer3/>
>>>>>>>>>>>>>>> JUnit in Action, Second Edition
>>>>>>>>>>>>>>> <http://www.manning.com/tahchiev/>
>>>>>>>>>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>>>>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>>>>>>>>> Home: http://garygregory.com/
>>>>>>>>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> [image: MagineTV]
>>>>>>>>>>>>>
>>>>>>>>>>>>> *Mikael Ståldal*
>>>>>>>>>>>>> Senior software developer
>>>>>>>>>>>>>
>>>>>>>>>>>>> *Magine TV*
>>>>>>>>>>>>> mikael.staldal@magine.com
>>>>>>>>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden |
>>>>>>>>>>>>> www.magine.com <http://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.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>>>> <gg...@apache.org>
>>>>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>>>>> <http://www.manning.com/bauer3/>
>>>>>>>>>> JUnit in Action, Second Edition
>>>>>>>>>> <http://www.manning.com/tahchiev/>
>>>>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>>>> Home: http://garygregory.com/
>>>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>> <gg...@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
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <bo...@gmail.com>
>>>>
>>>>
>>>
>>>
>>> --
>>> 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
>>>
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>
>
>
> --
> 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: Deprecated factory methods replaced by builders.
Posted by Gary Gregory <ga...@gmail.com>.
On Wed, Sep 7, 2016 at 9:26 PM, Matt Sicker <bo...@gmail.com> wrote:
> This is actually why I suggested making an spi package long ago in core
> for public classes that would remain BC. Sadly, it's a little late for that
> now.
>
It's never too late ;-)
We could do that and call it 2.8 or surely for 3.0. BC for Core is not 100%
guaranteed, we just try to make life not too painful for SPI providers.
Gary
>
> On 7 September 2016 at 23:22, Gary Gregory <ga...@gmail.com> wrote:
>
>> On Wed, Sep 7, 2016 at 9:17 PM, Remko Popma <re...@gmail.com>
>> wrote:
>>
>>> Okay.
>>> Shall we introduce an @Internal annotation?
>>>
>>
>> Please no, everything in Core is internal. I think we need to start with
>> English sentences before we get caught up on details of how to communicate
>> that to users.
>>
>> Gary
>>
>>
>>>
>>> Sent from my iPhone
>>>
>>> On 2016/09/08, at 12:52, Matt Sicker <bo...@gmail.com> wrote:
>>>
>>> I agree that util packages are out of scope for BC. That's especially
>>> true in log4j-api where everything else has BC concerns.
>>>
>>> On 7 September 2016 at 21:14, Gary Gregory <ga...@gmail.com>
>>> wrote:
>>>
>>>> I do not think NullOutputStream.NULL_OUTPUT_STREAM is a good example
>>>> because the Core util package is or should out of bounds for BC. I thought
>>>> we had "agreed" on that.
>>>>
>>>> Gary
>>>>
>>>> On Wed, Sep 7, 2016 at 5:29 PM, Remko Popma <re...@gmail.com>
>>>> wrote:
>>>>
>>>>> We should make an effort not to break compatibility unless it's
>>>>> unavoidable. There is usually a way to accomplish things without breaking
>>>>> BC.
>>>>>
>>>>> This is doubly true for plugins but should be our policy in general.
>>>>>
>>>>> We should not make breaking changes for aesthetic reasons. For
>>>>> example, NullOutputStream.NULL_OUTPUT_STREAM would have been better
>>>>> named INSTANCE, but this is one thing I would not change at this stage.
>>>>>
>>>>> One of the reasons people (I think on the Spark mailing list)
>>>>> mentioned for putting off upgrading from Log4j 1.2 to Log4j 2 was worries
>>>>> we would make breaking changes.
>>>>>
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On 2016/09/08, at 8:03, Gary Gregory <ga...@gmail.com> wrote:
>>>>>
>>>>> On Wed, Sep 7, 2016 at 1:02 PM, Ralph Goers <
>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>
>>>>>> We really need to document what we want to strive to maintain
>>>>>> compatibility with in core. Basic components like Appenders and their
>>>>>> managers, Filters, Layouts, & Lookups or pretty much any Plugin type would
>>>>>> be at the top of my list.
>>>>>>
>>>>>
>>>>> Bleh, then we need to mark methods in some @tag-way in Javadocs.
>>>>>
>>>>> Gary
>>>>>
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>> On Sep 7, 2016, at 11:05 AM, Gary Gregory <ga...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> On Wed, Sep 7, 2016 at 11:41 AM, Remko Popma <re...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> We should do this before starting the 2.7 release.
>>>>>>> If we are serious about being the replacement for Log4j 1.2 we
>>>>>>> should not break user code for no good reason.
>>>>>>>
>>>>>>
>>>>>> What does this have to do with 1.2?
>>>>>>
>>>>>> Gary
>>>>>>
>>>>>>>
>>>>>>> On Wed, Sep 7, 2016 at 7:25 AM, Remko Popma <re...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I think that would be good.
>>>>>>>>
>>>>>>>> Based on the number of Jira tickets being filed we are beginning to
>>>>>>>> see increased uptake. Programmatic configuration is used surprisingly
>>>>>>>> often. Leaving the factory methods in with some reasonable default for the
>>>>>>>> missing parameters ensures existing users can smoothly upgrade.
>>>>>>>>
>>>>>>>> Sent from my iPhone
>>>>>>>>
>>>>>>>> On 2016/09/07, at 3:03, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> All the commits that removed deprecated factory methods it sounds
>>>>>>>> like.
>>>>>>>>
>>>>>>>> On 6 September 2016 at 13:00, Gary Gregory <ga...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> On Tue, Sep 6, 2016 at 12:31 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Should we revert those commits? There's still time.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> What commit? Do you mean to add back factory methods?
>>>>>>>>>
>>>>>>>>> Gary
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 3 September 2016 at 01:12, Ralph Goers <
>>>>>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Perhaps we shouldn’t have.
>>>>>>>>>>>
>>>>>>>>>>> Ralph
>>>>>>>>>>>
>>>>>>>>>>> On Sep 2, 2016, at 7:46 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> We've already removed several deprecated factories in this
>>>>>>>>>>> upcoming release, though.
>>>>>>>>>>>
>>>>>>>>>>> On 2 September 2016 at 06:28, Mikael Ståldal <
>>>>>>>>>>> mikael.staldal@magine.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I agree with Remko, let's keep them unless they are in the way.
>>>>>>>>>>>> We can remove all of them in Log4j 3.0.
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Sep 2, 2016 at 1:31 AM, Remko Popma <
>>>>>>>>>>>> remko.popma@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> It was mentioned on a mailing list or twitter conversation
>>>>>>>>>>>>> with maintainers of another Apache project that one of the reasons they
>>>>>>>>>>>>> hesitate to migrate to Log4j is that they worry we will break binary
>>>>>>>>>>>>> compatibility.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Removing the factory methods just because we deprecated them
>>>>>>>>>>>>> seems a bit harsh.
>>>>>>>>>>>>> It's not like it's a huge maintenance effort to keep them.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I would not remove the deprecated factory methods unless they
>>>>>>>>>>>>> actively prevent us from doing something we want to do.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Remko
>>>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 2016/09/02, at 6:29, Ralph Goers <
>>>>>>>>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Well, Java seems to have a policy of waiting at least 10
>>>>>>>>>>>>> years, if ever….
>>>>>>>>>>>>>
>>>>>>>>>>>>> Seriously, I don’t think 1 minor release is enough as that
>>>>>>>>>>>>> might very well be the next release. I’d say 2 minor releases and at least
>>>>>>>>>>>>> 6 months.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Sep 1, 2016, at 1:42 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think that when you add a builder and deprecate the factory,
>>>>>>>>>>>>> you should remove it in the next 2.x release. Otherwise, deprecation has no
>>>>>>>>>>>>> point if there's no version with the deprecation specified.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 1 September 2016 at 13:40, Gary Gregory <
>>>>>>>>>>>>> garydgregory@gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> When can we delete factory methods that are deprecated by
>>>>>>>>>>>>>> builders?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Gary
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>>>>>>>> <gg...@apache.org>
>>>>>>>>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>>>>>>>>> <http://www.manning.com/bauer3/>
>>>>>>>>>>>>>> JUnit in Action, Second Edition
>>>>>>>>>>>>>> <http://www.manning.com/tahchiev/>
>>>>>>>>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>>>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>>>>>>>> Home: http://garygregory.com/
>>>>>>>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> [image: MagineTV]
>>>>>>>>>>>>
>>>>>>>>>>>> *Mikael Ståldal*
>>>>>>>>>>>> Senior software developer
>>>>>>>>>>>>
>>>>>>>>>>>> *Magine TV*
>>>>>>>>>>>> mikael.staldal@magine.com
>>>>>>>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden |
>>>>>>>>>>>> www.magine.com <http://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.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>>> <gg...@apache.org>
>>>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>>>> <http://www.manning.com/bauer3/>
>>>>>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>>> Home: http://garygregory.com/
>>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>> <gg...@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
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> 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
>>>>
>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>>
>>>
>>
>>
>> --
>> 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
>>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
--
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: Deprecated factory methods replaced by builders.
Posted by Gary Gregory <ga...@gmail.com>.
We can take a one step at a time approach too. There is only one interface
in javax.security.auth.spi...
Gary
On Wed, Sep 7, 2016 at 11:23 PM, Gary Gregory <ga...@gmail.com>
wrote:
> So what would this look like? Just stick all the interfaces in there? And
> add more interfaces for things that are "public" and "supported"?
>
> Gary
>
> On Wed, Sep 7, 2016 at 9:26 PM, Matt Sicker <bo...@gmail.com> wrote:
>
>> This is actually why I suggested making an spi package long ago in core
>> for public classes that would remain BC. Sadly, it's a little late for that
>> now.
>>
>> On 7 September 2016 at 23:22, Gary Gregory <ga...@gmail.com>
>> wrote:
>>
>>> On Wed, Sep 7, 2016 at 9:17 PM, Remko Popma <re...@gmail.com>
>>> wrote:
>>>
>>>> Okay.
>>>> Shall we introduce an @Internal annotation?
>>>>
>>>
>>> Please no, everything in Core is internal. I think we need to start with
>>> English sentences before we get caught up on details of how to communicate
>>> that to users.
>>>
>>> Gary
>>>
>>>
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On 2016/09/08, at 12:52, Matt Sicker <bo...@gmail.com> wrote:
>>>>
>>>> I agree that util packages are out of scope for BC. That's especially
>>>> true in log4j-api where everything else has BC concerns.
>>>>
>>>> On 7 September 2016 at 21:14, Gary Gregory <ga...@gmail.com>
>>>> wrote:
>>>>
>>>>> I do not think NullOutputStream.NULL_OUTPUT_STREAM is a good example
>>>>> because the Core util package is or should out of bounds for BC. I thought
>>>>> we had "agreed" on that.
>>>>>
>>>>> Gary
>>>>>
>>>>> On Wed, Sep 7, 2016 at 5:29 PM, Remko Popma <re...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> We should make an effort not to break compatibility unless it's
>>>>>> unavoidable. There is usually a way to accomplish things without breaking
>>>>>> BC.
>>>>>>
>>>>>> This is doubly true for plugins but should be our policy in general.
>>>>>>
>>>>>> We should not make breaking changes for aesthetic reasons. For
>>>>>> example, NullOutputStream.NULL_OUTPUT_STREAM would have been better
>>>>>> named INSTANCE, but this is one thing I would not change at this stage.
>>>>>>
>>>>>> One of the reasons people (I think on the Spark mailing list)
>>>>>> mentioned for putting off upgrading from Log4j 1.2 to Log4j 2 was worries
>>>>>> we would make breaking changes.
>>>>>>
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> On 2016/09/08, at 8:03, Gary Gregory <ga...@gmail.com> wrote:
>>>>>>
>>>>>> On Wed, Sep 7, 2016 at 1:02 PM, Ralph Goers <
>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>
>>>>>>> We really need to document what we want to strive to maintain
>>>>>>> compatibility with in core. Basic components like Appenders and their
>>>>>>> managers, Filters, Layouts, & Lookups or pretty much any Plugin type would
>>>>>>> be at the top of my list.
>>>>>>>
>>>>>>
>>>>>> Bleh, then we need to mark methods in some @tag-way in Javadocs.
>>>>>>
>>>>>> Gary
>>>>>>
>>>>>>>
>>>>>>> Ralph
>>>>>>>
>>>>>>> On Sep 7, 2016, at 11:05 AM, Gary Gregory <ga...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> On Wed, Sep 7, 2016 at 11:41 AM, Remko Popma <re...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> We should do this before starting the 2.7 release.
>>>>>>>> If we are serious about being the replacement for Log4j 1.2 we
>>>>>>>> should not break user code for no good reason.
>>>>>>>>
>>>>>>>
>>>>>>> What does this have to do with 1.2?
>>>>>>>
>>>>>>> Gary
>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Sep 7, 2016 at 7:25 AM, Remko Popma <re...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> I think that would be good.
>>>>>>>>>
>>>>>>>>> Based on the number of Jira tickets being filed we are beginning
>>>>>>>>> to see increased uptake. Programmatic configuration is used surprisingly
>>>>>>>>> often. Leaving the factory methods in with some reasonable default for the
>>>>>>>>> missing parameters ensures existing users can smoothly upgrade.
>>>>>>>>>
>>>>>>>>> Sent from my iPhone
>>>>>>>>>
>>>>>>>>> On 2016/09/07, at 3:03, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> All the commits that removed deprecated factory methods it sounds
>>>>>>>>> like.
>>>>>>>>>
>>>>>>>>> On 6 September 2016 at 13:00, Gary Gregory <garydgregory@gmail.com
>>>>>>>>> > wrote:
>>>>>>>>>
>>>>>>>>>> On Tue, Sep 6, 2016 at 12:31 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Should we revert those commits? There's still time.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> What commit? Do you mean to add back factory methods?
>>>>>>>>>>
>>>>>>>>>> Gary
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 3 September 2016 at 01:12, Ralph Goers <
>>>>>>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Perhaps we shouldn’t have.
>>>>>>>>>>>>
>>>>>>>>>>>> Ralph
>>>>>>>>>>>>
>>>>>>>>>>>> On Sep 2, 2016, at 7:46 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> We've already removed several deprecated factories in this
>>>>>>>>>>>> upcoming release, though.
>>>>>>>>>>>>
>>>>>>>>>>>> On 2 September 2016 at 06:28, Mikael Ståldal <
>>>>>>>>>>>> mikael.staldal@magine.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> I agree with Remko, let's keep them unless they are in the
>>>>>>>>>>>>> way. We can remove all of them in Log4j 3.0.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Fri, Sep 2, 2016 at 1:31 AM, Remko Popma <
>>>>>>>>>>>>> remko.popma@gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> It was mentioned on a mailing list or twitter conversation
>>>>>>>>>>>>>> with maintainers of another Apache project that one of the reasons they
>>>>>>>>>>>>>> hesitate to migrate to Log4j is that they worry we will break binary
>>>>>>>>>>>>>> compatibility.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Removing the factory methods just because we deprecated them
>>>>>>>>>>>>>> seems a bit harsh.
>>>>>>>>>>>>>> It's not like it's a huge maintenance effort to keep them.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I would not remove the deprecated factory methods unless they
>>>>>>>>>>>>>> actively prevent us from doing something we want to do.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Remko
>>>>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 2016/09/02, at 6:29, Ralph Goers <
>>>>>>>>>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Well, Java seems to have a policy of waiting at least 10
>>>>>>>>>>>>>> years, if ever….
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Seriously, I don’t think 1 minor release is enough as that
>>>>>>>>>>>>>> might very well be the next release. I’d say 2 minor releases and at least
>>>>>>>>>>>>>> 6 months.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Sep 1, 2016, at 1:42 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I think that when you add a builder and deprecate the
>>>>>>>>>>>>>> factory, you should remove it in the next 2.x release. Otherwise,
>>>>>>>>>>>>>> deprecation has no point if there's no version with the deprecation
>>>>>>>>>>>>>> specified.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 1 September 2016 at 13:40, Gary Gregory <
>>>>>>>>>>>>>> garydgregory@gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> When can we delete factory methods that are deprecated by
>>>>>>>>>>>>>>> builders?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Gary
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>>>>>>>>> <gg...@apache.org>
>>>>>>>>>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>>>>>>>>>> <http://www.manning.com/bauer3/>
>>>>>>>>>>>>>>> JUnit in Action, Second Edition
>>>>>>>>>>>>>>> <http://www.manning.com/tahchiev/>
>>>>>>>>>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>>>>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>>>>>>>>> Home: http://garygregory.com/
>>>>>>>>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> [image: MagineTV]
>>>>>>>>>>>>>
>>>>>>>>>>>>> *Mikael Ståldal*
>>>>>>>>>>>>> Senior software developer
>>>>>>>>>>>>>
>>>>>>>>>>>>> *Magine TV*
>>>>>>>>>>>>> mikael.staldal@magine.com
>>>>>>>>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden |
>>>>>>>>>>>>> www.magine.com <http://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.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>>>> <gg...@apache.org>
>>>>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>>>>> <http://www.manning.com/bauer3/>
>>>>>>>>>> JUnit in Action, Second Edition
>>>>>>>>>> <http://www.manning.com/tahchiev/>
>>>>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>>>> Home: http://garygregory.com/
>>>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>> <gg...@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
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <bo...@gmail.com>
>>>>
>>>>
>>>
>>>
>>> --
>>> 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
>>>
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>
>
>
> --
> 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: Deprecated factory methods replaced by builders.
Posted by Gary Gregory <ga...@gmail.com>.
So what would this look like? Just stick all the interfaces in there? And
add more interfaces for things that are "public" and "supported"?
Gary
On Wed, Sep 7, 2016 at 9:26 PM, Matt Sicker <bo...@gmail.com> wrote:
> This is actually why I suggested making an spi package long ago in core
> for public classes that would remain BC. Sadly, it's a little late for that
> now.
>
> On 7 September 2016 at 23:22, Gary Gregory <ga...@gmail.com> wrote:
>
>> On Wed, Sep 7, 2016 at 9:17 PM, Remko Popma <re...@gmail.com>
>> wrote:
>>
>>> Okay.
>>> Shall we introduce an @Internal annotation?
>>>
>>
>> Please no, everything in Core is internal. I think we need to start with
>> English sentences before we get caught up on details of how to communicate
>> that to users.
>>
>> Gary
>>
>>
>>>
>>> Sent from my iPhone
>>>
>>> On 2016/09/08, at 12:52, Matt Sicker <bo...@gmail.com> wrote:
>>>
>>> I agree that util packages are out of scope for BC. That's especially
>>> true in log4j-api where everything else has BC concerns.
>>>
>>> On 7 September 2016 at 21:14, Gary Gregory <ga...@gmail.com>
>>> wrote:
>>>
>>>> I do not think NullOutputStream.NULL_OUTPUT_STREAM is a good example
>>>> because the Core util package is or should out of bounds for BC. I thought
>>>> we had "agreed" on that.
>>>>
>>>> Gary
>>>>
>>>> On Wed, Sep 7, 2016 at 5:29 PM, Remko Popma <re...@gmail.com>
>>>> wrote:
>>>>
>>>>> We should make an effort not to break compatibility unless it's
>>>>> unavoidable. There is usually a way to accomplish things without breaking
>>>>> BC.
>>>>>
>>>>> This is doubly true for plugins but should be our policy in general.
>>>>>
>>>>> We should not make breaking changes for aesthetic reasons. For
>>>>> example, NullOutputStream.NULL_OUTPUT_STREAM would have been better
>>>>> named INSTANCE, but this is one thing I would not change at this stage.
>>>>>
>>>>> One of the reasons people (I think on the Spark mailing list)
>>>>> mentioned for putting off upgrading from Log4j 1.2 to Log4j 2 was worries
>>>>> we would make breaking changes.
>>>>>
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On 2016/09/08, at 8:03, Gary Gregory <ga...@gmail.com> wrote:
>>>>>
>>>>> On Wed, Sep 7, 2016 at 1:02 PM, Ralph Goers <
>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>
>>>>>> We really need to document what we want to strive to maintain
>>>>>> compatibility with in core. Basic components like Appenders and their
>>>>>> managers, Filters, Layouts, & Lookups or pretty much any Plugin type would
>>>>>> be at the top of my list.
>>>>>>
>>>>>
>>>>> Bleh, then we need to mark methods in some @tag-way in Javadocs.
>>>>>
>>>>> Gary
>>>>>
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>> On Sep 7, 2016, at 11:05 AM, Gary Gregory <ga...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> On Wed, Sep 7, 2016 at 11:41 AM, Remko Popma <re...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> We should do this before starting the 2.7 release.
>>>>>>> If we are serious about being the replacement for Log4j 1.2 we
>>>>>>> should not break user code for no good reason.
>>>>>>>
>>>>>>
>>>>>> What does this have to do with 1.2?
>>>>>>
>>>>>> Gary
>>>>>>
>>>>>>>
>>>>>>> On Wed, Sep 7, 2016 at 7:25 AM, Remko Popma <re...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I think that would be good.
>>>>>>>>
>>>>>>>> Based on the number of Jira tickets being filed we are beginning to
>>>>>>>> see increased uptake. Programmatic configuration is used surprisingly
>>>>>>>> often. Leaving the factory methods in with some reasonable default for the
>>>>>>>> missing parameters ensures existing users can smoothly upgrade.
>>>>>>>>
>>>>>>>> Sent from my iPhone
>>>>>>>>
>>>>>>>> On 2016/09/07, at 3:03, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> All the commits that removed deprecated factory methods it sounds
>>>>>>>> like.
>>>>>>>>
>>>>>>>> On 6 September 2016 at 13:00, Gary Gregory <ga...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> On Tue, Sep 6, 2016 at 12:31 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Should we revert those commits? There's still time.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> What commit? Do you mean to add back factory methods?
>>>>>>>>>
>>>>>>>>> Gary
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 3 September 2016 at 01:12, Ralph Goers <
>>>>>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Perhaps we shouldn’t have.
>>>>>>>>>>>
>>>>>>>>>>> Ralph
>>>>>>>>>>>
>>>>>>>>>>> On Sep 2, 2016, at 7:46 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> We've already removed several deprecated factories in this
>>>>>>>>>>> upcoming release, though.
>>>>>>>>>>>
>>>>>>>>>>> On 2 September 2016 at 06:28, Mikael Ståldal <
>>>>>>>>>>> mikael.staldal@magine.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I agree with Remko, let's keep them unless they are in the way.
>>>>>>>>>>>> We can remove all of them in Log4j 3.0.
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Sep 2, 2016 at 1:31 AM, Remko Popma <
>>>>>>>>>>>> remko.popma@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> It was mentioned on a mailing list or twitter conversation
>>>>>>>>>>>>> with maintainers of another Apache project that one of the reasons they
>>>>>>>>>>>>> hesitate to migrate to Log4j is that they worry we will break binary
>>>>>>>>>>>>> compatibility.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Removing the factory methods just because we deprecated them
>>>>>>>>>>>>> seems a bit harsh.
>>>>>>>>>>>>> It's not like it's a huge maintenance effort to keep them.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I would not remove the deprecated factory methods unless they
>>>>>>>>>>>>> actively prevent us from doing something we want to do.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Remko
>>>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 2016/09/02, at 6:29, Ralph Goers <
>>>>>>>>>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Well, Java seems to have a policy of waiting at least 10
>>>>>>>>>>>>> years, if ever….
>>>>>>>>>>>>>
>>>>>>>>>>>>> Seriously, I don’t think 1 minor release is enough as that
>>>>>>>>>>>>> might very well be the next release. I’d say 2 minor releases and at least
>>>>>>>>>>>>> 6 months.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Sep 1, 2016, at 1:42 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think that when you add a builder and deprecate the factory,
>>>>>>>>>>>>> you should remove it in the next 2.x release. Otherwise, deprecation has no
>>>>>>>>>>>>> point if there's no version with the deprecation specified.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 1 September 2016 at 13:40, Gary Gregory <
>>>>>>>>>>>>> garydgregory@gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> When can we delete factory methods that are deprecated by
>>>>>>>>>>>>>> builders?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Gary
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>>>>>>>> <gg...@apache.org>
>>>>>>>>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>>>>>>>>> <http://www.manning.com/bauer3/>
>>>>>>>>>>>>>> JUnit in Action, Second Edition
>>>>>>>>>>>>>> <http://www.manning.com/tahchiev/>
>>>>>>>>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>>>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>>>>>>>> Home: http://garygregory.com/
>>>>>>>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> [image: MagineTV]
>>>>>>>>>>>>
>>>>>>>>>>>> *Mikael Ståldal*
>>>>>>>>>>>> Senior software developer
>>>>>>>>>>>>
>>>>>>>>>>>> *Magine TV*
>>>>>>>>>>>> mikael.staldal@magine.com
>>>>>>>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden |
>>>>>>>>>>>> www.magine.com <http://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.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>>> <gg...@apache.org>
>>>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>>>> <http://www.manning.com/bauer3/>
>>>>>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>>> Home: http://garygregory.com/
>>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>> <gg...@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
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> 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
>>>>
>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>>
>>>
>>
>>
>> --
>> 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
>>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
--
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: Deprecated factory methods replaced by builders.
Posted by Matt Sicker <bo...@gmail.com>.
This is actually why I suggested making an spi package long ago in core for
public classes that would remain BC. Sadly, it's a little late for that now.
On 7 September 2016 at 23:22, Gary Gregory <ga...@gmail.com> wrote:
> On Wed, Sep 7, 2016 at 9:17 PM, Remko Popma <re...@gmail.com> wrote:
>
>> Okay.
>> Shall we introduce an @Internal annotation?
>>
>
> Please no, everything in Core is internal. I think we need to start with
> English sentences before we get caught up on details of how to communicate
> that to users.
>
> Gary
>
>
>>
>> Sent from my iPhone
>>
>> On 2016/09/08, at 12:52, Matt Sicker <bo...@gmail.com> wrote:
>>
>> I agree that util packages are out of scope for BC. That's especially
>> true in log4j-api where everything else has BC concerns.
>>
>> On 7 September 2016 at 21:14, Gary Gregory <ga...@gmail.com>
>> wrote:
>>
>>> I do not think NullOutputStream.NULL_OUTPUT_STREAM is a good example
>>> because the Core util package is or should out of bounds for BC. I thought
>>> we had "agreed" on that.
>>>
>>> Gary
>>>
>>> On Wed, Sep 7, 2016 at 5:29 PM, Remko Popma <re...@gmail.com>
>>> wrote:
>>>
>>>> We should make an effort not to break compatibility unless it's
>>>> unavoidable. There is usually a way to accomplish things without breaking
>>>> BC.
>>>>
>>>> This is doubly true for plugins but should be our policy in general.
>>>>
>>>> We should not make breaking changes for aesthetic reasons. For example,
>>>> NullOutputStream.NULL_OUTPUT_STREAM would have been better named
>>>> INSTANCE, but this is one thing I would not change at this stage.
>>>>
>>>> One of the reasons people (I think on the Spark mailing list) mentioned
>>>> for putting off upgrading from Log4j 1.2 to Log4j 2 was worries we would
>>>> make breaking changes.
>>>>
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On 2016/09/08, at 8:03, Gary Gregory <ga...@gmail.com> wrote:
>>>>
>>>> On Wed, Sep 7, 2016 at 1:02 PM, Ralph Goers <ralph.goers@dslextreme.com
>>>> > wrote:
>>>>
>>>>> We really need to document what we want to strive to maintain
>>>>> compatibility with in core. Basic components like Appenders and their
>>>>> managers, Filters, Layouts, & Lookups or pretty much any Plugin type would
>>>>> be at the top of my list.
>>>>>
>>>>
>>>> Bleh, then we need to mark methods in some @tag-way in Javadocs.
>>>>
>>>> Gary
>>>>
>>>>>
>>>>> Ralph
>>>>>
>>>>> On Sep 7, 2016, at 11:05 AM, Gary Gregory <ga...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> On Wed, Sep 7, 2016 at 11:41 AM, Remko Popma <re...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> We should do this before starting the 2.7 release.
>>>>>> If we are serious about being the replacement for Log4j 1.2 we should
>>>>>> not break user code for no good reason.
>>>>>>
>>>>>
>>>>> What does this have to do with 1.2?
>>>>>
>>>>> Gary
>>>>>
>>>>>>
>>>>>> On Wed, Sep 7, 2016 at 7:25 AM, Remko Popma <re...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I think that would be good.
>>>>>>>
>>>>>>> Based on the number of Jira tickets being filed we are beginning to
>>>>>>> see increased uptake. Programmatic configuration is used surprisingly
>>>>>>> often. Leaving the factory methods in with some reasonable default for the
>>>>>>> missing parameters ensures existing users can smoothly upgrade.
>>>>>>>
>>>>>>> Sent from my iPhone
>>>>>>>
>>>>>>> On 2016/09/07, at 3:03, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>
>>>>>>> All the commits that removed deprecated factory methods it sounds
>>>>>>> like.
>>>>>>>
>>>>>>> On 6 September 2016 at 13:00, Gary Gregory <ga...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On Tue, Sep 6, 2016 at 12:31 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Should we revert those commits? There's still time.
>>>>>>>>>
>>>>>>>>
>>>>>>>> What commit? Do you mean to add back factory methods?
>>>>>>>>
>>>>>>>> Gary
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 3 September 2016 at 01:12, Ralph Goers <ralph.goers@dslextreme.
>>>>>>>>> com> wrote:
>>>>>>>>>
>>>>>>>>>> Perhaps we shouldn’t have.
>>>>>>>>>>
>>>>>>>>>> Ralph
>>>>>>>>>>
>>>>>>>>>> On Sep 2, 2016, at 7:46 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> We've already removed several deprecated factories in this
>>>>>>>>>> upcoming release, though.
>>>>>>>>>>
>>>>>>>>>> On 2 September 2016 at 06:28, Mikael Ståldal <
>>>>>>>>>> mikael.staldal@magine.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> I agree with Remko, let's keep them unless they are in the way.
>>>>>>>>>>> We can remove all of them in Log4j 3.0.
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Sep 2, 2016 at 1:31 AM, Remko Popma <
>>>>>>>>>>> remko.popma@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> It was mentioned on a mailing list or twitter conversation with
>>>>>>>>>>>> maintainers of another Apache project that one of the reasons they hesitate
>>>>>>>>>>>> to migrate to Log4j is that they worry we will break binary compatibility.
>>>>>>>>>>>>
>>>>>>>>>>>> Removing the factory methods just because we deprecated them
>>>>>>>>>>>> seems a bit harsh.
>>>>>>>>>>>> It's not like it's a huge maintenance effort to keep them.
>>>>>>>>>>>>
>>>>>>>>>>>> I would not remove the deprecated factory methods unless they
>>>>>>>>>>>> actively prevent us from doing something we want to do.
>>>>>>>>>>>>
>>>>>>>>>>>> Remko
>>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>
>>>>>>>>>>>> On 2016/09/02, at 6:29, Ralph Goers <ra...@dslextreme.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Well, Java seems to have a policy of waiting at least 10 years,
>>>>>>>>>>>> if ever….
>>>>>>>>>>>>
>>>>>>>>>>>> Seriously, I don’t think 1 minor release is enough as that
>>>>>>>>>>>> might very well be the next release. I’d say 2 minor releases and at least
>>>>>>>>>>>> 6 months.
>>>>>>>>>>>>
>>>>>>>>>>>> Ralph
>>>>>>>>>>>>
>>>>>>>>>>>> On Sep 1, 2016, at 1:42 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> I think that when you add a builder and deprecate the factory,
>>>>>>>>>>>> you should remove it in the next 2.x release. Otherwise, deprecation has no
>>>>>>>>>>>> point if there's no version with the deprecation specified.
>>>>>>>>>>>>
>>>>>>>>>>>> On 1 September 2016 at 13:40, Gary Gregory <
>>>>>>>>>>>> garydgregory@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> When can we delete factory methods that are deprecated by
>>>>>>>>>>>>> builders?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Gary
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>>>>>>> <gg...@apache.org>
>>>>>>>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>>>>>>>> <http://www.manning.com/bauer3/>
>>>>>>>>>>>>> JUnit in Action, Second Edition
>>>>>>>>>>>>> <http://www.manning.com/tahchiev/>
>>>>>>>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>>>>>>> Home: http://garygregory.com/
>>>>>>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> [image: MagineTV]
>>>>>>>>>>>
>>>>>>>>>>> *Mikael Ståldal*
>>>>>>>>>>> Senior software developer
>>>>>>>>>>>
>>>>>>>>>>> *Magine TV*
>>>>>>>>>>> mikael.staldal@magine.com
>>>>>>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>>>>>>>>> <http://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.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>> <gg...@apache.org>
>>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>>> <http://www.manning.com/bauer3/>
>>>>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>> Home: http://garygregory.com/
>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>> <gg...@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
>>>>
>>>>
>>>
>>>
>>> --
>>> 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
>>>
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>>
>
>
> --
> 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
>
--
Matt Sicker <bo...@gmail.com>
Re: Deprecated factory methods replaced by builders.
Posted by Gary Gregory <ga...@gmail.com>.
On Wed, Sep 7, 2016 at 9:17 PM, Remko Popma <re...@gmail.com> wrote:
> Okay.
> Shall we introduce an @Internal annotation?
>
Please no, everything in Core is internal. I think we need to start with
English sentences before we get caught up on details of how to communicate
that to users.
Gary
>
> Sent from my iPhone
>
> On 2016/09/08, at 12:52, Matt Sicker <bo...@gmail.com> wrote:
>
> I agree that util packages are out of scope for BC. That's especially true
> in log4j-api where everything else has BC concerns.
>
> On 7 September 2016 at 21:14, Gary Gregory <ga...@gmail.com> wrote:
>
>> I do not think NullOutputStream.NULL_OUTPUT_STREAM is a good example
>> because the Core util package is or should out of bounds for BC. I thought
>> we had "agreed" on that.
>>
>> Gary
>>
>> On Wed, Sep 7, 2016 at 5:29 PM, Remko Popma <re...@gmail.com>
>> wrote:
>>
>>> We should make an effort not to break compatibility unless it's
>>> unavoidable. There is usually a way to accomplish things without breaking
>>> BC.
>>>
>>> This is doubly true for plugins but should be our policy in general.
>>>
>>> We should not make breaking changes for aesthetic reasons. For example,
>>> NullOutputStream.NULL_OUTPUT_STREAM would have been better named
>>> INSTANCE, but this is one thing I would not change at this stage.
>>>
>>> One of the reasons people (I think on the Spark mailing list) mentioned
>>> for putting off upgrading from Log4j 1.2 to Log4j 2 was worries we would
>>> make breaking changes.
>>>
>>>
>>> Sent from my iPhone
>>>
>>> On 2016/09/08, at 8:03, Gary Gregory <ga...@gmail.com> wrote:
>>>
>>> On Wed, Sep 7, 2016 at 1:02 PM, Ralph Goers <ra...@dslextreme.com>
>>> wrote:
>>>
>>>> We really need to document what we want to strive to maintain
>>>> compatibility with in core. Basic components like Appenders and their
>>>> managers, Filters, Layouts, & Lookups or pretty much any Plugin type would
>>>> be at the top of my list.
>>>>
>>>
>>> Bleh, then we need to mark methods in some @tag-way in Javadocs.
>>>
>>> Gary
>>>
>>>>
>>>> Ralph
>>>>
>>>> On Sep 7, 2016, at 11:05 AM, Gary Gregory <ga...@gmail.com>
>>>> wrote:
>>>>
>>>> On Wed, Sep 7, 2016 at 11:41 AM, Remko Popma <re...@gmail.com>
>>>> wrote:
>>>>
>>>>> We should do this before starting the 2.7 release.
>>>>> If we are serious about being the replacement for Log4j 1.2 we should
>>>>> not break user code for no good reason.
>>>>>
>>>>
>>>> What does this have to do with 1.2?
>>>>
>>>> Gary
>>>>
>>>>>
>>>>> On Wed, Sep 7, 2016 at 7:25 AM, Remko Popma <re...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> I think that would be good.
>>>>>>
>>>>>> Based on the number of Jira tickets being filed we are beginning to
>>>>>> see increased uptake. Programmatic configuration is used surprisingly
>>>>>> often. Leaving the factory methods in with some reasonable default for the
>>>>>> missing parameters ensures existing users can smoothly upgrade.
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> On 2016/09/07, at 3:03, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>
>>>>>> All the commits that removed deprecated factory methods it sounds
>>>>>> like.
>>>>>>
>>>>>> On 6 September 2016 at 13:00, Gary Gregory <ga...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> On Tue, Sep 6, 2016 at 12:31 PM, Matt Sicker <bo...@gmail.com> wrot
>>>>>>> e:
>>>>>>>
>>>>>>>> Should we revert those commits? There's still time.
>>>>>>>>
>>>>>>>
>>>>>>> What commit? Do you mean to add back factory methods?
>>>>>>>
>>>>>>> Gary
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> On 3 September 2016 at 01:12, Ralph Goers <ralph.goers@dslextreme.
>>>>>>>> com> wrote:
>>>>>>>>
>>>>>>>>> Perhaps we shouldn’t have.
>>>>>>>>>
>>>>>>>>> Ralph
>>>>>>>>>
>>>>>>>>> On Sep 2, 2016, at 7:46 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> We've already removed several deprecated factories in this
>>>>>>>>> upcoming release, though.
>>>>>>>>>
>>>>>>>>> On 2 September 2016 at 06:28, Mikael Ståldal <
>>>>>>>>> mikael.staldal@magine.com> wrote:
>>>>>>>>>
>>>>>>>>>> I agree with Remko, let's keep them unless they are in the way.
>>>>>>>>>> We can remove all of them in Log4j 3.0.
>>>>>>>>>>
>>>>>>>>>> On Fri, Sep 2, 2016 at 1:31 AM, Remko Popma <
>>>>>>>>>> remko.popma@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> It was mentioned on a mailing list or twitter conversation with
>>>>>>>>>>> maintainers of another Apache project that one of the reasons they hesitate
>>>>>>>>>>> to migrate to Log4j is that they worry we will break binary compatibility.
>>>>>>>>>>>
>>>>>>>>>>> Removing the factory methods just because we deprecated them
>>>>>>>>>>> seems a bit harsh.
>>>>>>>>>>> It's not like it's a huge maintenance effort to keep them.
>>>>>>>>>>>
>>>>>>>>>>> I would not remove the deprecated factory methods unless they
>>>>>>>>>>> actively prevent us from doing something we want to do.
>>>>>>>>>>>
>>>>>>>>>>> Remko
>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>
>>>>>>>>>>> On 2016/09/02, at 6:29, Ralph Goers <ra...@dslextreme.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Well, Java seems to have a policy of waiting at least 10 years,
>>>>>>>>>>> if ever….
>>>>>>>>>>>
>>>>>>>>>>> Seriously, I don’t think 1 minor release is enough as that might
>>>>>>>>>>> very well be the next release. I’d say 2 minor releases and at least 6
>>>>>>>>>>> months.
>>>>>>>>>>>
>>>>>>>>>>> Ralph
>>>>>>>>>>>
>>>>>>>>>>> On Sep 1, 2016, at 1:42 PM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> I think that when you add a builder and deprecate the factory,
>>>>>>>>>>> you should remove it in the next 2.x release. Otherwise, deprecation has no
>>>>>>>>>>> point if there's no version with the deprecation specified.
>>>>>>>>>>>
>>>>>>>>>>> On 1 September 2016 at 13:40, Gary Gregory <
>>>>>>>>>>> garydgregory@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> When can we delete factory methods that are deprecated by
>>>>>>>>>>>> builders?
>>>>>>>>>>>>
>>>>>>>>>>>> Gary
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>>>>>> <gg...@apache.org>
>>>>>>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>>>>>>> <http://www.manning.com/bauer3/>
>>>>>>>>>>>> JUnit in Action, Second Edition
>>>>>>>>>>>> <http://www.manning.com/tahchiev/>
>>>>>>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>>>>>> Home: http://garygregory.com/
>>>>>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> [image: MagineTV]
>>>>>>>>>>
>>>>>>>>>> *Mikael Ståldal*
>>>>>>>>>> Senior software developer
>>>>>>>>>>
>>>>>>>>>> *Magine TV*
>>>>>>>>>> mikael.staldal@magine.com
>>>>>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>>>>>>>> <http://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.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>> <gg...@apache.org>
>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>> <http://www.manning.com/bauer3/>
>>>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>> Home: http://garygregory.com/
>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>> <gg...@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
>>>
>>>
>>
>>
>> --
>> 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
>>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
>
--
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: Deprecated factory methods replaced by builders.
Posted by Remko Popma <re...@gmail.com>.
Okay.
Shall we introduce an @Internal annotation?
Sent from my iPhone
> On 2016/09/08, at 12:52, Matt Sicker <bo...@gmail.com> wrote:
>
> I agree that util packages are out of scope for BC. That's especially true in log4j-api where everything else has BC concerns.
>
>> On 7 September 2016 at 21:14, Gary Gregory <ga...@gmail.com> wrote:
>> I do not think NullOutputStream.NULL_OUTPUT_STREAM is a good example because the Core util package is or should out of bounds for BC. I thought we had "agreed" on that.
>>
>> Gary
>>
>>> On Wed, Sep 7, 2016 at 5:29 PM, Remko Popma <re...@gmail.com> wrote:
>>> We should make an effort not to break compatibility unless it's unavoidable. There is usually a way to accomplish things without breaking BC.
>>>
>>> This is doubly true for plugins but should be our policy in general.
>>>
>>> We should not make breaking changes for aesthetic reasons. For example, NullOutputStream.NULL_OUTPUT_STREAM would have been better named INSTANCE, but this is one thing I would not change at this stage.
>>>
>>> One of the reasons people (I think on the Spark mailing list) mentioned for putting off upgrading from Log4j 1.2 to Log4j 2 was worries we would make breaking changes.
>>>
>>>
>>> Sent from my iPhone
>>>
>>>> On 2016/09/08, at 8:03, Gary Gregory <ga...@gmail.com> wrote:
>>>>
>>>>> On Wed, Sep 7, 2016 at 1:02 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>>>>> We really need to document what we want to strive to maintain compatibility with in core. Basic components like Appenders and their managers, Filters, Layouts, & Lookups or pretty much any Plugin type would be at the top of my list.
>>>>
>>>> Bleh, then we need to mark methods in some @tag-way in Javadocs.
>>>>
>>>> Gary
>>>>>
>>>>> Ralph
>>>>>
>>>>>> On Sep 7, 2016, at 11:05 AM, Gary Gregory <ga...@gmail.com> wrote:
>>>>>>
>>>>>>> On Wed, Sep 7, 2016 at 11:41 AM, Remko Popma <re...@gmail.com> wrote:
>>>>>>> We should do this before starting the 2.7 release.
>>>>>>> If we are serious about being the replacement for Log4j 1.2 we should not break user code for no good reason.
>>>>>>
>>>>>> What does this have to do with 1.2?
>>>>>>
>>>>>> Gary
>>>>>>>
>>>>>>>> On Wed, Sep 7, 2016 at 7:25 AM, Remko Popma <re...@gmail.com> wrote:
>>>>>>>> I think that would be good.
>>>>>>>>
>>>>>>>> Based on the number of Jira tickets being filed we are beginning to see increased uptake. Programmatic configuration is used surprisingly often. Leaving the factory methods in with some reasonable default for the missing parameters ensures existing users can smoothly upgrade.
>>>>>>>>
>>>>>>>> Sent from my iPhone
>>>>>>>>
>>>>>>>>> On 2016/09/07, at 3:03, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> All the commits that removed deprecated factory methods it sounds like.
>>>>>>>>>
>>>>>>>>>> On 6 September 2016 at 13:00, Gary Gregory <ga...@gmail.com> wrote:
>>>>>>>>>>> On Tue, Sep 6, 2016 at 12:31 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>> Should we revert those commits? There's still time.
>>>>>>>>>>
>>>>>>>>>> What commit? Do you mean to add back factory methods?
>>>>>>>>>>
>>>>>>>>>> Gary
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> On 3 September 2016 at 01:12, Ralph Goers <ra...@dslextreme.com> wrote:
>>>>>>>>>>>> Perhaps we shouldn’t have.
>>>>>>>>>>>>
>>>>>>>>>>>> Ralph
>>>>>>>>>>>>
>>>>>>>>>>>>> On Sep 2, 2016, at 7:46 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> We've already removed several deprecated factories in this upcoming release, though.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 2 September 2016 at 06:28, Mikael Ståldal <mi...@magine.com> wrote:
>>>>>>>>>>>>>> I agree with Remko, let's keep them unless they are in the way. We can remove all of them in Log4j 3.0.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Fri, Sep 2, 2016 at 1:31 AM, Remko Popma <re...@gmail.com> wrote:
>>>>>>>>>>>>>>> It was mentioned on a mailing list or twitter conversation with maintainers of another Apache project that one of the reasons they hesitate to migrate to Log4j is that they worry we will break binary compatibility.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Removing the factory methods just because we deprecated them seems a bit harsh.
>>>>>>>>>>>>>>> It's not like it's a huge maintenance effort to keep them.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I would not remove the deprecated factory methods unless they actively prevent us from doing something we want to do.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Remko
>>>>>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 2016/09/02, at 6:29, Ralph Goers <ra...@dslextreme.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Well, Java seems to have a policy of waiting at least 10 years, if ever….
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Seriously, I don’t think 1 minor release is enough as that might very well be the next release. I’d say 2 minor releases and at least 6 months.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Sep 1, 2016, at 1:42 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I think that when you add a builder and deprecate the factory, you should remove it in the next 2.x release. Otherwise, deprecation has no point if there's no version with the deprecation specified.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 1 September 2016 at 13:40, Gary Gregory <ga...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> When can we delete factory methods that are deprecated by builders?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Mikael Ståldal
>>>>>>>>>>>>>> Senior software developer
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Magine TV
>>>>>>>>>>>>>> mikael.staldal@magine.com
>>>>>>>>>>>>>> Grev Turegatan 3 | 114 46 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.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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
>>
>>
>>
>> --
>> 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
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
Re: Deprecated factory methods replaced by builders.
Posted by Matt Sicker <bo...@gmail.com>.
I agree that util packages are out of scope for BC. That's especially true
in log4j-api where everything else has BC concerns.
On 7 September 2016 at 21:14, Gary Gregory <ga...@gmail.com> wrote:
> I do not think NullOutputStream.NULL_OUTPUT_STREAM is a good example
> because the Core util package is or should out of bounds for BC. I thought
> we had "agreed" on that.
>
> Gary
>
> On Wed, Sep 7, 2016 at 5:29 PM, Remko Popma <re...@gmail.com> wrote:
>
>> We should make an effort not to break compatibility unless it's
>> unavoidable. There is usually a way to accomplish things without breaking
>> BC.
>>
>> This is doubly true for plugins but should be our policy in general.
>>
>> We should not make breaking changes for aesthetic reasons. For example,
>> NullOutputStream.NULL_OUTPUT_STREAM would have been better named
>> INSTANCE, but this is one thing I would not change at this stage.
>>
>> One of the reasons people (I think on the Spark mailing list) mentioned
>> for putting off upgrading from Log4j 1.2 to Log4j 2 was worries we would
>> make breaking changes.
>>
>>
>> Sent from my iPhone
>>
>> On 2016/09/08, at 8:03, Gary Gregory <ga...@gmail.com> wrote:
>>
>> On Wed, Sep 7, 2016 at 1:02 PM, Ralph Goers <ra...@dslextreme.com>
>> wrote:
>>
>>> We really need to document what we want to strive to maintain
>>> compatibility with in core. Basic components like Appenders and their
>>> managers, Filters, Layouts, & Lookups or pretty much any Plugin type would
>>> be at the top of my list.
>>>
>>
>> Bleh, then we need to mark methods in some @tag-way in Javadocs.
>>
>> Gary
>>
>>>
>>> Ralph
>>>
>>> On Sep 7, 2016, at 11:05 AM, Gary Gregory <ga...@gmail.com>
>>> wrote:
>>>
>>> On Wed, Sep 7, 2016 at 11:41 AM, Remko Popma <re...@gmail.com>
>>> wrote:
>>>
>>>> We should do this before starting the 2.7 release.
>>>> If we are serious about being the replacement for Log4j 1.2 we should
>>>> not break user code for no good reason.
>>>>
>>>
>>> What does this have to do with 1.2?
>>>
>>> Gary
>>>
>>>>
>>>> On Wed, Sep 7, 2016 at 7:25 AM, Remko Popma <re...@gmail.com>
>>>> wrote:
>>>>
>>>>> I think that would be good.
>>>>>
>>>>> Based on the number of Jira tickets being filed we are beginning to
>>>>> see increased uptake. Programmatic configuration is used surprisingly
>>>>> often. Leaving the factory methods in with some reasonable default for the
>>>>> missing parameters ensures existing users can smoothly upgrade.
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On 2016/09/07, at 3:03, Matt Sicker <bo...@gmail.com> wrote:
>>>>>
>>>>> All the commits that removed deprecated factory methods it sounds like.
>>>>>
>>>>> On 6 September 2016 at 13:00, Gary Gregory <ga...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> On Tue, Sep 6, 2016 at 12:31 PM, Matt Sicker <bo...@gmail.com> wrot
>>>>>> e:
>>>>>>
>>>>>>> Should we revert those commits? There's still time.
>>>>>>>
>>>>>>
>>>>>> What commit? Do you mean to add back factory methods?
>>>>>>
>>>>>> Gary
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> On 3 September 2016 at 01:12, Ralph Goers <ralph.goers@dslextreme.
>>>>>>> com> wrote:
>>>>>>>
>>>>>>>> Perhaps we shouldn’t have.
>>>>>>>>
>>>>>>>> Ralph
>>>>>>>>
>>>>>>>> On Sep 2, 2016, at 7:46 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> We've already removed several deprecated factories in this upcoming
>>>>>>>> release, though.
>>>>>>>>
>>>>>>>> On 2 September 2016 at 06:28, Mikael Ståldal <mikael.staldal@magine
>>>>>>>> .com> wrote:
>>>>>>>>
>>>>>>>>> I agree with Remko, let's keep them unless they are in the way. We
>>>>>>>>> can remove all of them in Log4j 3.0.
>>>>>>>>>
>>>>>>>>> On Fri, Sep 2, 2016 at 1:31 AM, Remko Popma <remko.popma@gmail.com
>>>>>>>>> > wrote:
>>>>>>>>>
>>>>>>>>>> It was mentioned on a mailing list or twitter conversation with
>>>>>>>>>> maintainers of another Apache project that one of the reasons they hesitate
>>>>>>>>>> to migrate to Log4j is that they worry we will break binary compatibility.
>>>>>>>>>>
>>>>>>>>>> Removing the factory methods just because we deprecated them
>>>>>>>>>> seems a bit harsh.
>>>>>>>>>> It's not like it's a huge maintenance effort to keep them.
>>>>>>>>>>
>>>>>>>>>> I would not remove the deprecated factory methods unless they
>>>>>>>>>> actively prevent us from doing something we want to do.
>>>>>>>>>>
>>>>>>>>>> Remko
>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>
>>>>>>>>>> On 2016/09/02, at 6:29, Ralph Goers <ra...@dslextreme.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Well, Java seems to have a policy of waiting at least 10 years,
>>>>>>>>>> if ever….
>>>>>>>>>>
>>>>>>>>>> Seriously, I don’t think 1 minor release is enough as that might
>>>>>>>>>> very well be the next release. I’d say 2 minor releases and at least 6
>>>>>>>>>> months.
>>>>>>>>>>
>>>>>>>>>> Ralph
>>>>>>>>>>
>>>>>>>>>> On Sep 1, 2016, at 1:42 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> I think that when you add a builder and deprecate the factory,
>>>>>>>>>> you should remove it in the next 2.x release. Otherwise, deprecation has no
>>>>>>>>>> point if there's no version with the deprecation specified.
>>>>>>>>>>
>>>>>>>>>> On 1 September 2016 at 13:40, Gary Gregory <garydgregory@gmail.co
>>>>>>>>>> m> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> When can we delete factory methods that are deprecated by
>>>>>>>>>>> builders?
>>>>>>>>>>>
>>>>>>>>>>> Gary
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>>>>> <gg...@apache.org>
>>>>>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>>>>>> <http://www.manning.com/bauer3/>
>>>>>>>>>>> JUnit in Action, Second Edition
>>>>>>>>>>> <http://www.manning.com/tahchiev/>
>>>>>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>>>>> Home: http://garygregory.com/
>>>>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> [image: MagineTV]
>>>>>>>>>
>>>>>>>>> *Mikael Ståldal*
>>>>>>>>> Senior software developer
>>>>>>>>>
>>>>>>>>> *Magine TV*
>>>>>>>>> mikael.staldal@magine.com
>>>>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>>>>>>> <http://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.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>> <gg...@apache.org>
>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>> <http://www.manning.com/bauer3/>
>>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>> Blog: http://garygregory.wordpress.com
>>>>>> Home: http://garygregory.com/
>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker <bo...@gmail.com>
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> <gg...@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
>>
>>
>
>
> --
> 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
>
--
Matt Sicker <bo...@gmail.com>
Re: Deprecated factory methods replaced by builders.
Posted by Gary Gregory <ga...@gmail.com>.
I do not think NullOutputStream.NULL_OUTPUT_STREAM is a good example
because the Core util package is or should out of bounds for BC. I thought
we had "agreed" on that.
Gary
On Wed, Sep 7, 2016 at 5:29 PM, Remko Popma <re...@gmail.com> wrote:
> We should make an effort not to break compatibility unless it's
> unavoidable. There is usually a way to accomplish things without breaking
> BC.
>
> This is doubly true for plugins but should be our policy in general.
>
> We should not make breaking changes for aesthetic reasons. For example,
> NullOutputStream.NULL_OUTPUT_STREAM would have been better named
> INSTANCE, but this is one thing I would not change at this stage.
>
> One of the reasons people (I think on the Spark mailing list) mentioned
> for putting off upgrading from Log4j 1.2 to Log4j 2 was worries we would
> make breaking changes.
>
>
> Sent from my iPhone
>
> On 2016/09/08, at 8:03, Gary Gregory <ga...@gmail.com> wrote:
>
> On Wed, Sep 7, 2016 at 1:02 PM, Ralph Goers <ra...@dslextreme.com>
> wrote:
>
>> We really need to document what we want to strive to maintain
>> compatibility with in core. Basic components like Appenders and their
>> managers, Filters, Layouts, & Lookups or pretty much any Plugin type would
>> be at the top of my list.
>>
>
> Bleh, then we need to mark methods in some @tag-way in Javadocs.
>
> Gary
>
>>
>> Ralph
>>
>> On Sep 7, 2016, at 11:05 AM, Gary Gregory <ga...@gmail.com> wrote:
>>
>> On Wed, Sep 7, 2016 at 11:41 AM, Remko Popma <re...@gmail.com>
>> wrote:
>>
>>> We should do this before starting the 2.7 release.
>>> If we are serious about being the replacement for Log4j 1.2 we should
>>> not break user code for no good reason.
>>>
>>
>> What does this have to do with 1.2?
>>
>> Gary
>>
>>>
>>> On Wed, Sep 7, 2016 at 7:25 AM, Remko Popma <re...@gmail.com>
>>> wrote:
>>>
>>>> I think that would be good.
>>>>
>>>> Based on the number of Jira tickets being filed we are beginning to see
>>>> increased uptake. Programmatic configuration is used surprisingly often.
>>>> Leaving the factory methods in with some reasonable default for the missing
>>>> parameters ensures existing users can smoothly upgrade.
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On 2016/09/07, at 3:03, Matt Sicker <bo...@gmail.com> wrote:
>>>>
>>>> All the commits that removed deprecated factory methods it sounds like.
>>>>
>>>> On 6 September 2016 at 13:00, Gary Gregory <ga...@gmail.com>
>>>> wrote:
>>>>
>>>>> On Tue, Sep 6, 2016 at 12:31 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>
>>>>>> Should we revert those commits? There's still time.
>>>>>>
>>>>>
>>>>> What commit? Do you mean to add back factory methods?
>>>>>
>>>>> Gary
>>>>>
>>>>>
>>>>>>
>>>>>> On 3 September 2016 at 01:12, Ralph Goers <ralph.goers@dslextreme.com
>>>>>> > wrote:
>>>>>>
>>>>>>> Perhaps we shouldn’t have.
>>>>>>>
>>>>>>> Ralph
>>>>>>>
>>>>>>> On Sep 2, 2016, at 7:46 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>
>>>>>>> We've already removed several deprecated factories in this upcoming
>>>>>>> release, though.
>>>>>>>
>>>>>>> On 2 September 2016 at 06:28, Mikael Ståldal <mikael.staldal@magine
>>>>>>> .com> wrote:
>>>>>>>
>>>>>>>> I agree with Remko, let's keep them unless they are in the way. We
>>>>>>>> can remove all of them in Log4j 3.0.
>>>>>>>>
>>>>>>>> On Fri, Sep 2, 2016 at 1:31 AM, Remko Popma <re...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> It was mentioned on a mailing list or twitter conversation with
>>>>>>>>> maintainers of another Apache project that one of the reasons they hesitate
>>>>>>>>> to migrate to Log4j is that they worry we will break binary compatibility.
>>>>>>>>>
>>>>>>>>> Removing the factory methods just because we deprecated them
>>>>>>>>> seems a bit harsh.
>>>>>>>>> It's not like it's a huge maintenance effort to keep them.
>>>>>>>>>
>>>>>>>>> I would not remove the deprecated factory methods unless they
>>>>>>>>> actively prevent us from doing something we want to do.
>>>>>>>>>
>>>>>>>>> Remko
>>>>>>>>> Sent from my iPhone
>>>>>>>>>
>>>>>>>>> On 2016/09/02, at 6:29, Ralph Goers <ra...@dslextreme.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Well, Java seems to have a policy of waiting at least 10 years, if
>>>>>>>>> ever….
>>>>>>>>>
>>>>>>>>> Seriously, I don’t think 1 minor release is enough as that might
>>>>>>>>> very well be the next release. I’d say 2 minor releases and at least 6
>>>>>>>>> months.
>>>>>>>>>
>>>>>>>>> Ralph
>>>>>>>>>
>>>>>>>>> On Sep 1, 2016, at 1:42 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> I think that when you add a builder and deprecate the factory, you
>>>>>>>>> should remove it in the next 2.x release. Otherwise, deprecation has no
>>>>>>>>> point if there's no version with the deprecation specified.
>>>>>>>>>
>>>>>>>>> On 1 September 2016 at 13:40, Gary Gregory <garydgregory@gmail.com
>>>>>>>>> > wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> When can we delete factory methods that are deprecated by
>>>>>>>>>> builders?
>>>>>>>>>>
>>>>>>>>>> Gary
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>>>> <gg...@apache.org>
>>>>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>>>>> <http://www.manning.com/bauer3/>
>>>>>>>>>> JUnit in Action, Second Edition
>>>>>>>>>> <http://www.manning.com/tahchiev/>
>>>>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>>>> Home: http://garygregory.com/
>>>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> [image: MagineTV]
>>>>>>>>
>>>>>>>> *Mikael Ståldal*
>>>>>>>> Senior software developer
>>>>>>>>
>>>>>>>> *Magine TV*
>>>>>>>> mikael.staldal@magine.com
>>>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>>>>>> <http://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.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>> <gg...@apache.org>
>>>>> Java Persistence with Hibernate, Second Edition
>>>>> <http://www.manning.com/bauer3/>
>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>> Blog: http://garygregory.wordpress.com
>>>>> Home: http://garygregory.com/
>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <bo...@gmail.com>
>>>>
>>>>
>>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> <gg...@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
>
>
--
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: Deprecated factory methods replaced by builders.
Posted by Remko Popma <re...@gmail.com>.
We should make an effort not to break compatibility unless it's unavoidable. There is usually a way to accomplish things without breaking BC.
This is doubly true for plugins but should be our policy in general.
We should not make breaking changes for aesthetic reasons. For example, NullOutputStream.NULL_OUTPUT_STREAM would have been better named INSTANCE, but this is one thing I would not change at this stage.
One of the reasons people (I think on the Spark mailing list) mentioned for putting off upgrading from Log4j 1.2 to Log4j 2 was worries we would make breaking changes.
Sent from my iPhone
> On 2016/09/08, at 8:03, Gary Gregory <ga...@gmail.com> wrote:
>
>> On Wed, Sep 7, 2016 at 1:02 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>> We really need to document what we want to strive to maintain compatibility with in core. Basic components like Appenders and their managers, Filters, Layouts, & Lookups or pretty much any Plugin type would be at the top of my list.
>
> Bleh, then we need to mark methods in some @tag-way in Javadocs.
>
> Gary
>>
>> Ralph
>>
>>> On Sep 7, 2016, at 11:05 AM, Gary Gregory <ga...@gmail.com> wrote:
>>>
>>>> On Wed, Sep 7, 2016 at 11:41 AM, Remko Popma <re...@gmail.com> wrote:
>>>> We should do this before starting the 2.7 release.
>>>> If we are serious about being the replacement for Log4j 1.2 we should not break user code for no good reason.
>>>
>>> What does this have to do with 1.2?
>>>
>>> Gary
>>>>
>>>>> On Wed, Sep 7, 2016 at 7:25 AM, Remko Popma <re...@gmail.com> wrote:
>>>>> I think that would be good.
>>>>>
>>>>> Based on the number of Jira tickets being filed we are beginning to see increased uptake. Programmatic configuration is used surprisingly often. Leaving the factory methods in with some reasonable default for the missing parameters ensures existing users can smoothly upgrade.
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>>> On 2016/09/07, at 3:03, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>
>>>>>> All the commits that removed deprecated factory methods it sounds like.
>>>>>>
>>>>>>> On 6 September 2016 at 13:00, Gary Gregory <ga...@gmail.com> wrote:
>>>>>>>> On Tue, Sep 6, 2016 at 12:31 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>> Should we revert those commits? There's still time.
>>>>>>>
>>>>>>> What commit? Do you mean to add back factory methods?
>>>>>>>
>>>>>>> Gary
>>>>>>>
>>>>>>>>
>>>>>>>>> On 3 September 2016 at 01:12, Ralph Goers <ra...@dslextreme.com> wrote:
>>>>>>>>> Perhaps we shouldn’t have.
>>>>>>>>>
>>>>>>>>> Ralph
>>>>>>>>>
>>>>>>>>>> On Sep 2, 2016, at 7:46 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> We've already removed several deprecated factories in this upcoming release, though.
>>>>>>>>>>
>>>>>>>>>> On 2 September 2016 at 06:28, Mikael Ståldal <mi...@magine.com> wrote:
>>>>>>>>>>> I agree with Remko, let's keep them unless they are in the way. We can remove all of them in Log4j 3.0.
>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Sep 2, 2016 at 1:31 AM, Remko Popma <re...@gmail.com> wrote:
>>>>>>>>>>>> It was mentioned on a mailing list or twitter conversation with maintainers of another Apache project that one of the reasons they hesitate to migrate to Log4j is that they worry we will break binary compatibility.
>>>>>>>>>>>>
>>>>>>>>>>>> Removing the factory methods just because we deprecated them seems a bit harsh.
>>>>>>>>>>>> It's not like it's a huge maintenance effort to keep them.
>>>>>>>>>>>>
>>>>>>>>>>>> I would not remove the deprecated factory methods unless they actively prevent us from doing something we want to do.
>>>>>>>>>>>>
>>>>>>>>>>>> Remko
>>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>
>>>>>>>>>>>>> On 2016/09/02, at 6:29, Ralph Goers <ra...@dslextreme.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Well, Java seems to have a policy of waiting at least 10 years, if ever….
>>>>>>>>>>>>>
>>>>>>>>>>>>> Seriously, I don’t think 1 minor release is enough as that might very well be the next release. I’d say 2 minor releases and at least 6 months.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Sep 1, 2016, at 1:42 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I think that when you add a builder and deprecate the factory, you should remove it in the next 2.x release. Otherwise, deprecation has no point if there's no version with the deprecation specified.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 1 September 2016 at 13:40, Gary Gregory <ga...@gmail.com> wrote:
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> When can we delete factory methods that are deprecated by builders?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Mikael Ståldal
>>>>>>>>>>> Senior software developer
>>>>>>>>>>>
>>>>>>>>>>> Magine TV
>>>>>>>>>>> mikael.staldal@magine.com
>>>>>>>>>>> Grev Turegatan 3 | 114 46 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.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Matt Sicker <bo...@gmail.com>
>>>
>>>
>>>
>>> --
>>> 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: Deprecated factory methods replaced by builders.
Posted by Gary Gregory <ga...@gmail.com>.
On Wed, Sep 7, 2016 at 1:02 PM, Ralph Goers <ra...@dslextreme.com>
wrote:
> We really need to document what we want to strive to maintain
> compatibility with in core. Basic components like Appenders and their
> managers, Filters, Layouts, & Lookups or pretty much any Plugin type would
> be at the top of my list.
>
Bleh, then we need to mark methods in some @tag-way in Javadocs.
Gary
>
> Ralph
>
> On Sep 7, 2016, at 11:05 AM, Gary Gregory <ga...@gmail.com> wrote:
>
> On Wed, Sep 7, 2016 at 11:41 AM, Remko Popma <re...@gmail.com>
> wrote:
>
>> We should do this before starting the 2.7 release.
>> If we are serious about being the replacement for Log4j 1.2 we should not
>> break user code for no good reason.
>>
>
> What does this have to do with 1.2?
>
> Gary
>
>>
>> On Wed, Sep 7, 2016 at 7:25 AM, Remko Popma <re...@gmail.com>
>> wrote:
>>
>>> I think that would be good.
>>>
>>> Based on the number of Jira tickets being filed we are beginning to see
>>> increased uptake. Programmatic configuration is used surprisingly often.
>>> Leaving the factory methods in with some reasonable default for the missing
>>> parameters ensures existing users can smoothly upgrade.
>>>
>>> Sent from my iPhone
>>>
>>> On 2016/09/07, at 3:03, Matt Sicker <bo...@gmail.com> wrote:
>>>
>>> All the commits that removed deprecated factory methods it sounds like.
>>>
>>> On 6 September 2016 at 13:00, Gary Gregory <ga...@gmail.com>
>>> wrote:
>>>
>>>> On Tue, Sep 6, 2016 at 12:31 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>
>>>>> Should we revert those commits? There's still time.
>>>>>
>>>>
>>>> What commit? Do you mean to add back factory methods?
>>>>
>>>> Gary
>>>>
>>>>
>>>>>
>>>>> On 3 September 2016 at 01:12, Ralph Goers <ra...@dslextreme.com>
>>>>> wrote:
>>>>>
>>>>>> Perhaps we shouldn’t have.
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>> On Sep 2, 2016, at 7:46 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>
>>>>>> We've already removed several deprecated factories in this upcoming
>>>>>> release, though.
>>>>>>
>>>>>> On 2 September 2016 at 06:28, Mikael Ståldal <mikael.staldal@magine
>>>>>> .com> wrote:
>>>>>>
>>>>>>> I agree with Remko, let's keep them unless they are in the way. We
>>>>>>> can remove all of them in Log4j 3.0.
>>>>>>>
>>>>>>> On Fri, Sep 2, 2016 at 1:31 AM, Remko Popma <re...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> It was mentioned on a mailing list or twitter conversation with
>>>>>>>> maintainers of another Apache project that one of the reasons they hesitate
>>>>>>>> to migrate to Log4j is that they worry we will break binary compatibility.
>>>>>>>>
>>>>>>>> Removing the factory methods just because we deprecated them seems
>>>>>>>> a bit harsh.
>>>>>>>> It's not like it's a huge maintenance effort to keep them.
>>>>>>>>
>>>>>>>> I would not remove the deprecated factory methods unless they
>>>>>>>> actively prevent us from doing something we want to do.
>>>>>>>>
>>>>>>>> Remko
>>>>>>>> Sent from my iPhone
>>>>>>>>
>>>>>>>> On 2016/09/02, at 6:29, Ralph Goers <ra...@dslextreme.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Well, Java seems to have a policy of waiting at least 10 years, if
>>>>>>>> ever….
>>>>>>>>
>>>>>>>> Seriously, I don’t think 1 minor release is enough as that might
>>>>>>>> very well be the next release. I’d say 2 minor releases and at least 6
>>>>>>>> months.
>>>>>>>>
>>>>>>>> Ralph
>>>>>>>>
>>>>>>>> On Sep 1, 2016, at 1:42 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> I think that when you add a builder and deprecate the factory, you
>>>>>>>> should remove it in the next 2.x release. Otherwise, deprecation has no
>>>>>>>> point if there's no version with the deprecation specified.
>>>>>>>>
>>>>>>>> On 1 September 2016 at 13:40, Gary Gregory <ga...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> When can we delete factory methods that are deprecated by builders?
>>>>>>>>>
>>>>>>>>> Gary
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>>> <gg...@apache.org>
>>>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>>>> <http://www.manning.com/bauer3/>
>>>>>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>>> Home: http://garygregory.com/
>>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> [image: MagineTV]
>>>>>>>
>>>>>>> *Mikael Ståldal*
>>>>>>> Senior software developer
>>>>>>>
>>>>>>> *Magine TV*
>>>>>>> mikael.staldal@magine.com
>>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>>>>> <http://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.
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker <bo...@gmail.com>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>> <gg...@apache.org>
>>>> Java Persistence with Hibernate, Second Edition
>>>> <http://www.manning.com/bauer3/>
>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>> Blog: http://garygregory.wordpress.com
>>>> Home: http://garygregory.com/
>>>> Tweet! http://twitter.com/GaryGregory
>>>>
>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>>
>>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> <gg...@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: Deprecated factory methods replaced by builders.
Posted by Ralph Goers <ra...@dslextreme.com>.
We really need to document what we want to strive to maintain compatibility with in core. Basic components like Appenders and their managers, Filters, Layouts, & Lookups or pretty much any Plugin type would be at the top of my list.
Ralph
> On Sep 7, 2016, at 11:05 AM, Gary Gregory <ga...@gmail.com> wrote:
>
> On Wed, Sep 7, 2016 at 11:41 AM, Remko Popma <remko.popma@gmail.com <ma...@gmail.com>> wrote:
> We should do this before starting the 2.7 release.
> If we are serious about being the replacement for Log4j 1.2 we should not break user code for no good reason.
>
> What does this have to do with 1.2?
>
> Gary
>
> On Wed, Sep 7, 2016 at 7:25 AM, Remko Popma <remko.popma@gmail.com <ma...@gmail.com>> wrote:
> I think that would be good.
>
> Based on the number of Jira tickets being filed we are beginning to see increased uptake. Programmatic configuration is used surprisingly often. Leaving the factory methods in with some reasonable default for the missing parameters ensures existing users can smoothly upgrade.
>
> Sent from my iPhone
>
> On 2016/09/07, at 3:03, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>
>> All the commits that removed deprecated factory methods it sounds like.
>>
>> On 6 September 2016 at 13:00, Gary Gregory <garydgregory@gmail.com <ma...@gmail.com>> wrote:
>> On Tue, Sep 6, 2016 at 12:31 PM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>> Should we revert those commits? There's still time.
>>
>> What commit? Do you mean to add back factory methods?
>>
>> Gary
>>
>>
>> On 3 September 2016 at 01:12, Ralph Goers <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>> Perhaps we shouldn’t have.
>>
>> Ralph
>>
>>> On Sep 2, 2016, at 7:46 PM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>>>
>>> We've already removed several deprecated factories in this upcoming release, though.
>>>
>>> On 2 September 2016 at 06:28, Mikael Ståldal <mikael.staldal@magine.com <ma...@magine.com>> wrote:
>>> I agree with Remko, let's keep them unless they are in the way. We can remove all of them in Log4j 3.0.
>>>
>>> On Fri, Sep 2, 2016 at 1:31 AM, Remko Popma <remko.popma@gmail.com <ma...@gmail.com>> wrote:
>>> It was mentioned on a mailing list or twitter conversation with maintainers of another Apache project that one of the reasons they hesitate to migrate to Log4j is that they worry we will break binary compatibility.
>>>
>>> Removing the factory methods just because we deprecated them seems a bit harsh.
>>> It's not like it's a huge maintenance effort to keep them.
>>>
>>> I would not remove the deprecated factory methods unless they actively prevent us from doing something we want to do.
>>>
>>> Remko
>>> Sent from my iPhone
>>>
>>> On 2016/09/02, at 6:29, Ralph Goers <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>>>
>>>> Well, Java seems to have a policy of waiting at least 10 years, if ever….
>>>>
>>>> Seriously, I don’t think 1 minor release is enough as that might very well be the next release. I’d say 2 minor releases and at least 6 months.
>>>>
>>>> Ralph
>>>>
>>>>> On Sep 1, 2016, at 1:42 PM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>>>>>
>>>>> I think that when you add a builder and deprecate the factory, you should remove it in the next 2.x release. Otherwise, deprecation has no point if there's no version with the deprecation specified.
>>>>>
>>>>> On 1 September 2016 at 13:40, Gary Gregory <garydgregory@gmail.com <ma...@gmail.com>> wrote:
>>>>> Hi,
>>>>>
>>>>> When can we delete factory methods that are deprecated by builders?
>>>>>
>>>>> 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>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>>>
>>>
>>>
>>>
>>> --
>>>
>>>
>>> Mikael Ståldal
>>> Senior software developer
>>>
>>> Magine TV
>>> mikael.staldal@magine.com <ma...@magine.com>
>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com <http://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.
>>>
>>>
>>>
>>> --
>>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>
>>
>>
>>
>> --
>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>
>>
>>
>> --
>> 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>
>>
>>
>> --
>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>
>
>
>
> --
> 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: Deprecated factory methods replaced by builders.
Posted by Gary Gregory <ga...@gmail.com>.
On Wed, Sep 7, 2016 at 11:41 AM, Remko Popma <re...@gmail.com> wrote:
> We should do this before starting the 2.7 release.
> If we are serious about being the replacement for Log4j 1.2 we should not
> break user code for no good reason.
>
What does this have to do with 1.2?
Gary
>
> On Wed, Sep 7, 2016 at 7:25 AM, Remko Popma <re...@gmail.com> wrote:
>
>> I think that would be good.
>>
>> Based on the number of Jira tickets being filed we are beginning to see
>> increased uptake. Programmatic configuration is used surprisingly often.
>> Leaving the factory methods in with some reasonable default for the missing
>> parameters ensures existing users can smoothly upgrade.
>>
>> Sent from my iPhone
>>
>> On 2016/09/07, at 3:03, Matt Sicker <bo...@gmail.com> wrote:
>>
>> All the commits that removed deprecated factory methods it sounds like.
>>
>> On 6 September 2016 at 13:00, Gary Gregory <ga...@gmail.com>
>> wrote:
>>
>>> On Tue, Sep 6, 2016 at 12:31 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>
>>>> Should we revert those commits? There's still time.
>>>>
>>>
>>> What commit? Do you mean to add back factory methods?
>>>
>>> Gary
>>>
>>>
>>>>
>>>> On 3 September 2016 at 01:12, Ralph Goers <ra...@dslextreme.com>
>>>> wrote:
>>>>
>>>>> Perhaps we shouldn’t have.
>>>>>
>>>>> Ralph
>>>>>
>>>>> On Sep 2, 2016, at 7:46 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>
>>>>> We've already removed several deprecated factories in this upcoming
>>>>> release, though.
>>>>>
>>>>> On 2 September 2016 at 06:28, Mikael Ståldal <mikael.staldal@magine
>>>>> .com> wrote:
>>>>>
>>>>>> I agree with Remko, let's keep them unless they are in the way. We
>>>>>> can remove all of them in Log4j 3.0.
>>>>>>
>>>>>> On Fri, Sep 2, 2016 at 1:31 AM, Remko Popma <re...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> It was mentioned on a mailing list or twitter conversation with
>>>>>>> maintainers of another Apache project that one of the reasons they hesitate
>>>>>>> to migrate to Log4j is that they worry we will break binary compatibility.
>>>>>>>
>>>>>>> Removing the factory methods just because we deprecated them seems
>>>>>>> a bit harsh.
>>>>>>> It's not like it's a huge maintenance effort to keep them.
>>>>>>>
>>>>>>> I would not remove the deprecated factory methods unless they
>>>>>>> actively prevent us from doing something we want to do.
>>>>>>>
>>>>>>> Remko
>>>>>>> Sent from my iPhone
>>>>>>>
>>>>>>> On 2016/09/02, at 6:29, Ralph Goers <ra...@dslextreme.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Well, Java seems to have a policy of waiting at least 10 years, if
>>>>>>> ever….
>>>>>>>
>>>>>>> Seriously, I don’t think 1 minor release is enough as that might
>>>>>>> very well be the next release. I’d say 2 minor releases and at least 6
>>>>>>> months.
>>>>>>>
>>>>>>> Ralph
>>>>>>>
>>>>>>> On Sep 1, 2016, at 1:42 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>
>>>>>>> I think that when you add a builder and deprecate the factory, you
>>>>>>> should remove it in the next 2.x release. Otherwise, deprecation has no
>>>>>>> point if there's no version with the deprecation specified.
>>>>>>>
>>>>>>> On 1 September 2016 at 13:40, Gary Gregory <ga...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> When can we delete factory methods that are deprecated by builders?
>>>>>>>>
>>>>>>>> Gary
>>>>>>>>
>>>>>>>> --
>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>> <gg...@apache.org>
>>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>>> <http://www.manning.com/bauer3/>
>>>>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>> Home: http://garygregory.com/
>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> [image: MagineTV]
>>>>>>
>>>>>> *Mikael Ståldal*
>>>>>> Senior software developer
>>>>>>
>>>>>> *Magine TV*
>>>>>> mikael.staldal@magine.com
>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>>>> <http://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.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker <bo...@gmail.com>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <bo...@gmail.com>
>>>>
>>>
>>>
>>>
>>> --
>>> 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
>>>
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>>
>
--
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: Deprecated factory methods replaced by builders.
Posted by Remko Popma <re...@gmail.com>.
We should do this before starting the 2.7 release.
If we are serious about being the replacement for Log4j 1.2 we should not
break user code for no good reason.
On Wed, Sep 7, 2016 at 7:25 AM, Remko Popma <re...@gmail.com> wrote:
> I think that would be good.
>
> Based on the number of Jira tickets being filed we are beginning to see
> increased uptake. Programmatic configuration is used surprisingly often.
> Leaving the factory methods in with some reasonable default for the missing
> parameters ensures existing users can smoothly upgrade.
>
> Sent from my iPhone
>
> On 2016/09/07, at 3:03, Matt Sicker <bo...@gmail.com> wrote:
>
> All the commits that removed deprecated factory methods it sounds like.
>
> On 6 September 2016 at 13:00, Gary Gregory <ga...@gmail.com> wrote:
>
>> On Tue, Sep 6, 2016 at 12:31 PM, Matt Sicker <bo...@gmail.com> wrote:
>>
>>> Should we revert those commits? There's still time.
>>>
>>
>> What commit? Do you mean to add back factory methods?
>>
>> Gary
>>
>>
>>>
>>> On 3 September 2016 at 01:12, Ralph Goers <ra...@dslextreme.com>
>>> wrote:
>>>
>>>> Perhaps we shouldn’t have.
>>>>
>>>> Ralph
>>>>
>>>> On Sep 2, 2016, at 7:46 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>
>>>> We've already removed several deprecated factories in this upcoming
>>>> release, though.
>>>>
>>>> On 2 September 2016 at 06:28, Mikael Ståldal <mikael.staldal@magine.com
>>>> > wrote:
>>>>
>>>>> I agree with Remko, let's keep them unless they are in the way. We can
>>>>> remove all of them in Log4j 3.0.
>>>>>
>>>>> On Fri, Sep 2, 2016 at 1:31 AM, Remko Popma <re...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> It was mentioned on a mailing list or twitter conversation with
>>>>>> maintainers of another Apache project that one of the reasons they hesitate
>>>>>> to migrate to Log4j is that they worry we will break binary compatibility.
>>>>>>
>>>>>> Removing the factory methods just because we deprecated them seems a
>>>>>> bit harsh.
>>>>>> It's not like it's a huge maintenance effort to keep them.
>>>>>>
>>>>>> I would not remove the deprecated factory methods unless they
>>>>>> actively prevent us from doing something we want to do.
>>>>>>
>>>>>> Remko
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> On 2016/09/02, at 6:29, Ralph Goers <ra...@dslextreme.com>
>>>>>> wrote:
>>>>>>
>>>>>> Well, Java seems to have a policy of waiting at least 10 years, if
>>>>>> ever….
>>>>>>
>>>>>> Seriously, I don’t think 1 minor release is enough as that might very
>>>>>> well be the next release. I’d say 2 minor releases and at least 6 months.
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>> On Sep 1, 2016, at 1:42 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>
>>>>>> I think that when you add a builder and deprecate the factory, you
>>>>>> should remove it in the next 2.x release. Otherwise, deprecation has no
>>>>>> point if there's no version with the deprecation specified.
>>>>>>
>>>>>> On 1 September 2016 at 13:40, Gary Gregory <ga...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> When can we delete factory methods that are deprecated by builders?
>>>>>>>
>>>>>>> Gary
>>>>>>>
>>>>>>> --
>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>> <gg...@apache.org>
>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>> <http://www.manning.com/bauer3/>
>>>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>> Home: http://garygregory.com/
>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> [image: MagineTV]
>>>>>
>>>>> *Mikael Ståldal*
>>>>> Senior software developer
>>>>>
>>>>> *Magine TV*
>>>>> mikael.staldal@magine.com
>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>>> <http://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.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <bo...@gmail.com>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>>
>>
>>
>>
>> --
>> 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
>>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
>
Re: Deprecated factory methods replaced by builders.
Posted by Remko Popma <re...@gmail.com>.
I think that would be good.
Based on the number of Jira tickets being filed we are beginning to see increased uptake. Programmatic configuration is used surprisingly often. Leaving the factory methods in with some reasonable default for the missing parameters ensures existing users can smoothly upgrade.
Sent from my iPhone
> On 2016/09/07, at 3:03, Matt Sicker <bo...@gmail.com> wrote:
>
> All the commits that removed deprecated factory methods it sounds like.
>
>> On 6 September 2016 at 13:00, Gary Gregory <ga...@gmail.com> wrote:
>>> On Tue, Sep 6, 2016 at 12:31 PM, Matt Sicker <bo...@gmail.com> wrote:
>>> Should we revert those commits? There's still time.
>>
>> What commit? Do you mean to add back factory methods?
>>
>> Gary
>>
>>>
>>>> On 3 September 2016 at 01:12, Ralph Goers <ra...@dslextreme.com> wrote:
>>>> Perhaps we shouldn’t have.
>>>>
>>>> Ralph
>>>>
>>>>> On Sep 2, 2016, at 7:46 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>
>>>>> We've already removed several deprecated factories in this upcoming release, though.
>>>>>
>>>>> On 2 September 2016 at 06:28, Mikael Ståldal <mi...@magine.com> wrote:
>>>>>> I agree with Remko, let's keep them unless they are in the way. We can remove all of them in Log4j 3.0.
>>>>>>
>>>>>>> On Fri, Sep 2, 2016 at 1:31 AM, Remko Popma <re...@gmail.com> wrote:
>>>>>>> It was mentioned on a mailing list or twitter conversation with maintainers of another Apache project that one of the reasons they hesitate to migrate to Log4j is that they worry we will break binary compatibility.
>>>>>>>
>>>>>>> Removing the factory methods just because we deprecated them seems a bit harsh.
>>>>>>> It's not like it's a huge maintenance effort to keep them.
>>>>>>>
>>>>>>> I would not remove the deprecated factory methods unless they actively prevent us from doing something we want to do.
>>>>>>>
>>>>>>> Remko
>>>>>>> Sent from my iPhone
>>>>>>>
>>>>>>>> On 2016/09/02, at 6:29, Ralph Goers <ra...@dslextreme.com> wrote:
>>>>>>>>
>>>>>>>> Well, Java seems to have a policy of waiting at least 10 years, if ever….
>>>>>>>>
>>>>>>>> Seriously, I don’t think 1 minor release is enough as that might very well be the next release. I’d say 2 minor releases and at least 6 months.
>>>>>>>>
>>>>>>>> Ralph
>>>>>>>>
>>>>>>>>> On Sep 1, 2016, at 1:42 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> I think that when you add a builder and deprecate the factory, you should remove it in the next 2.x release. Otherwise, deprecation has no point if there's no version with the deprecation specified.
>>>>>>>>>
>>>>>>>>> On 1 September 2016 at 13:40, Gary Gregory <ga...@gmail.com> wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> When can we delete factory methods that are deprecated by builders?
>>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>>
>>>>>> Mikael Ståldal
>>>>>> Senior software developer
>>>>>>
>>>>>> Magine TV
>>>>>> mikael.staldal@magine.com
>>>>>> Grev Turegatan 3 | 114 46 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.
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker <bo...@gmail.com>
>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>
>>
>>
>>
>> --
>> 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
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
Re: Deprecated factory methods replaced by builders.
Posted by Matt Sicker <bo...@gmail.com>.
All the commits that removed deprecated factory methods it sounds like.
On 6 September 2016 at 13:00, Gary Gregory <ga...@gmail.com> wrote:
> On Tue, Sep 6, 2016 at 12:31 PM, Matt Sicker <bo...@gmail.com> wrote:
>
>> Should we revert those commits? There's still time.
>>
>
> What commit? Do you mean to add back factory methods?
>
> Gary
>
>
>>
>> On 3 September 2016 at 01:12, Ralph Goers <ra...@dslextreme.com>
>> wrote:
>>
>>> Perhaps we shouldn’t have.
>>>
>>> Ralph
>>>
>>> On Sep 2, 2016, at 7:46 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>
>>> We've already removed several deprecated factories in this upcoming
>>> release, though.
>>>
>>> On 2 September 2016 at 06:28, Mikael Ståldal <mi...@magine.com>
>>> wrote:
>>>
>>>> I agree with Remko, let's keep them unless they are in the way. We can
>>>> remove all of them in Log4j 3.0.
>>>>
>>>> On Fri, Sep 2, 2016 at 1:31 AM, Remko Popma <re...@gmail.com>
>>>> wrote:
>>>>
>>>>> It was mentioned on a mailing list or twitter conversation with
>>>>> maintainers of another Apache project that one of the reasons they hesitate
>>>>> to migrate to Log4j is that they worry we will break binary compatibility.
>>>>>
>>>>> Removing the factory methods just because we deprecated them seems a
>>>>> bit harsh.
>>>>> It's not like it's a huge maintenance effort to keep them.
>>>>>
>>>>> I would not remove the deprecated factory methods unless they actively
>>>>> prevent us from doing something we want to do.
>>>>>
>>>>> Remko
>>>>> Sent from my iPhone
>>>>>
>>>>> On 2016/09/02, at 6:29, Ralph Goers <ra...@dslextreme.com>
>>>>> wrote:
>>>>>
>>>>> Well, Java seems to have a policy of waiting at least 10 years, if
>>>>> ever….
>>>>>
>>>>> Seriously, I don’t think 1 minor release is enough as that might very
>>>>> well be the next release. I’d say 2 minor releases and at least 6 months.
>>>>>
>>>>> Ralph
>>>>>
>>>>> On Sep 1, 2016, at 1:42 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>
>>>>> I think that when you add a builder and deprecate the factory, you
>>>>> should remove it in the next 2.x release. Otherwise, deprecation has no
>>>>> point if there's no version with the deprecation specified.
>>>>>
>>>>> On 1 September 2016 at 13:40, Gary Gregory <ga...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> When can we delete factory methods that are deprecated by builders?
>>>>>>
>>>>>> Gary
>>>>>>
>>>>>> --
>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>> <gg...@apache.org>
>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>> <http://www.manning.com/bauer3/>
>>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>> Blog: http://garygregory.wordpress.com
>>>>>> Home: http://garygregory.com/
>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker <bo...@gmail.com>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> [image: MagineTV]
>>>>
>>>> *Mikael Ståldal*
>>>> Senior software developer
>>>>
>>>> *Magine TV*
>>>> mikael.staldal@magine.com
>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>> <http://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.
>>>>
>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>>
>>>
>>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>
>
>
> --
> 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
>
--
Matt Sicker <bo...@gmail.com>
Re: Deprecated factory methods replaced by builders.
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Sep 6, 2016 at 12:31 PM, Matt Sicker <bo...@gmail.com> wrote:
> Should we revert those commits? There's still time.
>
What commit? Do you mean to add back factory methods?
Gary
>
> On 3 September 2016 at 01:12, Ralph Goers <ra...@dslextreme.com>
> wrote:
>
>> Perhaps we shouldn’t have.
>>
>> Ralph
>>
>> On Sep 2, 2016, at 7:46 PM, Matt Sicker <bo...@gmail.com> wrote:
>>
>> We've already removed several deprecated factories in this upcoming
>> release, though.
>>
>> On 2 September 2016 at 06:28, Mikael Ståldal <mi...@magine.com>
>> wrote:
>>
>>> I agree with Remko, let's keep them unless they are in the way. We can
>>> remove all of them in Log4j 3.0.
>>>
>>> On Fri, Sep 2, 2016 at 1:31 AM, Remko Popma <re...@gmail.com>
>>> wrote:
>>>
>>>> It was mentioned on a mailing list or twitter conversation with
>>>> maintainers of another Apache project that one of the reasons they hesitate
>>>> to migrate to Log4j is that they worry we will break binary compatibility.
>>>>
>>>> Removing the factory methods just because we deprecated them seems a
>>>> bit harsh.
>>>> It's not like it's a huge maintenance effort to keep them.
>>>>
>>>> I would not remove the deprecated factory methods unless they actively
>>>> prevent us from doing something we want to do.
>>>>
>>>> Remko
>>>> Sent from my iPhone
>>>>
>>>> On 2016/09/02, at 6:29, Ralph Goers <ra...@dslextreme.com> wrote:
>>>>
>>>> Well, Java seems to have a policy of waiting at least 10 years, if
>>>> ever….
>>>>
>>>> Seriously, I don’t think 1 minor release is enough as that might very
>>>> well be the next release. I’d say 2 minor releases and at least 6 months.
>>>>
>>>> Ralph
>>>>
>>>> On Sep 1, 2016, at 1:42 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>
>>>> I think that when you add a builder and deprecate the factory, you
>>>> should remove it in the next 2.x release. Otherwise, deprecation has no
>>>> point if there's no version with the deprecation specified.
>>>>
>>>> On 1 September 2016 at 13:40, Gary Gregory <ga...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> When can we delete factory methods that are deprecated by builders?
>>>>>
>>>>> Gary
>>>>>
>>>>> --
>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>> <gg...@apache.org>
>>>>> Java Persistence with Hibernate, Second Edition
>>>>> <http://www.manning.com/bauer3/>
>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>> Blog: http://garygregory.wordpress.com
>>>>> Home: http://garygregory.com/
>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <bo...@gmail.com>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> [image: MagineTV]
>>>
>>> *Mikael Ståldal*
>>> Senior software developer
>>>
>>> *Magine TV*
>>> mikael.staldal@magine.com
>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>> <http://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.
>>>
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>>
>>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
--
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: Deprecated factory methods replaced by builders.
Posted by Matt Sicker <bo...@gmail.com>.
Should we revert those commits? There's still time.
On 3 September 2016 at 01:12, Ralph Goers <ra...@dslextreme.com>
wrote:
> Perhaps we shouldn’t have.
>
> Ralph
>
> On Sep 2, 2016, at 7:46 PM, Matt Sicker <bo...@gmail.com> wrote:
>
> We've already removed several deprecated factories in this upcoming
> release, though.
>
> On 2 September 2016 at 06:28, Mikael Ståldal <mi...@magine.com>
> wrote:
>
>> I agree with Remko, let's keep them unless they are in the way. We can
>> remove all of them in Log4j 3.0.
>>
>> On Fri, Sep 2, 2016 at 1:31 AM, Remko Popma <re...@gmail.com>
>> wrote:
>>
>>> It was mentioned on a mailing list or twitter conversation with
>>> maintainers of another Apache project that one of the reasons they hesitate
>>> to migrate to Log4j is that they worry we will break binary compatibility.
>>>
>>> Removing the factory methods just because we deprecated them seems a
>>> bit harsh.
>>> It's not like it's a huge maintenance effort to keep them.
>>>
>>> I would not remove the deprecated factory methods unless they actively
>>> prevent us from doing something we want to do.
>>>
>>> Remko
>>> Sent from my iPhone
>>>
>>> On 2016/09/02, at 6:29, Ralph Goers <ra...@dslextreme.com> wrote:
>>>
>>> Well, Java seems to have a policy of waiting at least 10 years, if ever….
>>>
>>> Seriously, I don’t think 1 minor release is enough as that might very
>>> well be the next release. I’d say 2 minor releases and at least 6 months.
>>>
>>> Ralph
>>>
>>> On Sep 1, 2016, at 1:42 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>
>>> I think that when you add a builder and deprecate the factory, you
>>> should remove it in the next 2.x release. Otherwise, deprecation has no
>>> point if there's no version with the deprecation specified.
>>>
>>> On 1 September 2016 at 13:40, Gary Gregory <ga...@gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> When can we delete factory methods that are deprecated by builders?
>>>>
>>>> Gary
>>>>
>>>> --
>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>> <gg...@apache.org>
>>>> Java Persistence with Hibernate, Second Edition
>>>> <http://www.manning.com/bauer3/>
>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>> Blog: http://garygregory.wordpress.com
>>>> Home: http://garygregory.com/
>>>> Tweet! http://twitter.com/GaryGregory
>>>>
>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>>
>>>
>>>
>>
>>
>> --
>> [image: MagineTV]
>>
>> *Mikael Ståldal*
>> Senior software developer
>>
>> *Magine TV*
>> mikael.staldal@magine.com
>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>> <http://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.
>>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
>
>
--
Matt Sicker <bo...@gmail.com>
Re: Deprecated factory methods replaced by builders.
Posted by Ralph Goers <ra...@dslextreme.com>.
Perhaps we shouldn’t have.
Ralph
> On Sep 2, 2016, at 7:46 PM, Matt Sicker <bo...@gmail.com> wrote:
>
> We've already removed several deprecated factories in this upcoming release, though.
>
> On 2 September 2016 at 06:28, Mikael Ståldal <mikael.staldal@magine.com <ma...@magine.com>> wrote:
> I agree with Remko, let's keep them unless they are in the way. We can remove all of them in Log4j 3.0.
>
> On Fri, Sep 2, 2016 at 1:31 AM, Remko Popma <remko.popma@gmail.com <ma...@gmail.com>> wrote:
> It was mentioned on a mailing list or twitter conversation with maintainers of another Apache project that one of the reasons they hesitate to migrate to Log4j is that they worry we will break binary compatibility.
>
> Removing the factory methods just because we deprecated them seems a bit harsh.
> It's not like it's a huge maintenance effort to keep them.
>
> I would not remove the deprecated factory methods unless they actively prevent us from doing something we want to do.
>
> Remko
> Sent from my iPhone
>
> On 2016/09/02, at 6:29, Ralph Goers <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>
>> Well, Java seems to have a policy of waiting at least 10 years, if ever….
>>
>> Seriously, I don’t think 1 minor release is enough as that might very well be the next release. I’d say 2 minor releases and at least 6 months.
>>
>> Ralph
>>
>>> On Sep 1, 2016, at 1:42 PM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>>>
>>> I think that when you add a builder and deprecate the factory, you should remove it in the next 2.x release. Otherwise, deprecation has no point if there's no version with the deprecation specified.
>>>
>>> On 1 September 2016 at 13:40, Gary Gregory <garydgregory@gmail.com <ma...@gmail.com>> wrote:
>>> Hi,
>>>
>>> When can we delete factory methods that are deprecated by builders?
>>>
>>> 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>
>>>
>>>
>>> --
>>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>
>
>
>
> --
>
>
> Mikael Ståldal
> Senior software developer
>
> Magine TV
> mikael.staldal@magine.com <ma...@magine.com>
> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com <http://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.
>
>
>
> --
> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
Re: Deprecated factory methods replaced by builders.
Posted by Matt Sicker <bo...@gmail.com>.
We've already removed several deprecated factories in this upcoming
release, though.
On 2 September 2016 at 06:28, Mikael Ståldal <mi...@magine.com>
wrote:
> I agree with Remko, let's keep them unless they are in the way. We can
> remove all of them in Log4j 3.0.
>
> On Fri, Sep 2, 2016 at 1:31 AM, Remko Popma <re...@gmail.com> wrote:
>
>> It was mentioned on a mailing list or twitter conversation with
>> maintainers of another Apache project that one of the reasons they hesitate
>> to migrate to Log4j is that they worry we will break binary compatibility.
>>
>> Removing the factory methods just because we deprecated them seems a bit
>> harsh.
>> It's not like it's a huge maintenance effort to keep them.
>>
>> I would not remove the deprecated factory methods unless they actively
>> prevent us from doing something we want to do.
>>
>> Remko
>> Sent from my iPhone
>>
>> On 2016/09/02, at 6:29, Ralph Goers <ra...@dslextreme.com> wrote:
>>
>> Well, Java seems to have a policy of waiting at least 10 years, if ever….
>>
>> Seriously, I don’t think 1 minor release is enough as that might very
>> well be the next release. I’d say 2 minor releases and at least 6 months.
>>
>> Ralph
>>
>> On Sep 1, 2016, at 1:42 PM, Matt Sicker <bo...@gmail.com> wrote:
>>
>> I think that when you add a builder and deprecate the factory, you should
>> remove it in the next 2.x release. Otherwise, deprecation has no point if
>> there's no version with the deprecation specified.
>>
>> On 1 September 2016 at 13:40, Gary Gregory <ga...@gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> When can we delete factory methods that are deprecated by builders?
>>>
>>> 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
>>>
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>>
>>
>
>
> --
> [image: MagineTV]
>
> *Mikael Ståldal*
> Senior software developer
>
> *Magine TV*
> mikael.staldal@magine.com
> Grev Turegatan 3 | 114 46 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.
>
--
Matt Sicker <bo...@gmail.com>
Re: Deprecated factory methods replaced by builders.
Posted by Mikael Ståldal <mi...@magine.com>.
I agree with Remko, let's keep them unless they are in the way. We can
remove all of them in Log4j 3.0.
On Fri, Sep 2, 2016 at 1:31 AM, Remko Popma <re...@gmail.com> wrote:
> It was mentioned on a mailing list or twitter conversation with
> maintainers of another Apache project that one of the reasons they hesitate
> to migrate to Log4j is that they worry we will break binary compatibility.
>
> Removing the factory methods just because we deprecated them seems a bit
> harsh.
> It's not like it's a huge maintenance effort to keep them.
>
> I would not remove the deprecated factory methods unless they actively
> prevent us from doing something we want to do.
>
> Remko
> Sent from my iPhone
>
> On 2016/09/02, at 6:29, Ralph Goers <ra...@dslextreme.com> wrote:
>
> Well, Java seems to have a policy of waiting at least 10 years, if ever….
>
> Seriously, I don’t think 1 minor release is enough as that might very well
> be the next release. I’d say 2 minor releases and at least 6 months.
>
> Ralph
>
> On Sep 1, 2016, at 1:42 PM, Matt Sicker <bo...@gmail.com> wrote:
>
> I think that when you add a builder and deprecate the factory, you should
> remove it in the next 2.x release. Otherwise, deprecation has no point if
> there's no version with the deprecation specified.
>
> On 1 September 2016 at 13:40, Gary Gregory <ga...@gmail.com> wrote:
>
>> Hi,
>>
>> When can we delete factory methods that are deprecated by builders?
>>
>> 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
>>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
>
>
--
[image: MagineTV]
*Mikael Ståldal*
Senior software developer
*Magine TV*
mikael.staldal@magine.com
Grev Turegatan 3 | 114 46 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: Deprecated factory methods replaced by builders.
Posted by Remko Popma <re...@gmail.com>.
It was mentioned on a mailing list or twitter conversation with maintainers of another Apache project that one of the reasons they hesitate to migrate to Log4j is that they worry we will break binary compatibility.
Removing the factory methods just because we deprecated them seems a bit harsh.
It's not like it's a huge maintenance effort to keep them.
I would not remove the deprecated factory methods unless they actively prevent us from doing something we want to do.
Remko
Sent from my iPhone
> On 2016/09/02, at 6:29, Ralph Goers <ra...@dslextreme.com> wrote:
>
> Well, Java seems to have a policy of waiting at least 10 years, if ever….
>
> Seriously, I don’t think 1 minor release is enough as that might very well be the next release. I’d say 2 minor releases and at least 6 months.
>
> Ralph
>
>> On Sep 1, 2016, at 1:42 PM, Matt Sicker <bo...@gmail.com> wrote:
>>
>> I think that when you add a builder and deprecate the factory, you should remove it in the next 2.x release. Otherwise, deprecation has no point if there's no version with the deprecation specified.
>>
>> On 1 September 2016 at 13:40, Gary Gregory <ga...@gmail.com> wrote:
>>> Hi,
>>>
>>> When can we delete factory methods that are deprecated by builders?
>>>
>>> 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
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>
Re: Deprecated factory methods replaced by builders.
Posted by Ralph Goers <ra...@dslextreme.com>.
Well, Java seems to have a policy of waiting at least 10 years, if ever….
Seriously, I don’t think 1 minor release is enough as that might very well be the next release. I’d say 2 minor releases and at least 6 months.
Ralph
> On Sep 1, 2016, at 1:42 PM, Matt Sicker <bo...@gmail.com> wrote:
>
> I think that when you add a builder and deprecate the factory, you should remove it in the next 2.x release. Otherwise, deprecation has no point if there's no version with the deprecation specified.
>
> On 1 September 2016 at 13:40, Gary Gregory <garydgregory@gmail.com <ma...@gmail.com>> wrote:
> Hi,
>
> When can we delete factory methods that are deprecated by builders?
>
> 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>
>
>
> --
> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
Re: Deprecated factory methods replaced by builders.
Posted by Matt Sicker <bo...@gmail.com>.
I think that when you add a builder and deprecate the factory, you should
remove it in the next 2.x release. Otherwise, deprecation has no point if
there's no version with the deprecation specified.
On 1 September 2016 at 13:40, Gary Gregory <ga...@gmail.com> wrote:
> Hi,
>
> When can we delete factory methods that are deprecated by builders?
>
> 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
>
--
Matt Sicker <bo...@gmail.com>