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 <garydgreg...@gmail.com> wrote: > > What about code in the Core util package? > > Gary > >> On Wed, Sep 7, 2016 at 10:06 PM, Ralph Goers <ralph.go...@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 <garydgreg...@gmail.com> wrote: >>> >>>> On Wed, Sep 7, 2016 at 9:17 PM, Remko Popma <remko.po...@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 <boa...@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 <garydgreg...@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.po...@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 <garydgreg...@gmail.com> wrote: >>>>>>>> >>>>>>>>> On Wed, Sep 7, 2016 at 1:02 PM, Ralph Goers >>>>>>>>> <ralph.go...@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 <garydgreg...@gmail.com> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> On Wed, Sep 7, 2016 at 11:41 AM, Remko Popma >>>>>>>>>>> <remko.po...@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.po...@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 <boa...@gmail.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> All the commits that removed deprecated factory methods it sounds >>>>>>>>>>>>> like. >>>>>>>>>>>>> >>>>>>>>>>>>>> On 6 September 2016 at 13:00, Gary Gregory >>>>>>>>>>>>>> <garydgreg...@gmail.com> wrote: >>>>>>>>>>>>>>> On Tue, Sep 6, 2016 at 12:31 PM, Matt Sicker <boa...@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.go...@dslextreme.com> wrote: >>>>>>>>>>>>>>>> Perhaps we shouldn’t have. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Ralph >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Sep 2, 2016, at 7:46 PM, Matt Sicker <boa...@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.stal...@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.po...@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.go...@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 >>>>>>>>>>>>>>>>>>>>> <boa...@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 >>>>>>>>>>>>>>>>>>>>> <garydgreg...@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> When can we delete factory methods that are deprecated >>>>>>>>>>>>>>>>>>>>>> by builders? >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Gary >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>>>>>>>>>>>>>>>>>>>>> Java Persistence with Hibernate, Second Edition >>>>>>>>>>>>>>>>>>>>>> JUnit in Action, Second Edition >>>>>>>>>>>>>>>>>>>>>> Spring Batch in Action >>>>>>>>>>>>>>>>>>>>>> Blog: http://garygregory.wordpress.com >>>>>>>>>>>>>>>>>>>>>> Home: http://garygregory.com/ >>>>>>>>>>>>>>>>>>>>>> Tweet! http://twitter.com/GaryGregory >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>> Matt Sicker <boa...@gmail.com> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Mikael Ståldal >>>>>>>>>>>>>>>>>> Senior software developer >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Magine TV >>>>>>>>>>>>>>>>>> mikael.stal...@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 <boa...@gmail.com> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Matt Sicker <boa...@gmail.com> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>>>>>>>>>>>>> Java Persistence with Hibernate, Second Edition >>>>>>>>>>>>>> JUnit in Action, Second Edition >>>>>>>>>>>>>> Spring Batch in Action >>>>>>>>>>>>>> Blog: http://garygregory.wordpress.com >>>>>>>>>>>>>> Home: http://garygregory.com/ >>>>>>>>>>>>>> Tweet! http://twitter.com/GaryGregory >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Matt Sicker <boa...@gmail.com> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>>>>>>>>> Java Persistence with Hibernate, Second Edition >>>>>>>>>> JUnit in Action, Second Edition >>>>>>>>>> Spring Batch in Action >>>>>>>>>> Blog: http://garygregory.wordpress.com >>>>>>>>>> Home: http://garygregory.com/ >>>>>>>>>> Tweet! http://twitter.com/GaryGregory >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>>>>>>> Java Persistence with Hibernate, Second Edition >>>>>>>> JUnit in Action, Second Edition >>>>>>>> Spring Batch in Action >>>>>>>> Blog: http://garygregory.wordpress.com >>>>>>>> Home: http://garygregory.com/ >>>>>>>> Tweet! http://twitter.com/GaryGregory >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>>>>> Java Persistence with Hibernate, Second Edition >>>>>> JUnit in Action, Second Edition >>>>>> Spring Batch in Action >>>>>> Blog: http://garygregory.wordpress.com >>>>>> Home: http://garygregory.com/ >>>>>> Tweet! http://twitter.com/GaryGregory >>>>> >>>>> >>>>> >>>>> -- >>>>> Matt Sicker <boa...@gmail.com> >>> >>> >>> >>> -- >>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>> Java Persistence with Hibernate, Second Edition >>> JUnit in Action, Second Edition >>> Spring Batch in Action >>> Blog: http://garygregory.wordpress.com >>> Home: http://garygregory.com/ >>> Tweet! http://twitter.com/GaryGregory > > > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > Java Persistence with Hibernate, Second Edition > JUnit in Action, Second Edition > Spring Batch in Action > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory
