phrocker commented on a change in pull request #499: MINIFICPP-748 - Nanofi:
add custom C processor example
URL: https://github.com/apache/nifi-minifi-cpp/pull/499#discussion_r263540555
##########
File path: nanofi/src/api/nanofi.cpp
##########
@@ -371,9 +371,18 @@ int8_t remove_attribute(flow_file_record *ff, const char
*key) {
int get_content(const flow_file_record* ff, uint8_t* target, int size) {
NULL_CHECK(0, ff, target);
auto content_repo =
static_cast<std::shared_ptr<minifi::core::ContentRepository>*>(ff->crp);
- std::shared_ptr<minifi::ResourceClaim> claim =
std::make_shared<minifi::ResourceClaim>(ff->contentLocation, *content_repo);
- auto stream = (*content_repo)->read(claim);
- return stream->read(target, size);
+ if(ff->crp && (*content_repo)) {
+ std::shared_ptr<minifi::ResourceClaim> claim =
std::make_shared<minifi::ResourceClaim>(ff->contentLocation,
+
*content_repo);
+ auto stream = (*content_repo)->read(claim);
+ return stream->read(target, size);
+ } else {
Review comment:
Imagine if there were no c++ involved, and as a result, no content repo,
would that change your concern?
Is this not an internal struct? it's fair to expect interaction with our
structures to not be raw access. As a result it's also fair to add a temporary
item while content-repo is in existence. I'll leave that up to you, but maybe
we should make clear that the FF object is not intended to be access outside
of the bounds of function accessors?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
With regards,
Apache Git Services
