[ 
https://issues.apache.org/jira/browse/NIFI-14891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Bean updated NIFI-14891:
-----------------------------
    Description: 
The NiFi API, ProvenanceReporter interface has the following method:

{{/**}}
{{* Emits a Provenance Event of type}}
{{* \{@link ProvenanceEventType#RECEIVE RECEIVE} that indicates that the given}}
{{* FlowFile was created from data received from the specified URI and that}}
{{* the source system used the specified identifier (a URI with namespace) to}}
{{* refer to the data.}}
{{*}}
{{* @param flowFile the FlowFile that was received}}
{{* @param transitUri A URI that provides information about the System and}}
{{* Protocol information over which the transfer occurred. The intent of this}}
{{* field is such that both the sender and the receiver can publish the}}
{{* events to an external Enterprise-wide system that is then able to}}
{{* correlate the SEND and RECEIVE events.}}
{{* @param sourceSystemFlowFileIdentifier the URI/identifier that the source}}
{{* system uses to refer to the data; if this value is non-null and is not a}}
{{* URI, the prefix "urn:tdo:" will be used to form a URI.}}
{{*/}}
{{void receive(FlowFile flowFile, String transitUri, String 
sourceSystemFlowFileIdentifier);}}
 
The implementing method in StandardProvenanceReporter is:
 
{{@Override}}
{{public void receive(FlowFile flowFile, String transitUri, String details) {}}
{{receive(flowFile, transitUri, details, -1L);}}
 
The method mistakenly uses the third parameter, a String, as "details" when it 
should be "sourceSystemFlowFileIdentifier". The overloaded receive method that 
is called expects details as the third parameter, so this problem is not simply 
a naming issue. The overloaded method should be one that receives the 
sourceSystemFlowFileIdentifier.
 
Fortunately, this method is not currently being used by any component. However, 
it should be updated to conform to the documented API.
 

  was:
The NiFi API, ProvenanceReporter interface has the following method:

 

{{/**}}
{{* Emits a Provenance Event of type}}
{{* \{@link ProvenanceEventType#RECEIVE RECEIVE} that indicates that the given}}
{{* FlowFile was created from data received from the specified URI and that}}
{{* the source system used the specified identifier (a URI with namespace) to}}
{{* refer to the data.}}
{{*}}
{{* @param flowFile the FlowFile that was received}}
{{* @param transitUri A URI that provides information about the System and}}
{{* Protocol information over which the transfer occurred. The intent of this}}
{{* field is such that both the sender and the receiver can publish the}}
{{* events to an external Enterprise-wide system that is then able to}}
{{* correlate the SEND and RECEIVE events.}}
{{* @param sourceSystemFlowFileIdentifier the URI/identifier that the source}}
{{* system uses to refer to the data; if this value is non-null and is not a}}
{{* URI, the prefix "urn:tdo:" will be used to form a URI.}}
{{*/}}
{{void receive(FlowFile flowFile, String transitUri, String 
sourceSystemFlowFileIdentifier);}}
 
The implementing method in StandardProvenanceReporter is:
 
{{@Override}}
{{public void receive(FlowFile flowFile, String transitUri, String details) {}}
{{receive(flowFile, transitUri, details, -1L);}}
 
The method mistakenly uses the third parameter, a String, as "details" when it 
should be "sourceSystemFlowFileIdentifier". The overloaded receive method that 
is called expects details as the third parameter, so this problem is not simply 
a naming issue. The overloaded method should be one that receives the 
sourceSystemFlowFileIdentifier.
 
Fortunately, this method is not currently being used by any component. However, 
it should be updated to conform to the documented API.
 


> StandardProvenanceReporter RECEIVE event implementation does not match API
> --------------------------------------------------------------------------
>
>                 Key: NIFI-14891
>                 URL: https://issues.apache.org/jira/browse/NIFI-14891
>             Project: Apache NiFi
>          Issue Type: Bug
>    Affects Versions: 2.5.0
>            Reporter: Mark Bean
>            Priority: Major
>
> The NiFi API, ProvenanceReporter interface has the following method:
> {{/**}}
> {{* Emits a Provenance Event of type}}
> {{* \{@link ProvenanceEventType#RECEIVE RECEIVE} that indicates that the 
> given}}
> {{* FlowFile was created from data received from the specified URI and that}}
> {{* the source system used the specified identifier (a URI with namespace) 
> to}}
> {{* refer to the data.}}
> {{*}}
> {{* @param flowFile the FlowFile that was received}}
> {{* @param transitUri A URI that provides information about the System and}}
> {{* Protocol information over which the transfer occurred. The intent of 
> this}}
> {{* field is such that both the sender and the receiver can publish the}}
> {{* events to an external Enterprise-wide system that is then able to}}
> {{* correlate the SEND and RECEIVE events.}}
> {{* @param sourceSystemFlowFileIdentifier the URI/identifier that the source}}
> {{* system uses to refer to the data; if this value is non-null and is not a}}
> {{* URI, the prefix "urn:tdo:" will be used to form a URI.}}
> {{*/}}
> {{void receive(FlowFile flowFile, String transitUri, String 
> sourceSystemFlowFileIdentifier);}}
>  
> The implementing method in StandardProvenanceReporter is:
>  
> {{@Override}}
> {{public void receive(FlowFile flowFile, String transitUri, String details) 
> {}}
> {{receive(flowFile, transitUri, details, -1L);}}
>  
> The method mistakenly uses the third parameter, a String, as "details" when 
> it should be "sourceSystemFlowFileIdentifier". The overloaded receive method 
> that is called expects details as the third parameter, so this problem is not 
> simply a naming issue. The overloaded method should be one that receives the 
> sourceSystemFlowFileIdentifier.
>  
> Fortunately, this method is not currently being used by any component. 
> However, it should be updated to conform to the documented API.
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to