[
https://issues.apache.org/jira/browse/NIFI-15977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18083818#comment-18083818
]
Jakub Bogusz commented on NIFI-15977:
-------------------------------------
[~turcsanyip] I've submitted a PR with the short term solution
[here|https://github.com/apache/nifi/pull/11285] - would you mind reviewing?
In terms of potential migration: the hard part I feel like would be a behavior
change. Currently the processor can resolve hostname & share from FlowFile
attributes. With the controller service approach that's not the case anymore.
This is why it seems like an explicit switch would be needed? Either from a
completely new processor or some property?
> 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)
