I'm trying to read code on my phone, but It looks like most of those classes are private. It seems #1 may be the best approach.
We keep having conversations about moving code around - I'd like to restate that I'm in favor of annotations on fields and methods to note whether they are intended extension points or subject to change, which would likely make this a no-brainer. Has anyone else come to this conclusion? On Jan 5, 2016 6:38 PM, "Bryan Bende" <[email protected]> wrote: > 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 > > > > > >
