[
https://issues.apache.org/jira/browse/NIFI-15977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18083826#comment-18083826
]
Peter Turcsanyi commented on NIFI-15977:
----------------------------------------
[~kbogusz] You're right, the FlowFile attribute based properties make the
controller service integration problematic.
Switching the logic in the existing processor seems to me a bit overkill
because it would lead to duplicated functions in SmbjClientService and
PutSmbFile. So it may not be worth.
The new processor does not help either, because it should support the
expression language config in order to provide the same functionality as the
current processor and therefore to be able to replace it in long term.
> PutSmbFile does not support non-default ports
> ---------------------------------------------
>
> Key: NIFI-15977
> URL: https://issues.apache.org/jira/browse/NIFI-15977
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Extensions
> Reporter: Jakub Bogusz
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> PutSmbFile & GetSmbFile processors don't expose a property to use a port
> different than the default. This is not an issue for GetSmbFile, as it's
> pretty much replaced by ListSmb and FetchSmb and those use
> SmbjClientProviderService which has a configurable port. But the PutSmbFile
> has no such alternative.
> It seems it would be hard to migrate PutSmbFile to use the new service in a
> non-breaking way. Maybe some "Connection Strategy" could switch between the
> old, processor-managed client and a new client service? Or maybe just a new
> version of "put" processor would make sense?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
