Sounds good to me. #1 does address the immediate problem as you mentioned. Since the util package has a lot of stuff in it, my preference would be to have a syslog package under util, or even at the same level as util. If we did that, would moving SyslogParser and SyslogEvent to that package be considered a breaking change? Seems "less breaking" than moving a processor to a new package which could break someone's flow, but still possible someone is using one of those classes since they are public. I can move the other stuff and leave those two alone, but just wanted to double-check.
-Bryan On Tue, Jan 5, 2016 at 4:11 PM, Joe Witt <joe.w...@gmail.com> wrote: > Bryan > > Great writeup on the tradeoffs. From my perspective #1 seems quite > fine for now. I see no need to create new processors and it seems > like the only problem to be solved right now is to make the code > cleaner/more readable. #1 it sounds like solves that. There is > perhaps another topic to address one day which is the grouping of > processors within a bundle. Syslog as its own nar was probably the > right call but this is just fine for now. When we go with a registry > model then we will revisit these and many others anyway. > > Thanks > Joe > > On Tue, Jan 5, 2016 at 10:22 AM, Bryan Bende <bbe...@gmail.com> wrote: > > All, > > > > I'm working on NIFI-1273 to add support for the RELP protocol (Reliable > > Event Logging Protocol) to the syslog processors. In order to do this > I'll > > likely have to add at least one more channel reader implementation to the > > inner classes that already exist in ListenSyslog. I'm starting to think > > there might be a bit too much going on in there and it might be easier to > > manage and understand if the inner classes were moved to regular classes. > > > > If we agree that is a good idea, then the question is where to put > them.... > > In hindsight it probably would have been better to have a syslog bundle, > > instead of putting the syslog processors in the nifi-standard-processors, > > then all of these classes could live there. The processors don't have any > > special dependencies which is why the standard bundle initially seemed > like > > a good idea. > > > > Since we have to be careful of breaking changes, the options I see are: > > > > 1) Keep the syslog processors in nifi-standard-processors, and put these > > classes under the util package where SyslogParser and SyslogEvent are. > > Maybe create org.apache.nifi.processors.standard.util.syslog to group > them > > together under util. > > > > 2) Keep the syslog processors in nifi-standard-processors, but create a > > nifi-syslog-utils project in nifi-commons and put all supporting code > > there. I doubt that any other parts of NiFi would need to make use of > this > > artifact, but it would create a nice isolated syslog library. I think we > > could safely move most of the inner classes there since they are private, > > but not sure if we can move SyslogParser and SyslogEvent yet since they > are > > public classes in standard processors. > > > > 3) Create a syslog bundle with copies of the processors, do all new work > > there, including NIFI-1273. Mark the existing processors as deprecated > and > > remove on 1.0. Seems unfortunate to deprecate processors one release > after > > releasing them, and would force anyone wanting RELP to switch to the new > > bundle, but seems to be the only way to create a separate bundle if that > is > > what we wanted. > > > > What do others think about this? > > > > #1 is obviously the least intrusive and easiest, but I'm not sure it is > the > > best choice, especially given that we want to move to an extension > registry > > eventually, and would probably want to break apart some of standard > > processors. > > > > #2 might be a good middle ground. Leaving the processor part for another > > time. > > > > -Bryan >
