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 <[email protected]> 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
