[GitHub] qpid-proton-j issue #13: Added API to Transport interface to allow custom sa...
Github user gemmellr commented on the issue: https://github.com/apache/qpid-proton-j/pull/13 For completeness, a different change was made via https://issues.apache.org/jira/browse/PROTON-1736 in commit 17cef9ace9a7c75901d517f951ae1d4610819436. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-proton-j issue #13: Added API to Transport interface to allow custom sa...
Github user gemmellr commented on the issue: https://github.com/apache/qpid-proton-j/pull/13 My immediate reaction is that this isn't acceptable. It exposes various APIs that are considered part of the implementation only, and then further exposes additional implementation detail presumably to subclass it, which it similarly isn't intended for. Given the general nature of the engines Sasl object/api, would I be right to assume the reason you want this ability is mainly just due to limitations imposed from use within the Reactor? If so perhaps theres a nicer reactor-only approach that can be explored, or alternatively perhaps theres a neat way to tie it in with the existing layering exposed by TransportInternal for similar reactor related layering reasons. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-proton-j issue #13: Added API to Transport interface to allow custom sa...
Github user timtay-microsoft commented on the issue: https://github.com/apache/qpid-proton-j/pull/13 https://issues.apache.org/jira/browse/PROTON-1718 --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
