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
