You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@nifi.apache.org by GitBox <gi...@apache.org> on 2019/04/25 15:34:48 UTC

[GitHub] [nifi-registry] bbende commented on issue #173: NIFIREG-251 Update data model to allow tracking of external controlle…

bbende commented on issue #173: NIFIREG-251 Update data model to allow tracking of external controlle…
URL: https://github.com/apache/nifi-registry/pull/173#issuecomment-486724446
 
 
   We definitely could, but not sure if we have to. It may depend on how we want to use this on NiFi side...
   
   When resolving the service references, NiFi will know the required API for a given property because it has the instantiated component. Then it would need to look for a service in a parent group that meets that API and also has the name that is tracked here, and ensure there is only one with that name.
   
   I suppose it is possible there is some interface Foo with impls of FooA and FooB, and in the first environment the processor was referencing an instance of FooA named "Foo", and in the second environment there is an instance of FooB available, also named "Foo".
   
   Would we want to auto-resolve the FooB instance? or fail because the exact impl that was used in the previous environment doesn't exist?
   
   If we want the latter (failure) then we would need to track more here to know what the implementation was.

----------------------------------------------------------------
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:
users@infra.apache.org


With regards,
Apache Git Services