Github user markap14 commented on the issue:
https://github.com/apache/nifi/pull/2777
In hindsight, a "Context" type of object would have been a good idea in
this situation, had it been done that way in the first place. However, while
it's a helpful design pattern, we have to be cognizant of the fact that we
always have performed a release that contains the Service API the way that it
is. We need to avoid changing that, as any custom Controller Services would
break if we change the API in a non-backward-compatible way. It would also
break any custom processors that try to use a Lookup Service.
While we do have some flexibility in changing Service API's after they have
been released, it is kind of a nuclear option that should be avoided if we can.
Especially for something that is as widely used as the lookup stuff.
This is largely why I want to avoid also including attributes in the same
map - it would potentially break existing services if new things suddenly are
fed into that map that are not part of the lookup's coordinates. By introducing
the `Map<String, String> context` and providing a default implementation in the
interface, all existing services will work as they previously did, and all
existing processors will work as the previously did. However, new or updated
implementations will still be able to take advantage of FlowFile Attributes.
---
