Mike, This response confuses me. Are you saying that because the customers are good with the config change Flume 1.9 can go out with Log4j 2 or are you saying you are good with updating the release notes to say it will happen in the next release?
Ralph > On Nov 29, 2018, at 10:53 PM, Mike Percy <mpe...@apache.org> wrote: > > After speaking with a couple of large users of Flume, because log4j2 is ABI > compatible with log4j1 It sounds like the config change will be acceptable to > them at upgrade time and so I am +1 on this proposal. > > Regards, > Mike > >> On Nov 28, 2018, at 5:37 AM, Ralph Goers <ralph.go...@dslextreme.com> wrote: >> >> Again, please update the release notes to indicate the logging configuration >> change will be coming with the next release. >> >> Ralph >> >>> On Nov 28, 2018, at 1:17 AM, Denes Arvay <de...@cloudera.com.INVALID> wrote: >>> >>> Hi All, >>> >>> I agree that the current content doesn't justify the 2.0 release, so I'd >>> vote for moving forward with the 1.9 as Ferenc recommended, i.e. without >>> the 2 previously mentioned breaking changes. >>> I also agree with the proposed new features, especially with the plugin >>> system/modularization, which was discussed on the other thread: >>> https://s.apache.org/2nm9 >>> >>> So, Ferenc, I think you are good to go with the proposed plan, unless >>> anybody vetoes. >>> >>> Regards, >>> Denes >>> >>> On Tue, Nov 27, 2018 at 4:37 PM Ralph Goers <ralph.go...@dslextreme.com> >>> wrote: >>> >>>> While Log4j 2 supports using properties files for configuration it is not >>>> syntactically compatible with Log4j 1. However, migrating a Log4j 1 >>>> configuration to Log4j 2 isn’t a difficult task. >>>> >>>> Ralph >>>> >>>>> On Nov 27, 2018, at 4:38 AM, Tristan Stevens >>>> <tris...@cloudera.com.INVALID> wrote: >>>>> >>>>> I did start thinking a while back about a REST API that could be used for >>>>> configuring Flume, after which you could potentially bolt on a UI. I >>>>> stopped work on it because it got tricky around configuring sources (and >>>>> the way in which they relate to channels etc). If someone had more time >>>> I’d >>>>> be happy to push to a repo the work that I did. This could be a really >>>>> useful 2.0 feature. >>>>> >>>>> Regarding move from Log4j1.x to 2, it’d be interesting to see what other >>>>> Apache projects, such as Hadoop, Hive etc did around this (in fact, are >>>>> they even at 2.x yet?). For me, if you need to change config, it’s not a >>>>> minor release, it become major, unless there’s a way you can >>>> automatically >>>>> migrate config from one to the other. I’ve not checked, but are we sure >>>>> that .properties file won’t work with log4j2? >>>>> >>>>> Tristan >>>>> >>>>> >>>>> >>>>> On 26 November 2018 at 19:54:01, Mike Percy (mpe...@apache.org) wrote: >>>>> >>>>> Yeah, I agree with this, especially classloader isolation would be great >>>> to >>>>> have as well on the plugin side. >>>>> >>>>> Mike >>>>> >>>>> On Mon, Nov 26, 2018 at 11:50 AM Ralph Goers <ralph.go...@dslextreme.com >>>>> >>>>> wrote: >>>>> >>>>>> I think people want to do more than just upgrade Log4j for a Flume 2.0 >>>>>> release. I would like to make configuration much more pluggable for >>>>>> example. There was also talk about splitting all the sources, sinks, >>>>>> interceptors, etc out of the core module and making them some sort of >>>>>> plugin. At this point those are just at the idea stage. >>>>>> >>>>>>> On Nov 26, 2018, at 12:19 PM, Bessenyei Balázs Donát < >>>> bes...@apache.org> >>>>> >>>>>> wrote: >>>>>>> >>>>>>> I wonder, is there anything blocking us from releasing 2.0 next instead >>>>>> of 1.x? >>>>>>> >>>>>>> >>>>>>> Donat >>>>>>> >>>>>>>> On Mon, Nov 26, 2018 at 6:27 PM Mike Percy <mpe...@apache.org> wrote: >>>>>>>> >>>>>>>> If only the PMC would be affected by this decision, we could have had >>>>>> this >>>>>>>> discussion on the PMC private list. But this decision impacts >>>>> everybody >>>>>>>> that uses Flume. So let's hear from anybody who cares about this, >>>>>> including >>>>>>>> committers, contributors, and users on whether they are okay with >>>>>> switching >>>>>>>> to log4j2 in a minor release version, knowing that they will need to >>>>>> change >>>>>>>> their config files when they upgrade Flume. >>>>>>>> >>>>>>>> Ferenc, it seems like we will have to ship one or the other with the >>>>>> binary >>>>>>>> artifacts at release time. It seems to me that we still have to make a >>>>>>>> choice about the built and shipped default, even if both could work at >>>>>>>> runtime, right? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Mike >>>>>>>> >>>>>>>> On Mon, Nov 26, 2018 at 5:58 AM Ferenc Szabo >>>>>> <fsz...@cloudera.com.invalid> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> I have directed it to the community, the PMC members. >>>>>>>>> I am looking for a decision from the PMC members (including You) on >>>>>> whether >>>>>>>>> we should continue as planned or not removing log4j2 form the minor >>>>>> release >>>>>>>>> branch. >>>>>>>>> >>>>>>>>> On Mon, Nov 26, 2018 at 2:43 PM Ralph Goers < >>>>>> ralph.go...@dslextreme.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Was this directed at me? I am not sure what decision you are >>>>> referring >>>>>>>>> to. >>>>>>>>>> I stated my position in the email you replied to. >>>>>>>>>> >>>>>>>>>> Ralph >>>>>>>>>> >>>>>>>>>>> On Nov 26, 2018, at 5:29 AM, Ferenc Szabo >>>>>> <fsz...@cloudera.com.INVALID >>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> With the new release, you can just replace the jars on the >>>>> classpath >>>>>> as >>>>>>>>>> we >>>>>>>>>>> removed every code dependency and using slf4j. So you do not need >>>>> to >>>>>>>>> fork >>>>>>>>>>> and change anything. >>>>>>>>>>> >>>>>>>>>>> Let me know your decision and we will continue with that. >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Ferenc >>>>>>>>>>> >>>>>>>>>>> On Mon, Nov 26, 2018 at 12:10 PM Apache < >>>> ralph.go...@dslextreme.com> >>>>> >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> As I said, I am fine with adding a notice to the release notes >>>>>> stating >>>>>>>>>> the >>>>>>>>>>>> logging will be changed in the next release regardless of its >>>>>> version >>>>>>>>>>>> number. This way the revert only needs to happen on the release >>>>>> branch >>>>>>>>>> for >>>>>>>>>>>> this release. >>>>>>>>>>>> >>>>>>>>>>>> Ralph >>>>>>>>>>>> >>>>>>>>>>>>> On Nov 25, 2018, at 9:59 PM, Mike Percy <mpe...@apache.org> >>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> While the committer veto rules are well documented here >>>>>>>>>>>>> <https://www.apache.org/foundation/voting.html#Veto>, and there >>>>> is >>>>>>>>> no >>>>>>>>>>>>> mention of a time limit, I propose we shelve that discussion and >>>>>> work >>>>>>>>>> on >>>>>>>>>>>>> getting to consensus on what we as a community want to include in >>>>>> the >>>>>>>>>>>> Flume >>>>>>>>>>>>> 1.9 release. >>>>>>>>>>>>> >>>>>>>>>>>>> As far as I can tell, the decision we have to make is whether to >>>>>>>>>> include >>>>>>>>>>>>> the FLUME-2050 logging changes in the Flume 1.9 release. We can >>>>>>>>> either: >>>>>>>>>>>>> >>>>>>>>>>>>> 1) Require users upgrading from Flume 1.8 to Flume 1.9 to have to >>>>>>>>>> modify >>>>>>>>>>>>> their log4j configuration files to use the different log4j2 XML >>>>>>>>> format, >>>>>>>>>>>>> with the procedure for doing so documented in the release notes. >>>>>>>>>>>>> -or- >>>>>>>>>>>>> 2) Defer that change to a future release where incompatible >>>>> changes >>>>>>>>> are >>>>>>>>>>>>> expected, such as Flume 2.0. >>>>>>>>>>>>> >>>>>>>>>>>>> Also, maybe there are other options I haven't thought of...? >>>>>>>>>>>>> >>>>>>>>>>>>> I would like to get some input from more people on this matter. >>>>> How >>>>>>>>> do >>>>>>>>>>>>> others feel about this? >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Mike >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Sat, Nov 24, 2018 at 9:36 PM Ralph Goers < >>>>>>>>>> ralph.go...@dslextreme.com> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> I should also point out that the time to raise this was a year >>>>> ago >>>>>>>>>> when >>>>>>>>>>>>>> the PR for FLUME-2050 was reviewed and committed. As it stands >>>>>> now I >>>>>>>>>>>> could >>>>>>>>>>>>>> be a jerk and vote -1 on the patch for FLUME-3296 with valid >>>>>>>>> technical >>>>>>>>>>>>>> grounds. If this was causing a true binary incompatibility I >>>>> would >>>>>>>>>>>> approve >>>>>>>>>>>>>> reverting it in a heartbeat, but I just don’t see how having >>>>> users >>>>>>>>>> have >>>>>>>>>>>> to >>>>>>>>>>>>>> change logging configuration is “intolerable”, especially with >>>>> the >>>>>>>>>> known >>>>>>>>>>>>>> security issues in Log4j 1, however unlikely user’s might be to >>>>>>>>>>>> encounter >>>>>>>>>>>>>> them. >>>>>>>>>>>>>> >>>>>>>>>>>>>> That said, I wouldn’t veto the revert on the release branch, but >>>>> I >>>>>>>>>> would >>>>>>>>>>>>>> suggest that the release notes provide fair warning that the >>>>> next >>>>>>>>>>>> release >>>>>>>>>>>>>> will upgrade the logging dependency. It would also be nice if >>>>>>>>>> releases >>>>>>>>>>>>>> could be more frequent than once a year. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I would also like to say that I’m not doing this for the fun of >>>>>> it. >>>>>>>>> My >>>>>>>>>>>>>> company uses Flume for some of its most critical processing. We >>>>>> run >>>>>>>>>>>>>> Veracode scans on all of our software and I expect Flume would >>>>> be >>>>>>>>>>>> flagged >>>>>>>>>>>>>> if I hadn’t repacked it with Log4j 2. It also may not show up >>>>>> since >>>>>>>>>> the >>>>>>>>>>>> CVE >>>>>>>>>>>>>> is marked against Log4j 2 since Log4j 1 is EOL, but the security >>>>>>>>>>>> scanning >>>>>>>>>>>>>> tools should be flagging that as well. >>>>>>>>>>>>>> >>>>>>>>>>>>>> FWIW I’ve had to hack or enhance a few Flume components to make >>>>> it >>>>>>>>>> work >>>>>>>>>>>>>> for my needs but overall it works really, really well. I’d like >>>>> to >>>>>>>>>>>> commit >>>>>>>>>>>>>> back some of the changes but the main one - Flume configuration >>>>> - >>>>>> I >>>>>>>>>>>> really >>>>>>>>>>>>>> don’t like and need to redo the whole thing. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Ralph >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Nov 24, 2018, at 5:11 PM, Mike Percy <mpe...@apache.org> >>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I wasn't aware of this security issue. Do you have a link to >>>>> the >>>>>>>>>>>> details? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> There's no ASF requirement for package names; it's really just >>>>> a >>>>>>>>> Java >>>>>>>>>>>>>>> language convention, and especially not enforced for >>>>>> compatibility >>>>>>>>>>>> shims. >>>>>>>>>>>>>>> Even Flume has some of those in the legacy sources. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I understand that it's very difficult to provide a >>>>> compatibility >>>>>>>>>> layer. >>>>>>>>>>>>>>> Maybe also a boring task. I'm just saying that without log4j1 >>>>>>>>>> backwards >>>>>>>>>>>>>>> compatibility provided by log4j2, there will have to be a >>>>> really >>>>>>>>>>>> critical >>>>>>>>>>>>>>> reason to inflict this migration pain on Flume users -- >>>>> something >>>>>>>>>> that >>>>>>>>>>>>>>> simply can't be tolerated, even in a minor release, like a new >>>>>> and >>>>>>>>>>>> highly >>>>>>>>>>>>>>> dangerous security bug. Without such a motivation, I don't see >>>>>> how >>>>>>>>>> this >>>>>>>>>>>>>>> incompatible dependency change can be justified. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Mike >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Sat, Nov 24, 2018 at 3:20 PM Ralph Goers < >>>>>>>>>>>> ralph.go...@dslextreme.com> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Nov 24, 2018, at 2:35 PM, Mike Percy <mpe...@apache.org> >>>>>>>>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Flume has long had a policy of backwards compatibility with >>>>> its >>>>>>>>> own >>>>>>>>>>>>>>>>> configuration files and people expect things to "just work" >>>>>> when >>>>>>>>>>>>>>>> upgrading >>>>>>>>>>>>>>>>> Flume. If log4j2 can't parse the log4j1 config file format >>>>> then >>>>>>>>>> it's >>>>>>>>>>>> an >>>>>>>>>>>>>>>>> incompatible upgrade and should not be done in a minor Flume >>>>>>>>>> release. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> If log4j2 wants to be a drop-in replacement for log4j1 then >>>>> by >>>>>>>>>>>> default >>>>>>>>>>>>>> it >>>>>>>>>>>>>>>>> should find and parse the traditional log4j.properties config >>>>>>>>>> files, >>>>>>>>>>>> at >>>>>>>>>>>>>>>>> least as a fallback, rather than force users to convert to >>>>> the >>>>>>>>> new >>>>>>>>>>>> XML >>>>>>>>>>>>>>>>> format before upgrading. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> That is simply not possible: >>>>>>>>>>>>>>>> 1. Log4j 1 requires the use of fully qualified class names. >>>>> The >>>>>>>>>>>> package >>>>>>>>>>>>>>>> names log4j 1 used didn’t conform to ASF naming guidelines and >>>>>>>>> don’t >>>>>>>>>>>>>> line >>>>>>>>>>>>>>>> up with the package names used in Log4j2. >>>>>>>>>>>>>>>> 2. Log4j 1 did not delineate between what was public and what >>>>>> was >>>>>>>>>>>>>> private >>>>>>>>>>>>>>>> so there is code all over the place mucking with the internals >>>>>> of >>>>>>>>>>>> Log4j. >>>>>>>>>>>>>>>> Log4j 2 implemented a compatibility layer by implementing the >>>>>>>>>> classes >>>>>>>>>>>>>> that >>>>>>>>>>>>>>>> are being used but by and large they don’t actually do >>>>> anything. >>>>>>>>>>>>>>>> 3. The Appenders and Filters in Log4j 2 implement different >>>>>>>>>> interfaces >>>>>>>>>>>>>> and >>>>>>>>>>>>>>>> cannot use components from Log4j 1. >>>>>>>>>>>>>>>> 4. The Appenders in Log4j 2 are not identical with Log4j 1. In >>>>>>>>> fact, >>>>>>>>>>>>>> many >>>>>>>>>>>>>>>> people didn’t use the Rolling File Appender that shipped with >>>>>>>>> Log4j >>>>>>>>>>>> but >>>>>>>>>>>>>>>> used the one from Log4j extras. So it is hard to.know what >>>>>> Log4j 2 >>>>>>>>>>>> would >>>>>>>>>>>>>>>> have needed to be compatible with. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Many organizations (including mine) have security requirements >>>>>>>>> that >>>>>>>>>>>> say >>>>>>>>>>>>>>>> they must use software that is supported with security fixes. >>>>>>>>> Log4j >>>>>>>>>> 1 >>>>>>>>>>>>>> has a >>>>>>>>>>>>>>>> known security bug that will never be fixed as it reached >>>>>>>>>> end-of-life >>>>>>>>>>>> in >>>>>>>>>>>>>>>> August of 2015. This means the use of Log4j 1 is not >>>>> acceptable >>>>>>>>> for >>>>>>>>>>>> any >>>>>>>>>>>>>>>> security conscious organization. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> While folks have brought up this issue from time to time most >>>>>> seem >>>>>>>>>> to >>>>>>>>>>>>>>>> adapt quite quickly to the change. Most of the issues are >>>>>>>>> developers >>>>>>>>>>>>>>>> wanting to know how to make something they were doing in Log4j >>>>> 1 >>>>>>>>>> work >>>>>>>>>>>> in >>>>>>>>>>>>>>>> Log4j 2. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> As you can imagine, since Log4j 2 has been GA now for 4 1/2 >>>>>> years >>>>>>>>>> and >>>>>>>>>>>>>>>> Log4j 1 has been EOL for over 3, making the configuration >>>>>>>>> compatible >>>>>>>>>>>>>> with >>>>>>>>>>>>>>>> Log4j 1 is not a high priority. FWIW, there was an effort to >>>>> do >>>>>>>>>> that a >>>>>>>>>>>>>> few >>>>>>>>>>>>>>>> years ago, and while we were able to get some basic stuff to >>>>>> work >>>>>>>>>>>>>> making it >>>>>>>>>>>>>>>> work in a general way wasn’t possible. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Ralph >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Mike >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Fri, Nov 23, 2018 at 9:39 AM Ralph Goers < >>>>>>>>>>>>>> ralph.go...@dslextreme.com> >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> No, you are correct. However, requiring a change to logging >>>>>>>>>>>>>>>> configuration >>>>>>>>>>>>>>>>>> has never been considered a binary compatibility break in >>>>> any >>>>>>>>>>>> project >>>>>>>>>>>>>> I >>>>>>>>>>>>>>>>>> have ever worked on. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Ralph >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Nov 23, 2018, at 10:05 AM, Ferenc Szabo >>>>>>>>>>>>>> <fsz...@cloudera.com.INVALID >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> As you mentioned, you have the freedom to use Log4j 2 and >>>>> the >>>>>>>>>> same >>>>>>>>>>>>>> time >>>>>>>>>>>>>>>>>> we >>>>>>>>>>>>>>>>>>> have to keep the out of the box experience the same in a >>>>>> minor >>>>>>>>>>>>>> version. >>>>>>>>>>>>>>>>>>> Users should be able to upgrade flume without changing any >>>>> of >>>>>>>>>> their >>>>>>>>>>>>>>>>>>> configurations. >>>>>>>>>>>>>>>>>>> If they have a log4j.properties (Log4j 1) then they would >>>>> not >>>>>>>>> be >>>>>>>>>>>> able >>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>> use it after the upgrade without changing it. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Or am I missing a feature that would solve this case? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Fri, Nov 23, 2018 at 5:49 PM Ralph Goers < >>>>>>>>>>>>>>>> ralph.go...@dslextreme.com> >>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Also, please put details in the Jira issues. It is much >>>>>> easier >>>>>>>>>> to >>>>>>>>>>>>>> find >>>>>>>>>>>>>>>>>> out >>>>>>>>>>>>>>>>>>>> why something was done by searching Jira later on then >>>>>>>>> searching >>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>> mailing list. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Ralph >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Nov 23, 2018, at 9:47 AM, Ralph Goers < >>>>>>>>>>>>>> ralph.go...@dslextreme.com >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I do not understand this at all. Log4j 2 provides runtime >>>>>>>>>>>>>>>> compatibility >>>>>>>>>>>>>>>>>>>> with Log4j 1. What is the problem that requires a revert? >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I have been running Flume with Log4j 2 since 1.6 so I >>>>> don’t >>>>>>>>>>>>>>>> understand >>>>>>>>>>>>>>>>>>>> what the problem could possibly be. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Ralph >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On Nov 23, 2018, at 8:50 AM, Ferenc Szabo < >>>>>>>>>>>> szabofe...@apache.org> >>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Hi everyone >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I am about to branch the 1.9 release from trunk. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On the 1.9 branch we will revert the following breaking >>>>>>>>>> changes: >>>>>>>>>>>>>>>>>>>>>> - FLUME-2957. Remove Guava from our public API: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>> >>>>> >>>> https://github.com/apache/flume/commit/7f85df9e473ee675d461d5b76650694c5a6c0088 >>>>>>>>>>>>>>>>>>>>>> - part of FLUME-2050. Upgrade to Log4j 2.10.0: >>>>>>>>>>>>>>>>>>>>>> as the new release should work with the previous >>>>>>>>>> configurations >>>>>>>>>>>> we >>>>>>>>>>>>>>>>>> have >>>>>>>>>>>>>>>>>>>>>> to release it with log4j 1.x >>>>>>>>>>>>>>>>>>>>>> For the log4j2 upgrade, we will provide a guide, how to >>>>>>>>>> replace >>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>> jars >>>>>>>>>>>>>>>>>>>>>> if users would like to start using it in the 1.9 release >>>>>> on >>>>>>>>>> the >>>>>>>>>>>>>> wiki >>>>>>>>>>>>>>>>>>>> page. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Because of these changes the first release candidate >>>>> might >>>>>>>>> be >>>>>>>>>>>>>>>>>> postponed >>>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>>> Monday. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>>>>>>> Ferenc Szabo >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On Wed, Nov 7, 2018 at 5:04 PM ema...@cloudera.com < >>>>>>>>>>>>>>>>>> ema...@cloudera.com >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Hi Ferenc, >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> +1 >>>>>>>>>>>>>>>>>>>>>>> I am working on FLUME-3281 Update to Kafka 2.0 client, >>>>>>>>> should >>>>>>>>>>>> be >>>>>>>>>>>>>>>> able >>>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>>>> finish it >>>>>>>>>>>>>>>>>>>>>>> till the suggested deadline. >>>>>>>>>>>>>>>>>>>>>>> I am also happy to do some reviews. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>>>>>>>> Endre >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On 2018/11/06 21:23:17, Ferenc Szabo < >>>>>>>>> szabofe...@apache.org> >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>> Hello Flume Community, >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 1.8 was released about a year ago and since that quite >>>>> a >>>>>>>>> few >>>>>>>>>>>> bug >>>>>>>>>>>>>>>>>>>> fixes, >>>>>>>>>>>>>>>>>>>>>>>> improvements, features and documentation were >>>>>> introduced. >>>>>>>>>>>>>>>>>>>>>>>> I would like to propose to publish the next minor >>>>>> release >>>>>>>>> of >>>>>>>>>>>>>> Flume >>>>>>>>>>>>>>>>>>>>>>>> to make these changes available to the users. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> I would be more than happy to be the Release Manager >>>>>> with >>>>>>>>>> the >>>>>>>>>>>>>> help >>>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>>>>> Denes Arvay for anything that requires PMC access - if >>>>>>>>> both >>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>> community >>>>>>>>>>>>>>>>>>>>>>>> and he are >>>>>>>>>>>>>>>>>>>>>>>> OK with it. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Among others the following changes will be included in >>>>>> the >>>>>>>>>>>> next >>>>>>>>>>>>>>>>>>>> release: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Fixed bugs: >>>>>>>>>>>>>>>>>>>>>>>> - FLUME-3117 Application can be dead loop when call >>>>>>>>>>>>>> System.exit() >>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>>>>>>>> methodconfigure >>>>>>>>>>>>>>>>>>>>>>>> - FLUME-3237 Handling RuntimeExceptions coming from >>>>> the >>>>>>>>> JMS >>>>>>>>>>>>>>>> provider >>>>>>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>>>>>>>> JMSSource >>>>>>>>>>>>>>>>>>>>>>>> - FLUME-3201 Fix SyslogUtil to handle RFC3164 format >>>>> in >>>>>>>>>>>> december >>>>>>>>>>>>>>>>>>>>>>> correctly >>>>>>>>>>>>>>>>>>>>>>>> - FLUME-3056 TestApplication hangs indefinitely >>>>>>>>>>>>>>>>>>>>>>>> - FLUME-2976 Exception when JMS source tries to >>>>> connect >>>>>>>>> to a >>>>>>>>>>>>>>>>>> Weblogic >>>>>>>>>>>>>>>>>>>>>>>> server without authentication >>>>>>>>>>>>>>>>>>>>>>>> - FLUME-3270 Close JMS resources in JMSMessageConsumer >>>>>>>>>>>>>> constructor >>>>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>>>>>>> case >>>>>>>>>>>>>>>>>>>>>>>> of failure >>>>>>>>>>>>>>>>>>>>>>>> - FLUME-3222 java.nio.file.NoSuchFileException thrown >>>>>> when >>>>>>>>>>>> files >>>>>>>>>>>>>>>> are >>>>>>>>>>>>>>>>>>>>>>> being >>>>>>>>>>>>>>>>>>>>>>>> deleted from the TAILDIR source >>>>>>>>>>>>>>>>>>>>>>>> - FLUME-2894 Flume components should stop in the >>>>> correct >>>>>>>>>> order >>>>>>>>>>>>>>>>>>>> (graceful >>>>>>>>>>>>>>>>>>>>>>>> shutdown) >>>>>>>>>>>>>>>>>>>>>>>> - FLUME-2973 Deadlock in hdfs sink >>>>>>>>>>>>>>>>>>>>>>>> - FLUME-3278 Handling -D keystore parameters in Kafka >>>>>>>>>>>> components >>>>>>>>>>>>>>>>>>>>>>>> - FLUME-3265 Cannot set batch-size for >>>>>>>>>> LoadBalancingRpcClient >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Improvements: >>>>>>>>>>>>>>>>>>>>>>>> - FLUME-3186 Make asyncHbaseClient configuration >>>>>>>>> parameters >>>>>>>>>>>>>>>>>> available >>>>>>>>>>>>>>>>>>>>>>> from >>>>>>>>>>>>>>>>>>>>>>>> flume config >>>>>>>>>>>>>>>>>>>>>>>> - FLUME-3239 Do not rename files in >>>>> SpoolDirectorySource >>>>>>>>>>>>>>>>>>>>>>>> - FLUME-3227 Add Rate Limiter to StressSource >>>>>>>>>>>>>>>>>>>>>>>> - FLUME-2050 Upgrade to log4j2 (when GA) >>>>>>>>>>>>>>>>>>>>>>>> - FLUME-3246 Validate flume configuration to prevent >>>>>>>>> larger >>>>>>>>>>>>>> source >>>>>>>>>>>>>>>>>>>> batch >>>>>>>>>>>>>>>>>>>>>>>> size than the channel transaction capacity >>>>>>>>>>>>>>>>>>>>>>>> - FLUME-3050 add counters for error conditions and >>>>>> expose >>>>>>>>> to >>>>>>>>>>>>>>>> monitor >>>>>>>>>>>>>>>>>>>> URL >>>>>>>>>>>>>>>>>>>>>>>> - FLUME-3269 Support JSSE keystore/trustore -D system >>>>>>>>>>>> properties >>>>>>>>>>>>>>>>>>>>>>>> - FLUME-3223 Flume HDFS Sink should retry close prior >>>>> to >>>>>>>>>>>>>>>> performing >>>>>>>>>>>>>>>>>> a >>>>>>>>>>>>>>>>>>>>>>>> recoverLease >>>>>>>>>>>>>>>>>>>>>>>> - FLUME-3276 Components supporting SSL/TLS should be >>>>>> able >>>>>>>>> to >>>>>>>>>>>>>>>> specify >>>>>>>>>>>>>>>>>>>>>>> cipher >>>>>>>>>>>>>>>>>>>>>>>> suite list >>>>>>>>>>>>>>>>>>>>>>>> - FLUME-3275 Components supporting SSL/TLS should be >>>>>> able >>>>>>>>> to >>>>>>>>>>>>>>>> specify >>>>>>>>>>>>>>>>>>>>>>>> protocol list >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> New Features: >>>>>>>>>>>>>>>>>>>>>>>> - FLUME-3142 Adding HBase2 sink >>>>>>>>>>>>>>>>>>>>>>>> - FLUME-2442 Need an alternative to providing clear >>>>> text >>>>>>>>>>>>>> passwords >>>>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>>>>>>> flume >>>>>>>>>>>>>>>>>>>>>>>> config >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> There are 26 open tickets targeted for 1.9 in patch >>>>>>>>>> available >>>>>>>>>>>>>>>> state: >>>>>>>>>>>>>>>>>>>>>>>> https://s.apache.org/flume-1.9-target-tickets >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> We also have a number of open pull requests on Github: >>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/flume/pulls >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> There are a few tickets in progress that would be good >>>>>> to >>>>>>>>>>>>>> include >>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>> release so >>>>>>>>>>>>>>>>>>>>>>>> I would say that we focus on reviewing and testing >>>>> them >>>>>> in >>>>>>>>>> the >>>>>>>>>>>>>>>> next >>>>>>>>>>>>>>>>>> 2 >>>>>>>>>>>>>>>>>>>>>>>> weeks. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> I would like to propose to target the 23rd of November >>>>>> for >>>>>>>>>> the >>>>>>>>>>>>>>>> first >>>>>>>>>>>>>>>>>>>>>>>> release candidate. >>>>>>>>>>>>>>>>>>>>>>>> That would mean that the branch date would be a few >>>>> days >>>>>>>>>>>> before >>>>>>>>>>>>>>>>>> that. >>>>>>>>>>>>>>>>>>>>>>>> Any significant code change should get in by that >>>>> date. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> If nobody has any concerns then I am going to create >>>>> an >>>>>>>>>>>> umbrella >>>>>>>>>>>>>>>>>>>> ticket >>>>>>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>>>>> track the release process. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Some movement can be expected in the related JIRA >>>>>> tickets. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Kind regards, >>>>>>>>>>>>>>>>>>>>>>>> Ferenc >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >> >> > >
