nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Bende <>
Subject Re: AbstractRecordProcessor
Date Sat, 17 Jun 2017 15:18:13 GMT
Hi Chris,

I think a good place for an abstract record processor would be in the
standard record utils under nifi-nar-bundles/nifi-extension-utils:

We've taken a similar approach for other abstract processors by putting
them in nifi-processor-utils which is also under nifi-extension-utils, but
since this depends on the record API I would lean towards the standard
record utils.

For an archetype, I am on the fence about whether maintaining a separate
archetype is worth it. We could also just document the maven dependcies
that should be added to work with records when using a project generated
from the standard archetype? With that plus the abstract record processor
it might be easy enough for people to get going.


On Sat, Jun 17, 2017 at 10:22 AM Chris Herrera <>

> Hi All,
> This is my second attempt for some reason my email client likes to defer
> to my non-registered email to write to the list, (I doubt it happened but
> if you receive this twice, many apologies).
> I was starting to work on the HBase record processors, and while looking
> around found the AbstractRecordProcessor in
> org.apache.nifi.processors.standard. Best I can tell, this is currently
> implemented in UpdateRecord and ConvertRecord. However,
> AbstractRecordProcessor extends AbstractProcessor with the addition
> record-specific logic, thus making it a slightly better starting point from
> which to create a record-based processor. I was wondering wether it makes
> sense to move the AbstractRecordProcessor to  nifi-api from where it
> currently lives int the nifi-nar-bundles (under the standard processors).
> As a follow on to this, does it make sense to create a maven archetype
> that basically has the shell of a record based processor (essentially a
> light implementation of AbstractRecordProcessor)?
> Thanks!
> Chris
Sent from Gmail Mobile

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message