[jira] [Updated] (PROTON-1414) heap-buffer-overflow in pni_decoder_decode_value when invoking pn_message_decode
[
https://issues.apache.org/jira/browse/PROTON-1414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross updated PROTON-1414:
Fix Version/s: proton-c-0.20.0
> heap-buffer-overflow in pni_decoder_decode_value when invoking
> pn_message_decode
>
>
> Key: PROTON-1414
> URL: https://issues.apache.org/jira/browse/PROTON-1414
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: proton-c-0.18.0
>Reporter: Jiri Daněk
>Assignee: Andrew Stitcher
> Labels: codec
> Fix For: proton-c-0.20.0
>
> Attachments: minimized-from-6bdd20e31278a9c00b966db0a4e1b2dd412fdfba
>
>
> {noformat}
> [jdanek@e530 fuzz]$ ./fuzz-message-decode
> minimized-from-6bdd20e31278a9c00b966db0a4e1b2dd412fdfba
> INFO: Seed: 3671742454
> INFO: Loaded 2 modules (7259 guards): [0x7f20793b8c80, 0x7f20793bfdd4),
> [0x74ad60, 0x74ad78),
> ./fuzz-message-decode: Running 1 inputs 1 time(s) each.
> Running: minimized-from-6bdd20e31278a9c00b966db0a4e1b2dd412fdfba
> =
> ==29686==ERROR: AddressSanitizer: heap-buffer-overflow on address
> 0x60200033 at pc 0x7f20790bf3de bp 0x7ffc0d69a970 sp 0x7ffc0d69a968
> READ of size 1 at 0x60200033 thread T0
> #0 0x7f20790bf3dd in pni_decoder_decode_value
> /home/jdanek/Work/qpid-proton/proton-c/src/core/decoder.c:389:24
> #1 0x7f20790bcfa4 in pni_decoder_single
> /home/jdanek/Work/qpid-proton/proton-c/src/core/decoder.c:477:9
> #2 0x7f20790bccc1 in pn_decoder_decode
> /home/jdanek/Work/qpid-proton/proton-c/src/core/decoder.c:491:13
> #3 0x7f20790b84c5 in pn_data_decode
> /home/jdanek/Work/qpid-proton/proton-c/src/core/codec.c:1437:10
> #4 0x7f207911160b in pn_message_decode
> /home/jdanek/Work/qpid-proton/proton-c/src/core/message.c:635:20
> #5 0x4f90c1 in LLVMFuzzerTestOneInput
> /home/jdanek/Work/qpid-proton/proton-c/src/tests/fuzz/fuzz-message-decode.c:12:15
> #6 0x501427 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*,
> unsigned long) /home/jdanek/Work/./Fuzzer/FuzzerLoop.cpp:515:13
> #7 0x501615 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned
> long) /home/jdanek/Work/./Fuzzer/FuzzerLoop.cpp:469:3
> #8 0x4f930c in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned
> long) /home/jdanek/Work/./Fuzzer/FuzzerDriver.cpp:272:6
> #9 0x4fb0ac in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char
> const*, unsigned long)) /home/jdanek/Work/./Fuzzer/FuzzerDriver.cpp:482:9
> #10 0x4f9200 in main /home/jdanek/Work/./Fuzzer/FuzzerMain.cpp:20:10
> #11 0x7f20772d2290 in __libc_start_main (/usr/lib/libc.so.6+0x20290)
> #12 0x423889 in _start
> (/home/jdanek/Work/qpid-proton/build/proton-c/src/tests/fuzz/fuzz-message-decode+0x423889)
> 0x60200033 is located 0 bytes to the right of 3-byte region
> [0x60200030,0x60200033)
> allocated by thread T0 here:
> #0 0x4f608b in operator new[](unsigned long)
> (/home/jdanek/Work/qpid-proton/build/proton-c/src/tests/fuzz/fuzz-message-decode+0x4f608b)
> #1 0x50136a in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*,
> unsigned long) /home/jdanek/Work/./Fuzzer/FuzzerLoop.cpp:506:23
> #2 0x501615 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned
> long) /home/jdanek/Work/./Fuzzer/FuzzerLoop.cpp:469:3
> #3 0x4f930c in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned
> long) /home/jdanek/Work/./Fuzzer/FuzzerDriver.cpp:272:6
> #4 0x4fb0ac in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char
> const*, unsigned long)) /home/jdanek/Work/./Fuzzer/FuzzerDriver.cpp:482:9
> #5 0x4f9200 in main /home/jdanek/Work/./Fuzzer/FuzzerMain.cpp:20:10
> #6 0x7f20772d2290 in __libc_start_main (/usr/lib/libc.so.6+0x20290)
> SUMMARY: AddressSanitizer: heap-buffer-overflow
> /home/jdanek/Work/qpid-proton/proton-c/src/core/decoder.c:389:24 in
> pni_decoder_decode_value
> Shadow bytes around the buggy address:
> 0x0c047fff7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0c047fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0c047fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0c047fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0c047fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> =>0x0c047fff8000: fa fa 03 fa fa fa[03]fa fa fa 00 00 fa fa 00 00
> 0x0c047fff8010: fa fa 00 00 fa fa 00 00 fa fa 00 00 fa fa 00 00
> 0x0c047fff8020: fa fa 00 00 fa fa 00 00 fa fa 00 00 fa fa 00 00
> 0x0c047fff8030: fa fa 00 00 fa fa 00 00 fa fa 00 00 fa fa 00 00
> 0x0c047fff8040: fa fa 00 00 fa fa fa fa fa fa fa fa fa fa fa fa
> 0x0c047fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> Shadow byte legend (one shadow byte
[jira] [Commented] (PROTON-1537) ruby: update API in line with new C++ API changes
[ https://issues.apache.org/jira/browse/PROTON-1537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16296934#comment-16296934 ] ASF subversion and git services commented on PROTON-1537: - Commit 38afef9d2d6a09d15a489d3223190fedb8bb09c0 in qpid-proton's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=38afef9 ] PROTON-1537: [ruby] Fix typo in messaging_adapter.rb code > ruby: update API in line with new C++ API changes > - > > Key: PROTON-1537 > URL: https://issues.apache.org/jira/browse/PROTON-1537 > Project: Qpid Proton > Issue Type: Bug > Components: ruby-binding >Affects Versions: proton-c-0.17.0 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: proton-c-0.19.0 > > > Update the ruby Container interface in line with the new C++ container API > Deprecate Reactor (use Container instead) > Deprecate or remove Messenger API. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1079) Ruby Reactor interface fails with SSL.new ArgumentError
[ https://issues.apache.org/jira/browse/PROTON-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16296942#comment-16296942 ] Justin Ross commented on PROTON-1079: - [~aconway], does your recent work change the picture here? > Ruby Reactor interface fails with SSL.new ArgumentError > --- > > Key: PROTON-1079 > URL: https://issues.apache.org/jira/browse/PROTON-1079 > Project: Qpid Proton > Issue Type: Bug > Components: ruby-binding >Affects Versions: 0.12.0 > Environment: Fresh checkout of master (#32fa7cb059). I believe this > is happening in any released branch as well. > Trying to connect to Azure Event Hubs using amqps. >Reporter: Philippe Le Rohellec >Assignee: Alan Conway > Fix For: proton-c-0.20.0 > > > Using the vanilla qpid-proton/examples/ruby/reactor/simple_recv.rb. I get the > following stacktrace: > $ ./simple_recv.rb -a > 'amqps://eh01-manage:@plrtest-02.servicebus.windows.net/eh01/ConsumerGroups/qpid01/Partitions/1' > -m 1 > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/core/ssl.rb:104:in > `initialize': wrong number of arguments (2 for 4) (ArgumentError) > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/connector.rb:84:in > `new' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/connector.rb:84:in > `connect' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/connector.rb:37:in > `on_connection_local_open' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/event/event_base.rb:26:in > `dispatch' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/event/event.rb:212:in > `dispatch' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/global_overrides.rb:36:in > `override?' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/global_overrides.rb:29:in > `on_unhandled' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/event/event_base.rb:28:in > `dispatch' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/event/event.rb:212:in > `dispatch' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/handler/c_adaptor.rb:34:in > `dispatch' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/reactor.rb:137:in > `pn_reactor_process' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/reactor.rb:137:in > `process' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/reactor.rb:120:in > `run' > from ./simple_recv.rb:57:in `' > Connector calls "Qpid::Proton::SSL.new(transport, @ssl_domain)" but the SSL > constructor takes 4 arguments (and is private). > I tried replacing the SSL.new call by SSL.create which takes transport and > domain but the domain it expects is an SSLDomain instance while the domain > passed by the connector is a Qpid::Proton::Reactor::SessionPerConnection. > I can't figure out why the connector.ssl_domain is assigned to a > SessionPerConnection instance. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1079) Ruby Reactor interface fails with SSL.new ArgumentError
[ https://issues.apache.org/jira/browse/PROTON-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16296955#comment-16296955 ] Alan Conway commented on PROTON-1079: - [~jr...@redhat.com] it should. That reactor code is gone, there is an SSl example (ssl_send.rb sending client, and broker.rb has SSL enabled) which works. I did find and fix some errors in the SSL code - it looked like someone had started to re-organize it and not finished. All the things I tried are working now, although the testing is just basic client-server. More complex operations (client certs etc.) have not been checked. > Ruby Reactor interface fails with SSL.new ArgumentError > --- > > Key: PROTON-1079 > URL: https://issues.apache.org/jira/browse/PROTON-1079 > Project: Qpid Proton > Issue Type: Bug > Components: ruby-binding >Affects Versions: 0.12.0 > Environment: Fresh checkout of master (#32fa7cb059). I believe this > is happening in any released branch as well. > Trying to connect to Azure Event Hubs using amqps. >Reporter: Philippe Le Rohellec >Assignee: Alan Conway > Fix For: proton-c-0.20.0 > > > Using the vanilla qpid-proton/examples/ruby/reactor/simple_recv.rb. I get the > following stacktrace: > $ ./simple_recv.rb -a > 'amqps://eh01-manage:@plrtest-02.servicebus.windows.net/eh01/ConsumerGroups/qpid01/Partitions/1' > -m 1 > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/core/ssl.rb:104:in > `initialize': wrong number of arguments (2 for 4) (ArgumentError) > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/connector.rb:84:in > `new' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/connector.rb:84:in > `connect' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/connector.rb:37:in > `on_connection_local_open' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/event/event_base.rb:26:in > `dispatch' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/event/event.rb:212:in > `dispatch' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/global_overrides.rb:36:in > `override?' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/global_overrides.rb:29:in > `on_unhandled' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/event/event_base.rb:28:in > `dispatch' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/event/event.rb:212:in > `dispatch' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/handler/c_adaptor.rb:34:in > `dispatch' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/reactor.rb:137:in > `pn_reactor_process' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/reactor.rb:137:in > `process' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/reactor.rb:120:in > `run' > from ./simple_recv.rb:57:in `' > Connector calls "Qpid::Proton::SSL.new(transport, @ssl_domain)" but the SSL > constructor takes 4 arguments (and is private). > I tried replacing the SSL.new call by SSL.create which takes transport and > domain but the domain it expects is an SSLDomain instance while the domain > passed by the connector is a Qpid::Proton::Reactor::SessionPerConnection. > I can't figure out why the connector.ssl_domain is assigned to a > SessionPerConnection instance. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1079) Ruby Reactor interface fails with SSL.new ArgumentError
[ https://issues.apache.org/jira/browse/PROTON-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1079: Fix Version/s: (was: proton-c-0.20.0) proton-c-0.19.0 > Ruby Reactor interface fails with SSL.new ArgumentError > --- > > Key: PROTON-1079 > URL: https://issues.apache.org/jira/browse/PROTON-1079 > Project: Qpid Proton > Issue Type: Bug > Components: ruby-binding >Affects Versions: 0.12.0 > Environment: Fresh checkout of master (#32fa7cb059). I believe this > is happening in any released branch as well. > Trying to connect to Azure Event Hubs using amqps. >Reporter: Philippe Le Rohellec >Assignee: Alan Conway > Labels: tls > Fix For: proton-c-0.19.0 > > > Using the vanilla qpid-proton/examples/ruby/reactor/simple_recv.rb. I get the > following stacktrace: > $ ./simple_recv.rb -a > 'amqps://eh01-manage:@plrtest-02.servicebus.windows.net/eh01/ConsumerGroups/qpid01/Partitions/1' > -m 1 > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/core/ssl.rb:104:in > `initialize': wrong number of arguments (2 for 4) (ArgumentError) > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/connector.rb:84:in > `new' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/connector.rb:84:in > `connect' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/connector.rb:37:in > `on_connection_local_open' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/event/event_base.rb:26:in > `dispatch' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/event/event.rb:212:in > `dispatch' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/global_overrides.rb:36:in > `override?' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/global_overrides.rb:29:in > `on_unhandled' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/event/event_base.rb:28:in > `dispatch' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/event/event.rb:212:in > `dispatch' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/handler/c_adaptor.rb:34:in > `dispatch' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/reactor.rb:137:in > `pn_reactor_process' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/reactor.rb:137:in > `process' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/reactor.rb:120:in > `run' > from ./simple_recv.rb:57:in `' > Connector calls "Qpid::Proton::SSL.new(transport, @ssl_domain)" but the SSL > constructor takes 4 arguments (and is private). > I tried replacing the SSL.new call by SSL.create which takes transport and > domain but the domain it expects is an SSLDomain instance while the domain > passed by the connector is a Qpid::Proton::Reactor::SessionPerConnection. > I can't figure out why the connector.ssl_domain is assigned to a > SessionPerConnection instance. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1079) Ruby Reactor interface fails with SSL.new ArgumentError
[ https://issues.apache.org/jira/browse/PROTON-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1079: Labels: tls (was: ) > Ruby Reactor interface fails with SSL.new ArgumentError > --- > > Key: PROTON-1079 > URL: https://issues.apache.org/jira/browse/PROTON-1079 > Project: Qpid Proton > Issue Type: Bug > Components: ruby-binding >Affects Versions: 0.12.0 > Environment: Fresh checkout of master (#32fa7cb059). I believe this > is happening in any released branch as well. > Trying to connect to Azure Event Hubs using amqps. >Reporter: Philippe Le Rohellec >Assignee: Alan Conway > Labels: tls > Fix For: proton-c-0.19.0 > > > Using the vanilla qpid-proton/examples/ruby/reactor/simple_recv.rb. I get the > following stacktrace: > $ ./simple_recv.rb -a > 'amqps://eh01-manage:@plrtest-02.servicebus.windows.net/eh01/ConsumerGroups/qpid01/Partitions/1' > -m 1 > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/core/ssl.rb:104:in > `initialize': wrong number of arguments (2 for 4) (ArgumentError) > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/connector.rb:84:in > `new' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/connector.rb:84:in > `connect' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/connector.rb:37:in > `on_connection_local_open' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/event/event_base.rb:26:in > `dispatch' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/event/event.rb:212:in > `dispatch' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/global_overrides.rb:36:in > `override?' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/global_overrides.rb:29:in > `on_unhandled' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/event/event_base.rb:28:in > `dispatch' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/event/event.rb:212:in > `dispatch' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/handler/c_adaptor.rb:34:in > `dispatch' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/reactor.rb:137:in > `pn_reactor_process' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/reactor.rb:137:in > `process' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/reactor.rb:120:in > `run' > from ./simple_recv.rb:57:in `' > Connector calls "Qpid::Proton::SSL.new(transport, @ssl_domain)" but the SSL > constructor takes 4 arguments (and is private). > I tried replacing the SSL.new call by SSL.create which takes transport and > domain but the domain it expects is an SSLDomain instance while the domain > passed by the connector is a Qpid::Proton::Reactor::SessionPerConnection. > I can't figure out why the connector.ssl_domain is assigned to a > SessionPerConnection instance. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-1079) Ruby Reactor interface fails with SSL.new ArgumentError
[ https://issues.apache.org/jira/browse/PROTON-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross resolved PROTON-1079. - Resolution: Fixed > Ruby Reactor interface fails with SSL.new ArgumentError > --- > > Key: PROTON-1079 > URL: https://issues.apache.org/jira/browse/PROTON-1079 > Project: Qpid Proton > Issue Type: Bug > Components: ruby-binding >Affects Versions: 0.12.0 > Environment: Fresh checkout of master (#32fa7cb059). I believe this > is happening in any released branch as well. > Trying to connect to Azure Event Hubs using amqps. >Reporter: Philippe Le Rohellec >Assignee: Alan Conway > Labels: tls > Fix For: proton-c-0.19.0 > > > Using the vanilla qpid-proton/examples/ruby/reactor/simple_recv.rb. I get the > following stacktrace: > $ ./simple_recv.rb -a > 'amqps://eh01-manage:@plrtest-02.servicebus.windows.net/eh01/ConsumerGroups/qpid01/Partitions/1' > -m 1 > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/core/ssl.rb:104:in > `initialize': wrong number of arguments (2 for 4) (ArgumentError) > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/connector.rb:84:in > `new' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/connector.rb:84:in > `connect' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/connector.rb:37:in > `on_connection_local_open' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/event/event_base.rb:26:in > `dispatch' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/event/event.rb:212:in > `dispatch' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/global_overrides.rb:36:in > `override?' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/global_overrides.rb:29:in > `on_unhandled' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/event/event_base.rb:28:in > `dispatch' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/event/event.rb:212:in > `dispatch' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/handler/c_adaptor.rb:34:in > `dispatch' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/reactor.rb:137:in > `pn_reactor_process' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/reactor.rb:137:in > `process' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/reactor.rb:120:in > `run' > from ./simple_recv.rb:57:in `' > Connector calls "Qpid::Proton::SSL.new(transport, @ssl_domain)" but the SSL > constructor takes 4 arguments (and is private). > I tried replacing the SSL.new call by SSL.create which takes transport and > domain but the domain it expects is an SSLDomain instance while the domain > passed by the connector is a Qpid::Proton::Reactor::SessionPerConnection. > I can't figure out why the connector.ssl_domain is assigned to a > SessionPerConnection instance. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1644) [FreeBSD] Scheme for reusing ports in testing does not work for FreeBSD
[
https://issues.apache.org/jira/browse/PROTON-1644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross updated PROTON-1644:
Component/s: (was: ruby-binding)
> [FreeBSD] Scheme for reusing ports in testing does not work for FreeBSD
> ---
>
> Key: PROTON-1644
> URL: https://issues.apache.org/jira/browse/PROTON-1644
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: proton-c-0.18.0
> Environment: FreeBSD 10.3-RELEASE-p20
>Reporter: Andrew Stitcher
>Assignee: Alan Conway
> Labels: freebsd
> Fix For: proton-c-0.20.0
>
>
> The scheme for picking ports using SO_REUSEPORT does not seem to work on
> FreeBSD producing a bunch of errors like
> {noformat}
> listen error: proton:io: address already in use - listening on localhost:51439
> broker shutdown: proton:io: address already in use - listening on
> localhost:51439
> {noformat}
> This happens in the tests:
> - 12:ruby-test-container
> - 31:c-proactor-tests
> - 34:cpp-example-container
> - 35:cpp-example-container-ssl
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1640) ruby-data-spec test fails on Raspbian Stretch
[
https://issues.apache.org/jira/browse/PROTON-1640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross updated PROTON-1640:
Fix Version/s: proton-c-0.20.0
> ruby-data-spec test fails on Raspbian Stretch
> -
>
> Key: PROTON-1640
> URL: https://issues.apache.org/jira/browse/PROTON-1640
> Project: Qpid Proton
> Issue Type: Bug
> Components: ruby-binding
>Affects Versions: proton-c-0.18.0
> Environment: Raspberry Pi 3
> Raspbian Stretch
>Reporter: Andrew Stitcher
>Assignee: Alan Conway
> Fix For: proton-c-0.20.0
>
>
> Building/Testing 0.18 RC1:
> The only problem is this failure in the ruby tests:
> {noformat}
> Start 19: ruby-data-spec
>
> 19: Test command: /usr/bin/ruby
> "/home/andrew/Source/qpid-proton/qpid-proton-0.18.0
> proton-c/bindings/ruby/spec/data_spec.rb" "-v"
>
> 19: Environment variables:
> 19:
> PATH=/home/andrew/.cargo/bin:/home/andrew/.local/bin:/home/andrew/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games:/home/andrew/Source/qpid-proton/qpid-proton-0.18.0/BLD/proton-c/bindings/ruby:/home/andrew/Source/qpid-proton/qpid-proton-0.18.0/BLD/proton-c
>
> 19:
> RUBYLIB=:/home/andrew/Source/qpid-proton/qpid-proton-0.18.0/proton-c/bindings/ruby/lib:/home/andrew/Source/qpid-proton/qpid-proton-0.18.0/proton-c/bindings/ruby/tests:/home/andrew/Source/qpid-proton/qpid-proton-0.18.0/proton-c/bindings/ruby/spec:/home/andrew/Source/qpid-proton/qpid-proton-0.18.0/BLD/proton-c/bindings/ruby:/home/andrew/Source/qpid-proton/qpid-proton-0.18.0/BLD/proton-c
> 19: Test timeout computed to be: 1500
> 19: Run options: -v --seed 49451
> 19:
> 19: # Running:
> 19:
> 19: A data object#test_0028_raises an error on a negative ulong = 0.00 s = .
> 19: A data object#test_0031_raises an error on a null long = 0.00 s = .
> 19: A data object#test_0053_can hold a zero decimal128 = 0.00 s = .
> 19: A data object#test_0003_can hold a true boolean = 0.00 s = .
> 19: A data object#test_0056_raises an error on a malformed UUID = 0.00 s = .
> 19: A data object#test_0010_raises an error on a negative ushort = 0.00 s = .
> 19: A data object#test_0047_can hold a zero decimal32 = 0.00 s = .
> 19: A data object#test_0052_raises an error on a null decimal128 = 0.00 s = .
> 19: A data object#test_0065_can hold a described value = 0.00 s = .
> 19: A data object#test_0012_can hold a zero unsigned short = 0.00 s = .
> 19: A data object#test_0021_can hold a zero unsigned integer = 0.00 s = .
> 19: A data object#test_0035_can handle a negative timestamp = 0.00 s = .
> 19: A data object#test_0040_can hold a zero float = 0.00 s = .
> 19: A data object#test_0042_raise an error on a null double = 0.00 s = .
> 19: A data object#test_0069_can hold a list = 0.04 s = .
> 19: A data object#test_0037_can hold a timestamp = 0.00 s = .
> 19: A data object#test_0050_can hold a zero decimal64 = 0.00 s = .
> 19: A data object#test_0070_can hold a map = 0.09 s = .
> 19: A data object#test_0032_can have a zero long = 0.00 s = .
> 19: A data object#test_0007_can hold an unsigned byte = 0.00 s = .
> 19: A data object#test_0018_raises an error on a nil uint = 0.00 s = .
> 19: A data object#test_0067_can hold an array = 0.00 s = .
> 19: A data object#test_0054_can hold a decimal128 = 0.00 s = .
> 19: A data object#test_0026_can hold a character = 0.00 s = .
> 19: A data object#test_0017_can hold a negative short = 0.00 s = .
> 19: A data object#test_0036_can handle a zero timestamp = 0.00 s = .
> 19: A data object#test_0059_can hold a null binary = 0.00 s = .
> 19: A data object#test_0068_can hold a described array = 0.03 s = .
> 19: A data object#test_0015_can hold a short = 0.00 s = .
> 19: A data object#test_0048_can hold a decimal32 = 0.00 s = F
> 19: A data object#test_0011_raises an error on a nil ushort = 0.00 s = .
> 19: A data object#test_0063_can hold a null symbol = 0.00 s = .
> 19: A data object#test_0020_can hold an unsigned integer = 0.00 s = .
> 19: A data object#test_0004_can hold a false boolean = 0.00 s = .
> 19: A data object#test_0014_raises an error on a nil short = 0.00 s = .
> 19: A data object#test_0058_can hold a UUID = 0.00 s = .
> 19: A data object#test_0045_can hold a double = 0.00 s = .
> 19: A data object#test_0013_can hold an unsigned short = 0.00 s = .
> 19: A data
[jira] [Comment Edited] (PROTON-1079) Ruby Reactor interface fails with SSL.new ArgumentError
[ https://issues.apache.org/jira/browse/PROTON-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16296955#comment-16296955 ] Alan Conway edited comment on PROTON-1079 at 12/19/17 3:27 PM: --- [~jr...@redhat.com] it should. That reactor code is gone, there is an SSl example (ssl_send.rb sending client, and broker.rb has SSL enabled) which works. I did find and fix some errors in the SSL code - it looked like someone had started to re-organize it and not finished. All the things I tried are working now, although the testing is just basic client-server. More complex operations (including peer-hostname!) have not been checked. was (Author: aconway): [~jr...@redhat.com] it should. That reactor code is gone, there is an SSl example (ssl_send.rb sending client, and broker.rb has SSL enabled) which works. I did find and fix some errors in the SSL code - it looked like someone had started to re-organize it and not finished. All the things I tried are working now, although the testing is just basic client-server. More complex operations (client certs etc.) have not been checked. > Ruby Reactor interface fails with SSL.new ArgumentError > --- > > Key: PROTON-1079 > URL: https://issues.apache.org/jira/browse/PROTON-1079 > Project: Qpid Proton > Issue Type: Bug > Components: ruby-binding >Affects Versions: 0.12.0 > Environment: Fresh checkout of master (#32fa7cb059). I believe this > is happening in any released branch as well. > Trying to connect to Azure Event Hubs using amqps. >Reporter: Philippe Le Rohellec >Assignee: Alan Conway > Fix For: proton-c-0.20.0 > > > Using the vanilla qpid-proton/examples/ruby/reactor/simple_recv.rb. I get the > following stacktrace: > $ ./simple_recv.rb -a > 'amqps://eh01-manage:@plrtest-02.servicebus.windows.net/eh01/ConsumerGroups/qpid01/Partitions/1' > -m 1 > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/core/ssl.rb:104:in > `initialize': wrong number of arguments (2 for 4) (ArgumentError) > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/connector.rb:84:in > `new' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/connector.rb:84:in > `connect' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/connector.rb:37:in > `on_connection_local_open' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/event/event_base.rb:26:in > `dispatch' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/event/event.rb:212:in > `dispatch' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/global_overrides.rb:36:in > `override?' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/global_overrides.rb:29:in > `on_unhandled' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/event/event_base.rb:28:in > `dispatch' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/event/event.rb:212:in > `dispatch' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/handler/c_adaptor.rb:34:in > `dispatch' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/reactor.rb:137:in > `pn_reactor_process' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/reactor.rb:137:in > `process' > from > /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/reactor.rb:120:in > `run' > from ./simple_recv.rb:57:in `' > Connector calls "Qpid::Proton::SSL.new(transport, @ssl_domain)" but the SSL > constructor takes 4 arguments (and is private). > I tried replacing the SSL.new call by SSL.create which takes transport and > domain but the domain it expects is an SSLDomain instance while the domain > passed by the connector is a Qpid::Proton::Reactor::SessionPerConnection. > I can't figure out why the connector.ssl_domain is assigned to a > SessionPerConnection instance. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #234: DISPATCH-89: Parse tree updates
Github user asfgit closed the pull request at: https://github.com/apache/qpid-dispatch/pull/234 --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-89) Model the legacy topic exchange behavior of qpidd
[ https://issues.apache.org/jira/browse/DISPATCH-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16297039#comment-16297039 ] ASF subversion and git services commented on DISPATCH-89: - Commit 4844313b988d91406ab966c2abd91e661062b881 in qpid-dispatch's branch refs/heads/master from Kenneth Giusti [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=4844313 ] DISPATCH-89: Parse tree updates Modification of the parse tree to support MQTT and AMQP 0-10 wildcard patterns. This closes #234 > Model the legacy topic exchange behavior of qpidd > - > > Key: DISPATCH-89 > URL: https://issues.apache.org/jira/browse/DISPATCH-89 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Routing Engine >Affects Versions: 0.2 >Reporter: Ken Giusti >Assignee: Ken Giusti > > With Qpidd, a user can define a binding from an Exchange to a target queue. > The binding uses a key that is compared to a message's subject field. If the > key matches, the message is routed to the target queue for that binding. > It should be possible to emulate this behavior using the dispatch router. > Example: > User defines a mappings from a target address (the 'exchange') to a different > target address(es) (the 'queue'). These mappings (the 'bindings') are driven > by a pattern match against the inbound message's subject field. > Messages arriving at the router from any link whose target address has > bindings defined are not immediately routed. Prior to routing, the message's > subject field is extracted and compared against each binding defined for the > target. A list of new target addresses is created containing the target > address from each binding that satisfied the pattern match. The message is > then routed to each new target address. > The pattern syntax should be the same 'dotted string' notation from qpidd, > including '*' and "#' wildcarding. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-89) Model the legacy topic exchange behavior of qpidd
[ https://issues.apache.org/jira/browse/DISPATCH-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16297040#comment-16297040 ] ASF GitHub Bot commented on DISPATCH-89: Github user asfgit closed the pull request at: https://github.com/apache/qpid-dispatch/pull/234 > Model the legacy topic exchange behavior of qpidd > - > > Key: DISPATCH-89 > URL: https://issues.apache.org/jira/browse/DISPATCH-89 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Routing Engine >Affects Versions: 0.2 >Reporter: Ken Giusti >Assignee: Ken Giusti > > With Qpidd, a user can define a binding from an Exchange to a target queue. > The binding uses a key that is compared to a message's subject field. If the > key matches, the message is routed to the target queue for that binding. > It should be possible to emulate this behavior using the dispatch router. > Example: > User defines a mappings from a target address (the 'exchange') to a different > target address(es) (the 'queue'). These mappings (the 'bindings') are driven > by a pattern match against the inbound message's subject field. > Messages arriving at the router from any link whose target address has > bindings defined are not immediately routed. Prior to routing, the message's > subject field is extracted and compared against each binding defined for the > target. A list of new target addresses is created containing the target > address from each binding that satisfied the pattern match. The message is > then routed to each new target address. > The pattern syntax should be the same 'dotted string' notation from qpidd, > including '*' and "#' wildcarding. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - 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
[jira] [Commented] (PROTON-1718) (Proton-J) Custom Sasl
[
https://issues.apache.org/jira/browse/PROTON-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16297103#comment-16297103
]
Robbie Gemmell commented on PROTON-1718:
Copy of comment from https://github.com/apache/qpid-proton-j/pull/13, the bot
didn't mirror it since the JIRA key isn't in the PR title:
{quote}
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.
{quote}
> (Proton-J) Custom Sasl
> --
>
> Key: PROTON-1718
> URL: https://issues.apache.org/jira/browse/PROTON-1718
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.24.0
>Reporter: Tim Taylor
> Labels: features
>
> I would like to be able to provide a custom SASL implementation for Proton-j
> to use instead of being forced to use the default SaslImpl.java
> implementation.
> Ideally, code like below would be possible
> private class CustomSasl implements org.apache.qpid.proton.engine.Sasl
> {
> ...
> }
> ...
> ...
> //transport.sasl(...) saves the provided sasl implementation and uses it
> internally
> Sasl sasl = transport.sasl(new CustomSasl());
> Do you currently have a workaround that would allow me to use Proton-J this
> way?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-327) QPid JMS has no support for the content-type AMQP properties
[ https://issues.apache.org/jira/browse/QPIDJMS-327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16297155#comment-16297155 ] Robbie Gemmell commented on QPIDJMS-327: One of the reasons discussed for removing the content encoding related property was expectation that for many uses cases seen for it, the client would be handling that itself and if couldn't understand an encoding of a received message consider the message unprocessable. On the content type, it needs to be seen how this interacts with existing usages of it by the client, and also around how it should only be used with Data body sections. How the two aspects further play into any message encryption efforts we would like to explore also needs to be considered. These are all amongst the reasons the client does not yet support anything in this non-JMS area and likely wont imminently. > QPid JMS has no support for the content-type AMQP properties > > > Key: QPIDJMS-327 > URL: https://issues.apache.org/jira/browse/QPIDJMS-327 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Reporter: Leo Riguspi > > The content-type AMQP property cannot be set. According to the specifications > it should be set via the Jms property JMS_AMQP_ContentType, however this > results in nothing being set. > NOTE: there is a similar issue (albeit different) for the content-encoding > property (see [https://issues.apache.org/jira/browse/QPIDJMS-295]) -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8063) Please use https (SSL) for links to KEYS, hashes, sigs
[ https://issues.apache.org/jira/browse/QPID-8063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16297261#comment-16297261 ] Robbie Gemmell commented on QPID-8063: -- verification instructions updated > Please use https (SSL) for links to KEYS, hashes, sigs > -- > > Key: QPID-8063 > URL: https://issues.apache.org/jira/browse/QPID-8063 > Project: Qpid > Issue Type: Bug > Components: Website > Environment: http://qpid.apache.org/download.html >Reporter: Sebb >Assignee: Robbie Gemmell >Priority: Minor > > As the subject says: Please use https (SSL) for links to KEYS, hashes, sigs -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1723) [proton-c] Building with sasl2-bin not installed results in test failure
Timothy Bish created PROTON-1723:
Summary: [proton-c] Building with sasl2-bin not installed results
in test failure
Key: PROTON-1723
URL: https://issues.apache.org/jira/browse/PROTON-1723
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Environment: Linux Mint 18.2
Reporter: Timothy Bish
Priority: Trivial
Building the latest upstream code and running the tests results in a failed
test "ruby-test-container" on my Ubuntu based machine. The INSTALL.md omits
the need to install "sasl2-bin" which leads to the test failure. The install
guide needs an update but also the test might be made to check for that an
maybe offer a better diagnostic or just not run on platforms that are missing
the required dependencies for that test.
{noformat}
timothy@OfficePC ~/temp/0.20.0/qpid-proton-0.19.0/build $ ctest -V -R
ruby-test-container
UpdateCTestConfiguration from
:/home/timothy/temp/0.20.0/qpid-proton-0.19.0/build/DartConfiguration.tcl
Parse Config
file:/home/timothy/temp/0.20.0/qpid-proton-0.19.0/build/DartConfiguration.tcl
UpdateCTestConfiguration from
:/home/timothy/temp/0.20.0/qpid-proton-0.19.0/build/DartConfiguration.tcl
Parse Config
file:/home/timothy/temp/0.20.0/qpid-proton-0.19.0/build/DartConfiguration.tcl
Test project /home/timothy/temp/0.20.0/qpid-proton-0.19.0/build
Constructing a list of tests
Done constructing a list of tests
Checking test dependency graph...
Checking test dependency graph end
test 18
Start 18: ruby-test-container
18: Test command: /usr/bin/python
"/home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/env.py" "--"
"PATH=/home/timothy/.local/bin:/home/timothy/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/lib/jvm/java-8-oracle/bin:/usr/lib/jvm/java-8-oracle/db/bin:/usr/lib/jvm/java-8-oracle/jre/bin:/home/timothy/temp/0.20.0/qpid-proton-0.19.0/build/proton-c/bindings/ruby:/home/timothy/temp/0.20.0/qpid-proton-0.19.0/build/proton-c"
"RUBYLIB=:/home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/bindings/ruby/lib:/home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/bindings/ruby/tests:/home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/bindings/ruby/spec:/home/timothy/temp/0.20.0/qpid-proton-0.19.0/build/proton-c/bindings/ruby:/home/timothy/temp/0.20.0/qpid-proton-0.19.0/build/proton-c"
"SASLPASSWD=SASLPASSWD_EXE-NOTFOUND" "RUBYOPT=-W0" "/usr/bin/ruby"
"/home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/bindings/ruby/tests/test_container.rb"
"-v"
18: Test timeout computed to be: 1500
18: sh: 1: SASLPASSWD_EXE-NOTFOUND: not found
18:
/home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/bindings/ruby/tests/test_container.rb:282:in
`make_user': undefined local variable or method `makepw_cmd' for
# (NameError)
18: from
/home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/bindings/ruby/tests/test_container.rb:261:in
`initialize'
18: from
/home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/bindings/ruby/tests/test_container.rb:284:in
`new'
18: from
/home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/bindings/ruby/tests/test_container.rb:284:in
`'
18: from
/home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/bindings/ruby/tests/test_container.rb:249:in
`'
18: from
/home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/bindings/ruby/tests/test_container.rb:221:in
`'
1/1 Test #18: ruby-test-container ..***Failed0.08 sec
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1723) [proton-c] Building with sasl2-bin not installed results in test failure
[
https://issues.apache.org/jira/browse/PROTON-1723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross updated PROTON-1723:
Fix Version/s: proton-c-0.20.0
> [proton-c] Building with sasl2-bin not installed results in test failure
>
>
> Key: PROTON-1723
> URL: https://issues.apache.org/jira/browse/PROTON-1723
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
> Environment: Linux Mint 18.2
>Reporter: Timothy Bish
>Priority: Trivial
> Fix For: proton-c-0.20.0
>
>
> Building the latest upstream code and running the tests results in a failed
> test "ruby-test-container" on my Ubuntu based machine. The INSTALL.md omits
> the need to install "sasl2-bin" which leads to the test failure. The install
> guide needs an update but also the test might be made to check for that an
> maybe offer a better diagnostic or just not run on platforms that are missing
> the required dependencies for that test.
> {noformat}
> timothy@OfficePC ~/temp/0.20.0/qpid-proton-0.19.0/build $ ctest -V -R
> ruby-test-container
> UpdateCTestConfiguration from
> :/home/timothy/temp/0.20.0/qpid-proton-0.19.0/build/DartConfiguration.tcl
> Parse Config
> file:/home/timothy/temp/0.20.0/qpid-proton-0.19.0/build/DartConfiguration.tcl
> UpdateCTestConfiguration from
> :/home/timothy/temp/0.20.0/qpid-proton-0.19.0/build/DartConfiguration.tcl
> Parse Config
> file:/home/timothy/temp/0.20.0/qpid-proton-0.19.0/build/DartConfiguration.tcl
> Test project /home/timothy/temp/0.20.0/qpid-proton-0.19.0/build
> Constructing a list of tests
> Done constructing a list of tests
> Checking test dependency graph...
> Checking test dependency graph end
> test 18
> Start 18: ruby-test-container
>
> 18: Test command: /usr/bin/python
> "/home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/env.py" "--"
> "PATH=/home/timothy/.local/bin:/home/timothy/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/lib/jvm/java-8-oracle/bin:/usr/lib/jvm/java-8-oracle/db/bin:/usr/lib/jvm/java-8-oracle/jre/bin:/home/timothy/temp/0.20.0/qpid-proton-0.19.0/build/proton-c/bindings/ruby:/home/timothy/temp/0.20.0/qpid-proton-0.19.0/build/proton-c"
>
> "RUBYLIB=:/home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/bindings/ruby/lib:/home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/bindings/ruby/tests:/home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/bindings/ruby/spec:/home/timothy/temp/0.20.0/qpid-proton-0.19.0/build/proton-c/bindings/ruby:/home/timothy/temp/0.20.0/qpid-proton-0.19.0/build/proton-c"
> "SASLPASSWD=SASLPASSWD_EXE-NOTFOUND" "RUBYOPT=-W0" "/usr/bin/ruby"
> "/home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/bindings/ruby/tests/test_container.rb"
> "-v"
> 18: Test timeout computed to be: 1500
> 18: sh: 1: SASLPASSWD_EXE-NOTFOUND: not found
> 18:
> /home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/bindings/ruby/tests/test_container.rb:282:in
> `make_user': undefined local variable or method `makepw_cmd' for
> # (NameError)
> 18: from
> /home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/bindings/ruby/tests/test_container.rb:261:in
> `initialize'
> 18: from
> /home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/bindings/ruby/tests/test_container.rb:284:in
> `new'
> 18: from
> /home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/bindings/ruby/tests/test_container.rb:284:in
> `'
> 18: from
> /home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/bindings/ruby/tests/test_container.rb:249:in
> `'
> 18: from
> /home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/bindings/ruby/tests/test_container.rb:221:in
> `'
> 1/1 Test #18: ruby-test-container ..***Failed0.08 sec
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1718) (Proton-J) Custom Sasl
[
https://issues.apache.org/jira/browse/PROTON-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16297167#comment-16297167
]
Tim Taylor commented on PROTON-1718:
Thanks for the response!
Okay, if this kind of change is unacceptable, maybe you can help me find a
different way to resolve a problem I'm facing. Essentially, the service I need
to do Sasl auth against only allows a custom Sasl mechanism. The flow works as
follows:
1) Service advertises this custom Sasl mechanism as the only option
2) Client sends init message with a payload containing application code data to
the service (sending multiple init messages if the payload is too large for one
frame)
3) Service responds with a challenge asking to send some specific data
4) Client writes a frame with that data in Sasl Response
5) Service responds with another challenge, this time with a payload that
+needs+ to be exposed to our application code for processing.
6) Client sends some challenge response using the processed data from the
previous challenge.
7) Sasl authentication has succeeded
There doesn't seem to be a way for me to implement this custom sasl flow using
the current proton-j library. I can't expose the sasl challenge data exposed to
my application for processing, and I can't tell the library how to handle each
iteration of the challenge-response flow. Am I just missing how to implement a
custom sasl mechanism, or is this a limitation of proton-j?
Of the two commits made in the pull request for this fix, only the first is
necessary for me to implement this. The second commit is simply to allow me to
subclass SaslImpl so that I don't need to re-write and maintain all the logic
that isn't tied to Init/Challenge/Response. Is it possible for this PR to be
approved if I limit it to just the first commit?
> (Proton-J) Custom Sasl
> --
>
> Key: PROTON-1718
> URL: https://issues.apache.org/jira/browse/PROTON-1718
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.24.0
>Reporter: Tim Taylor
> Labels: features
>
> I would like to be able to provide a custom SASL implementation for Proton-j
> to use instead of being forced to use the default SaslImpl.java
> implementation.
> Ideally, code like below would be possible
> private class CustomSasl implements org.apache.qpid.proton.engine.Sasl
> {
> ...
> }
> ...
> ...
> //transport.sasl(...) saves the provided sasl implementation and uses it
> internally
> Sasl sasl = transport.sasl(new CustomSasl());
> Do you currently have a workaround that would allow me to use Proton-J this
> way?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (PROTON-1723) [proton-c] Building with sasl2-bin not installed results in test failure
[
https://issues.apache.org/jira/browse/PROTON-1723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross reassigned PROTON-1723:
---
Assignee: Justin Ross
> [proton-c] Building with sasl2-bin not installed results in test failure
>
>
> Key: PROTON-1723
> URL: https://issues.apache.org/jira/browse/PROTON-1723
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
> Environment: Linux Mint 18.2
>Reporter: Timothy Bish
>Assignee: Justin Ross
>Priority: Trivial
> Fix For: proton-c-0.20.0
>
>
> Building the latest upstream code and running the tests results in a failed
> test "ruby-test-container" on my Ubuntu based machine. The INSTALL.md omits
> the need to install "sasl2-bin" which leads to the test failure. The install
> guide needs an update but also the test might be made to check for that an
> maybe offer a better diagnostic or just not run on platforms that are missing
> the required dependencies for that test.
> {noformat}
> timothy@OfficePC ~/temp/0.20.0/qpid-proton-0.19.0/build $ ctest -V -R
> ruby-test-container
> UpdateCTestConfiguration from
> :/home/timothy/temp/0.20.0/qpid-proton-0.19.0/build/DartConfiguration.tcl
> Parse Config
> file:/home/timothy/temp/0.20.0/qpid-proton-0.19.0/build/DartConfiguration.tcl
> UpdateCTestConfiguration from
> :/home/timothy/temp/0.20.0/qpid-proton-0.19.0/build/DartConfiguration.tcl
> Parse Config
> file:/home/timothy/temp/0.20.0/qpid-proton-0.19.0/build/DartConfiguration.tcl
> Test project /home/timothy/temp/0.20.0/qpid-proton-0.19.0/build
> Constructing a list of tests
> Done constructing a list of tests
> Checking test dependency graph...
> Checking test dependency graph end
> test 18
> Start 18: ruby-test-container
>
> 18: Test command: /usr/bin/python
> "/home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/env.py" "--"
> "PATH=/home/timothy/.local/bin:/home/timothy/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/lib/jvm/java-8-oracle/bin:/usr/lib/jvm/java-8-oracle/db/bin:/usr/lib/jvm/java-8-oracle/jre/bin:/home/timothy/temp/0.20.0/qpid-proton-0.19.0/build/proton-c/bindings/ruby:/home/timothy/temp/0.20.0/qpid-proton-0.19.0/build/proton-c"
>
> "RUBYLIB=:/home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/bindings/ruby/lib:/home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/bindings/ruby/tests:/home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/bindings/ruby/spec:/home/timothy/temp/0.20.0/qpid-proton-0.19.0/build/proton-c/bindings/ruby:/home/timothy/temp/0.20.0/qpid-proton-0.19.0/build/proton-c"
> "SASLPASSWD=SASLPASSWD_EXE-NOTFOUND" "RUBYOPT=-W0" "/usr/bin/ruby"
> "/home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/bindings/ruby/tests/test_container.rb"
> "-v"
> 18: Test timeout computed to be: 1500
> 18: sh: 1: SASLPASSWD_EXE-NOTFOUND: not found
> 18:
> /home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/bindings/ruby/tests/test_container.rb:282:in
> `make_user': undefined local variable or method `makepw_cmd' for
> # (NameError)
> 18: from
> /home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/bindings/ruby/tests/test_container.rb:261:in
> `initialize'
> 18: from
> /home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/bindings/ruby/tests/test_container.rb:284:in
> `new'
> 18: from
> /home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/bindings/ruby/tests/test_container.rb:284:in
> `'
> 18: from
> /home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/bindings/ruby/tests/test_container.rb:249:in
> `'
> 18: from
> /home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/bindings/ruby/tests/test_container.rb:221:in
> `'
> 1/1 Test #18: ruby-test-container ..***Failed0.08 sec
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1718) (Proton-J) Custom Sasl
[
https://issues.apache.org/jira/browse/PROTON-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16297571#comment-16297571
]
Tim Taylor commented on PROTON-1718:
Let's simplify this a bit to get the ball rolling (When you get back from break)
Suppose I'm taking the library as it is right now. If I needed to include a
payload in the sasl init frame, is that possible?
> (Proton-J) Custom Sasl
> --
>
> Key: PROTON-1718
> URL: https://issues.apache.org/jira/browse/PROTON-1718
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.24.0
>Reporter: Tim Taylor
> Labels: features
>
> I would like to be able to provide a custom SASL implementation for Proton-j
> to use instead of being forced to use the default SaslImpl.java
> implementation.
> Ideally, code like below would be possible
> private class CustomSasl implements org.apache.qpid.proton.engine.Sasl
> {
> ...
> }
> ...
> ...
> //transport.sasl(...) saves the provided sasl implementation and uses it
> internally
> Sasl sasl = transport.sasl(new CustomSasl());
> Do you currently have a workaround that would allow me to use Proton-J this
> way?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1703) [cpp] Remove auto_settle from receiver options
[ https://issues.apache.org/jira/browse/PROTON-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16297280#comment-16297280 ] ASF subversion and git services commented on PROTON-1703: - Commit b9f9402598171602ed7d3c6f7dd410906d1d0684 in qpid-proton's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=b9f9402 ] Revert PROTON-1703: [cpp] Remove auto_settle from receiver_options Reverted the change for binary compatibility but deprecated auto_settle since it is a no-op on receiver. To remove at next major revision. > [cpp] Remove auto_settle from receiver options > -- > > Key: PROTON-1703 > URL: https://issues.apache.org/jira/browse/PROTON-1703 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.18.1 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: proton-c-0.19.0 > > > auto_settle is a sender-only option, the receiver equivalent is auto_accept. > auto_settle is only used at messaging_adapter.cpp#L172, which applies only to > senders, it was included in the option list by mistake. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1717) [C proactor] Allow initialization of transport and connection before binding
[ https://issues.apache.org/jira/browse/PROTON-1717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16297281#comment-16297281 ] ASF subversion and git services commented on PROTON-1717: - Commit 3311dd602d228e960019a54128e1e6674247778f in qpid-proton's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=3311dd6 ] PROTON-1717 [C proactor] Make changes backward compatible. Restore and deprecate original signatures for pn_proactor_connect and pn_listener_accept. Introduce pn_proactor_connect2 and pn_listener_accept2 taking a transport parameter. Update all examples & tests to use the un-deprecated functions. > [C proactor] Allow initialization of transport and connection before binding > > > Key: PROTON-1717 > URL: https://issues.apache.org/jira/browse/PROTON-1717 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: proton-c-0.18.1 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: proton-c-0.19.0 > > > The C proactor allows the user to configure a connection before it is bound > to a transport, but does not allow configuring the transport before binding. > Some security configurations require this. > Modify the proactor API to give access to both the connection and the > transport before the are bound together. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-831) Change conntector.cost default value to 1 instead of '1'
[ https://issues.apache.org/jira/browse/DISPATCH-831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy resolved DISPATCH-831. Resolution: Fixed Assignee: Ganesh Murthy Fix Version/s: 1.1.0 > Change conntector.cost default value to 1 instead of '1' > > > Key: DISPATCH-831 > URL: https://issues.apache.org/jira/browse/DISPATCH-831 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 0.8.0 >Reporter: Ernest Allen >Assignee: Ganesh Murthy >Priority: Trivial > Fix For: 1.1.0 > > > The schema lists the connector.cost attribute as being an integer, however > the default value is the string '1'. This is causing javascript errors in the > console. I have a work-around for the console but it would be better to fix > this at the source. > Note: the listener.cost attribute is also an integer and it has an integer > value as the default so I'm assuming that nothing is relying on the default > value to be a string. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (PROTON-1718) (Proton-J) Custom Sasl
[
https://issues.apache.org/jira/browse/PROTON-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16297167#comment-16297167
]
Tim Taylor edited comment on PROTON-1718 at 12/19/17 6:11 PM:
--
Thanks for the response!
Okay, if this kind of change is unacceptable, maybe you can help me find a
different way to resolve a problem I'm facing. Essentially, the service I need
to do Sasl auth against only allows a custom Sasl mechanism. The flow works as
follows:
1) Service advertises this custom Sasl mechanism as the only option
2) Client sends init message with a payload containing application code data to
the service (sending multiple init messages if the payload is too large for one
frame)
3) Service responds with a challenge asking to send some specific data
4) Client writes a frame with that data in Sasl Response
5) Service responds with another challenge, this time with a payload that
+needs+ to be exposed to our application code for processing.
6) Client sends some challenge response using the processed data from the
previous challenge.
7) Sasl authentication has succeeded
There doesn't seem to be a way for me to implement this custom sasl flow using
the current proton-j library. I can't choose what payload to include in the
init, I can't expose the sasl challenge data exposed to my application for
processing, and I can't tell the library how to handle each iteration of the
challenge-response flow. Am I just missing how to implement a custom sasl
mechanism, or is this a limitation of proton-j?
Of the two commits made in the pull request for this fix, only the first is
necessary for me to implement this. The second commit is simply to allow me to
subclass SaslImpl so that I don't need to re-write and maintain all the logic
that isn't tied to Init/Challenge/Response. Is it possible for this PR to be
approved if I limit it to just the first commit?
was (Author: timtay):
Thanks for the response!
Okay, if this kind of change is unacceptable, maybe you can help me find a
different way to resolve a problem I'm facing. Essentially, the service I need
to do Sasl auth against only allows a custom Sasl mechanism. The flow works as
follows:
1) Service advertises this custom Sasl mechanism as the only option
2) Client sends init message with a payload containing application code data to
the service (sending multiple init messages if the payload is too large for one
frame)
3) Service responds with a challenge asking to send some specific data
4) Client writes a frame with that data in Sasl Response
5) Service responds with another challenge, this time with a payload that
+needs+ to be exposed to our application code for processing.
6) Client sends some challenge response using the processed data from the
previous challenge.
7) Sasl authentication has succeeded
There doesn't seem to be a way for me to implement this custom sasl flow using
the current proton-j library. I can't expose the sasl challenge data exposed to
my application for processing, and I can't tell the library how to handle each
iteration of the challenge-response flow. Am I just missing how to implement a
custom sasl mechanism, or is this a limitation of proton-j?
Of the two commits made in the pull request for this fix, only the first is
necessary for me to implement this. The second commit is simply to allow me to
subclass SaslImpl so that I don't need to re-write and maintain all the logic
that isn't tied to Init/Challenge/Response. Is it possible for this PR to be
approved if I limit it to just the first commit?
> (Proton-J) Custom Sasl
> --
>
> Key: PROTON-1718
> URL: https://issues.apache.org/jira/browse/PROTON-1718
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.24.0
>Reporter: Tim Taylor
> Labels: features
>
> I would like to be able to provide a custom SASL implementation for Proton-j
> to use instead of being forced to use the default SaslImpl.java
> implementation.
> Ideally, code like below would be possible
> private class CustomSasl implements org.apache.qpid.proton.engine.Sasl
> {
> ...
> }
> ...
> ...
> //transport.sasl(...) saves the provided sasl implementation and uses it
> internally
> Sasl sasl = transport.sasl(new CustomSasl());
> Do you currently have a workaround that would allow me to use Proton-J this
> way?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1722) 0.20.0 release tasks
[ https://issues.apache.org/jira/browse/PROTON-1722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-1722: --- Fix Version/s: (was: proton-c-0.19.0) proton-c-0.20.0 > 0.20.0 release tasks > > > Key: PROTON-1722 > URL: https://issues.apache.org/jira/browse/PROTON-1722 > Project: Qpid Proton > Issue Type: Task > Components: proton-c, release >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: proton-c-0.20.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1717) [C proactor] Allow initialization of transport and connection before binding
[ https://issues.apache.org/jira/browse/PROTON-1717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16297319#comment-16297319 ] ASF subversion and git services commented on PROTON-1717: - Commit 4d16e6183d4d0eb39e2a29d2a3a289fef2327201 in qpid-proton's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=4d16e61 ] PROTON-1717 [C proactor] Fix build error in example Fix build error on older compilers in ssl-send example. > [C proactor] Allow initialization of transport and connection before binding > > > Key: PROTON-1717 > URL: https://issues.apache.org/jira/browse/PROTON-1717 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: proton-c-0.18.1 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: proton-c-0.19.0 > > > The C proactor allows the user to configure a connection before it is bound > to a transport, but does not allow configuring the transport before binding. > Some security configurations require this. > Modify the proactor API to give access to both the connection and the > transport before the are bound together. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1669) 0.19.0 release tasks
[ https://issues.apache.org/jira/browse/PROTON-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16297309#comment-16297309 ] ASF subversion and git services commented on PROTON-1669: - Commit 5e4242c29663f2398219d1c21d93789ef2870c27 in qpid-proton's branch refs/heads/master from [~gemmellr] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=5e4242c ] PROTON-1669: bump the .so minor versions > 0.19.0 release tasks > > > Key: PROTON-1669 > URL: https://issues.apache.org/jira/browse/PROTON-1669 > Project: Qpid Proton > Issue Type: Task > Components: proton-c, release >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: proton-c-0.19.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1669) 0.19.0 release tasks
[ https://issues.apache.org/jira/browse/PROTON-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16297388#comment-16297388 ] ASF subversion and git services commented on PROTON-1669: - Commit f3054e391218a20c88ecd803f39e325388f45d82 in qpid-proton's branch refs/heads/master from [~gemmellr] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=f3054e3 ] PROTON-1722, PROTON-1669: update versions for 0.20.0-SNAPSHOT > 0.19.0 release tasks > > > Key: PROTON-1669 > URL: https://issues.apache.org/jira/browse/PROTON-1669 > Project: Qpid Proton > Issue Type: Task > Components: proton-c, release >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: proton-c-0.19.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1669) 0.19.0 release tasks
[ https://issues.apache.org/jira/browse/PROTON-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16297386#comment-16297386 ] ASF subversion and git services commented on PROTON-1669: - Commit 01917c713a00dc50c148fb726229e9aa444bbf0c in qpid-proton's branch refs/heads/master from [~gemmellr] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=01917c7 ] PROTON-1669: update versions for 0.19.0-rc1 > 0.19.0 release tasks > > > Key: PROTON-1669 > URL: https://issues.apache.org/jira/browse/PROTON-1669 > Project: Qpid Proton > Issue Type: Task > Components: proton-c, release >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: proton-c-0.19.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-902) Intermittent crash with link to broker when broker closed
[
https://issues.apache.org/jira/browse/DISPATCH-902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Conway reassigned DISPATCH-902:
Assignee: Alan Conway (was: Ted Ross)
> Intermittent crash with link to broker when broker closed
> -
>
> Key: DISPATCH-902
> URL: https://issues.apache.org/jira/browse/DISPATCH-902
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.0.0
>Reporter: Kim van der Riet
>Assignee: Alan Conway
>Priority: Blocker
> Fix For: 1.1.0
>
> Attachments: qdrouterd.node1.conf, qdrouterd.node2.conf,
> qpidd.d2n.conf
>
>
> When using dispatch in a 2-node configuration with a broker between them:
> {noformat}
> 9002 10001 100019003
> sender > dispatch1 -> qpid-cpp -> dispatch2 -> receiver
> {noformat}
> and initializing in the following order:
> # start dispatch1
> # start dispatch2
> # start qpid-cpp
> # wait for "Link Route Activated" messages on both dispatch nodes
> # stop qpid-cpp
> then the dispatch nodes will core after a random amount of time and after
> sending a random number of
> {noformat}
> (info) Connection to localhost:10001 failed: proton:io Connection refused -
> on read from localhost:10001
> {noformat}
> messages.
> The stack trace is as follows for all occurrences:
> {noformat}
> Thread 3 "qdrouterd" received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7fffea269700 (LWP 10954)]
> pn_transport_tail_closed (transport=0x0) at
> /home/kpvdr/RedHat/qpid-proton/proton-c/src/core/transport.c:3044
> 3044 bool pn_transport_tail_closed(pn_transport_t *transport) { return
> transport->tail_closed; }
> (gdb) thread apply all bt
> Thread 5 (Thread 0x7fffe9267700 (LWP 10956)):
> #0 0x767eb6d3 in epoll_wait () at
> ../sysdeps/unix/syscall-template.S:84
> #1 0x777327e2 in proactor_do_epoll (p=0x89b550,
> can_block=can_block@entry=true) at
> /home/kpvdr/RedHat/qpid-proton/proton-c/src/proactor/epoll.c:1978
> #2 0x777337ca in pn_proactor_wait (p=) at
> /home/kpvdr/RedHat/qpid-proton/proton-c/src/proactor/epoll.c:2025
> #3 0x77bbc219 in thread_run (arg=0x89ec20) at
> /home/kpvdr/RedHat/qpid-dispatch/src/server.c:932
> #4 0x775185ca in start_thread (arg=0x7fffe9267700) at
> pthread_create.c:333
> #5 0x767eb0cd in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
> Thread 4 (Thread 0x7fffe9a68700 (LWP 10955)):
> #0 0x767eb6d3 in epoll_wait () at
> ../sysdeps/unix/syscall-template.S:84
> #1 0x777327e2 in proactor_do_epoll (p=0x89b550,
> can_block=can_block@entry=true) at
> /home/kpvdr/RedHat/qpid-proton/proton-c/src/proactor/epoll.c:1978
> #2 0x777337ca in pn_proactor_wait (p=) at
> /home/kpvdr/RedHat/qpid-proton/proton-c/src/proactor/epoll.c:2025
> #3 0x77bbc219 in thread_run (arg=0x89ec20) at
> /home/kpvdr/RedHat/qpid-dispatch/src/server.c:932
> #4 0x775185ca in start_thread (arg=0x7fffe9a68700) at
> pthread_create.c:333
> #5 0x767eb0cd in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
> Thread 3 (Thread 0x7fffea269700 (LWP 10954)):
> #0 pn_transport_tail_closed (transport=0x0) at
> /home/kpvdr/RedHat/qpid-proton/proton-c/src/core/transport.c:3044
> #1 0x7794f4f9 in pn_connection_driver_read_closed
> (d=d@entry=0x7fffdc054288) at
> /home/kpvdr/RedHat/qpid-proton/proton-c/src/core/connection_driver.c:109
> #2 0x77731ef1 in pconnection_rclosed (pc=0x7fffdc053ce0) at
> /home/kpvdr/RedHat/qpid-proton/proton-c/src/proactor/epoll.c:898
> #3 pconnection_process (pc=0x7fffdc053ce0, events=,
> timeout=timeout@entry=false, topup=topup@entry=false) at
> /home/kpvdr/RedHat/qpid-proton/proton-c/src/proactor/epoll.c:1084
> #4 0x77732945 in proactor_do_epoll (p=0x89b550,
> can_block=can_block@entry=true) at
> /home/kpvdr/RedHat/qpid-proton/proton-c/src/proactor/epoll.c:2007
> #5 0x777337ca in pn_proactor_wait (p=) at
> /home/kpvdr/RedHat/qpid-proton/proton-c/src/proactor/epoll.c:2025
> #6 0x77bbc219 in thread_run (arg=0x89ec20) at
> /home/kpvdr/RedHat/qpid-dispatch/src/server.c:932
> #7 0x775185ca in start_thread (arg=0x7fffea269700) at
> pthread_create.c:333
> #8 0x767eb0cd in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
> Thread 2 (Thread 0x7fffeaa6a700 (LWP 10953)):
> #0 pthread_cond_wait@@GLIBC_2.3.2 () at
> ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
> #1 0x77ba2949 in sys_cond_wait (cond=,
> held_mutex=) at
> /home/kpvdr/RedHat/qpid-dispatch/src/posix/threading.c:91
> #2 0x77bb0cf5 in router_core_thread (arg=0x8f8c90) at
> /home/kpvdr/RedHat/qpid-dispatch/src/router_core/router_core_thread.c:66
> #3
[jira] [Commented] (PROTON-1722) 0.20.0 release tasks
[ https://issues.apache.org/jira/browse/PROTON-1722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16297387#comment-16297387 ] ASF subversion and git services commented on PROTON-1722: - Commit f3054e391218a20c88ecd803f39e325388f45d82 in qpid-proton's branch refs/heads/master from [~gemmellr] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=f3054e3 ] PROTON-1722, PROTON-1669: update versions for 0.20.0-SNAPSHOT > 0.20.0 release tasks > > > Key: PROTON-1722 > URL: https://issues.apache.org/jira/browse/PROTON-1722 > Project: Qpid Proton > Issue Type: Task > Components: proton-c, release >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: proton-c-0.20.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1703) [cpp] Remove auto_settle from receiver options
[ https://issues.apache.org/jira/browse/PROTON-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-1703: --- Affects Version/s: (was: proton-c-0.18.1) proton-c-0.19.0 > [cpp] Remove auto_settle from receiver options > -- > > Key: PROTON-1703 > URL: https://issues.apache.org/jira/browse/PROTON-1703 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.19.0 >Reporter: Alan Conway >Assignee: Alan Conway > > auto_settle is a sender-only option, the receiver equivalent is auto_accept. > auto_settle is only used at messaging_adapter.cpp#L172, which applies only to > senders, it was included in the option list by mistake. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Reopened] (PROTON-1703) [cpp] Remove auto_settle from receiver options
[ https://issues.apache.org/jira/browse/PROTON-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reopened PROTON-1703: > [cpp] Remove auto_settle from receiver options > -- > > Key: PROTON-1703 > URL: https://issues.apache.org/jira/browse/PROTON-1703 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.19.0 >Reporter: Alan Conway >Assignee: Alan Conway > > auto_settle is a sender-only option, the receiver equivalent is auto_accept. > auto_settle is only used at messaging_adapter.cpp#L172, which applies only to > senders, it was included in the option list by mistake. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1703) [cpp] Remove auto_settle from receiver options
[ https://issues.apache.org/jira/browse/PROTON-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-1703: --- Fix Version/s: (was: proton-c-0.19.0) > [cpp] Remove auto_settle from receiver options > -- > > Key: PROTON-1703 > URL: https://issues.apache.org/jira/browse/PROTON-1703 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.19.0 >Reporter: Alan Conway >Assignee: Alan Conway > > auto_settle is a sender-only option, the receiver equivalent is auto_accept. > auto_settle is only used at messaging_adapter.cpp#L172, which applies only to > senders, it was included in the option list by mistake. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1722) 0.20.0 release tasks
Robbie Gemmell created PROTON-1722: -- Summary: 0.20.0 release tasks Key: PROTON-1722 URL: https://issues.apache.org/jira/browse/PROTON-1722 Project: Qpid Proton Issue Type: Task Components: proton-c, release Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: proton-c-0.19.0 -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-831) Change conntector.cost default value to 1 instead of '1'
[ https://issues.apache.org/jira/browse/DISPATCH-831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16297310#comment-16297310 ] ASF subversion and git services commented on DISPATCH-831: -- Commit 86ef580e429beb68ac4167e8f96ca284f2668dd2 in qpid-dispatch's branch refs/heads/master from [~ganeshmurthy] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=86ef580 ] DISPATCH-831 - Set the default value of cost in connector to be 1 instead of '1' > Change conntector.cost default value to 1 instead of '1' > > > Key: DISPATCH-831 > URL: https://issues.apache.org/jira/browse/DISPATCH-831 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 0.8.0 >Reporter: Ernest Allen >Priority: Trivial > > The schema lists the connector.cost attribute as being an integer, however > the default value is the string '1'. This is causing javascript errors in the > console. I have a work-around for the console but it would be better to fix > this at the source. > Note: the listener.cost attribute is also an integer and it has an integer > value as the default so I'm assuming that nothing is relying on the default > value to be a string. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1718) (Proton-J) Custom Sasl
[
https://issues.apache.org/jira/browse/PROTON-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16297488#comment-16297488
]
Robbie Gemmell commented on PROTON-1718:
The comments applied to both commits and not just the second.
The Sasl API as originally intended for using proton as a byte level protocol
engine, how proton was envisaged and proton-j is mostly used, does let you
implement specific mechanisms and is being used to do so in various
clients/brokers/etc (though it wont let you send multiple init frames as thats
not intended by the protocol). The model provided by the Reactor, which some
folks added much later, rather hides it away in a fashion that makes it very
difficult to use in the originally intended way, hence my question around
whether thats really what you are hitting, which seems likely from prior
issues. As I say, perhaps a nicer approach can be found that doesn't leak the
implementation details, or is more specific to the Reactor since thats whats
causing the hassle. Alternatively perhaps something more general can be put
together in concert with the existing transport layering (which is essentially
all the sasl handling is) previously exposed via the TransportInternal
interface to allow other transport tinkering in the reactor model.
I'm heading off for the holidays now, so I won't be around for couple of weeks.
> (Proton-J) Custom Sasl
> --
>
> Key: PROTON-1718
> URL: https://issues.apache.org/jira/browse/PROTON-1718
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.24.0
>Reporter: Tim Taylor
> Labels: features
>
> I would like to be able to provide a custom SASL implementation for Proton-j
> to use instead of being forced to use the default SaslImpl.java
> implementation.
> Ideally, code like below would be possible
> private class CustomSasl implements org.apache.qpid.proton.engine.Sasl
> {
> ...
> }
> ...
> ...
> //transport.sasl(...) saves the provided sasl implementation and uses it
> internally
> Sasl sasl = transport.sasl(new CustomSasl());
> Do you currently have a workaround that would allow me to use Proton-J this
> way?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (PROTON-1718) (Proton-J) Custom Sasl
[
https://issues.apache.org/jira/browse/PROTON-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16297527#comment-16297527
]
Tim Taylor edited comment on PROTON-1718 at 12/19/17 10:20 PM:
---
Yes, my issue is more to do with how the Reactor does not allow users to alter
the Sasl operations in the ways that I outlined above.
Ignore the point of sending multiple init frames, I was mistaken. I do not need
to be able to do that.
I'll try exploring the possibility of a fix that is more tied to the reactor.
was (Author: timtay):
Yes, my issue is more to do with how the Reactor does not allow users to alter
the Sasl operations in a ways that I outlined above.
Ignore the point of sending multiple init frames, I was mistaken. I do not need
to be able to do that.
I'll try exploring the possibility of a fix that is more tied to the reactor.
> (Proton-J) Custom Sasl
> --
>
> Key: PROTON-1718
> URL: https://issues.apache.org/jira/browse/PROTON-1718
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.24.0
>Reporter: Tim Taylor
> Labels: features
>
> I would like to be able to provide a custom SASL implementation for Proton-j
> to use instead of being forced to use the default SaslImpl.java
> implementation.
> Ideally, code like below would be possible
> private class CustomSasl implements org.apache.qpid.proton.engine.Sasl
> {
> ...
> }
> ...
> ...
> //transport.sasl(...) saves the provided sasl implementation and uses it
> internally
> Sasl sasl = transport.sasl(new CustomSasl());
> Do you currently have a workaround that would allow me to use Proton-J this
> way?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1718) (Proton-J) Custom Sasl
[
https://issues.apache.org/jira/browse/PROTON-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16297527#comment-16297527
]
Tim Taylor commented on PROTON-1718:
Yes, my issue is more to do with how the Reactor does not allow users to alter
the Sasl operations in a ways that I outlined above.
Ignore the point of sending multiple init frames, I was mistaken. I do not need
to be able to do that.
I'll try exploring the possibility of a fix that is more tied to the reactor.
> (Proton-J) Custom Sasl
> --
>
> Key: PROTON-1718
> URL: https://issues.apache.org/jira/browse/PROTON-1718
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.24.0
>Reporter: Tim Taylor
> Labels: features
>
> I would like to be able to provide a custom SASL implementation for Proton-j
> to use instead of being forced to use the default SaslImpl.java
> implementation.
> Ideally, code like below would be possible
> private class CustomSasl implements org.apache.qpid.proton.engine.Sasl
> {
> ...
> }
> ...
> ...
> //transport.sasl(...) saves the provided sasl implementation and uses it
> internally
> Sasl sasl = transport.sasl(new CustomSasl());
> Do you currently have a workaround that would allow me to use Proton-J this
> way?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (PROTON-1718) (Proton-J) Custom Sasl
[
https://issues.apache.org/jira/browse/PROTON-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16297527#comment-16297527
]
Tim Taylor edited comment on PROTON-1718 at 12/19/17 10:27 PM:
---
Yes, my issue is more to do with how the Reactor does not allow users enough
control over the Sasl operations in the ways that I outlined above.
Ignore the point of sending multiple init frames, I was mistaken. I do not need
to be able to do that.
I'll try exploring the possibility of a fix that is more tied to the reactor.
was (Author: timtay):
Yes, my issue is more to do with how the Reactor does not allow users to alter
the Sasl operations in the ways that I outlined above.
Ignore the point of sending multiple init frames, I was mistaken. I do not need
to be able to do that.
I'll try exploring the possibility of a fix that is more tied to the reactor.
> (Proton-J) Custom Sasl
> --
>
> Key: PROTON-1718
> URL: https://issues.apache.org/jira/browse/PROTON-1718
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.24.0
>Reporter: Tim Taylor
> Labels: features
>
> I would like to be able to provide a custom SASL implementation for Proton-j
> to use instead of being forced to use the default SaslImpl.java
> implementation.
> Ideally, code like below would be possible
> private class CustomSasl implements org.apache.qpid.proton.engine.Sasl
> {
> ...
> }
> ...
> ...
> //transport.sasl(...) saves the provided sasl implementation and uses it
> internally
> Sasl sasl = transport.sasl(new CustomSasl());
> Do you currently have a workaround that would allow me to use Proton-J this
> way?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-6933) Factor out a JMS client neutral messaging test suite from system tests
[ https://issues.apache.org/jira/browse/QPID-6933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16297985#comment-16297985 ] ASF subversion and git services commented on QPID-6933: --- Commit 60db0d9f98ffc8bd302733594d19706f2c593187 in qpid-broker-j's branch refs/heads/master from [~k-wall] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=60db0d9 ] QPID-6933: [System Tests] Refactor BytesMessageTest, MapMessageTest, TextMessageTest as JMS 1.1 system tests > Factor out a JMS client neutral messaging test suite from system tests > -- > > Key: QPID-6933 > URL: https://issues.apache.org/jira/browse/QPID-6933 > Project: Qpid > Issue Type: Improvement > Components: Java Tests >Reporter: Keith Wall >Assignee: Alex Rudyy > > The existing system testsuite is in a poor state. > * It is poorly structured > * Mixes different types of test. i.e. messaging behaviour with those that > test features of the Java Broker (e.g. REST). > * Many of the tests refer directly to the implementation classes of the Qpid > Client 0-8..0-10 client meaning the tests cannot be run using the new client. > As a first step, we want to factor out a separate messaging system test suite: > * The tests in this suite will be JMS client neutral. > * Written in terms of JNDI/JMS client > * Configurations/Broker observations will be performed via a clean > Broker-neutral facade. For instance > ** a mechanism to cause the queue to be created of a particular type. > ** a mechanism to observe a queue depth. > * The tests will be classified by feature (to be defined) > * The classification system will be used to drive an exclusion feature (to be > defined). -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
