If it helps at all, here is a possible refactoring based on making a syslog package under org.apache.nifi.processors.standard, and moving the parser and event classes there as well:
https://github.com/bbende/nifi/tree/NIFI-1273/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/syslog On Tue, Jan 5, 2016 at 6:14 PM, Tony Kurc <[email protected]> wrote: > Excellent questions, Bryan. I'll give it some thought tonight. > > On Tue, Jan 5, 2016 at 11: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 > > >
