[jira] [Commented] (PROTON-2105) Support Go modules

2019-10-02 Thread Roddie Kieley (Jira)


[ 
https://issues.apache.org/jira/browse/PROTON-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943261#comment-16943261
 ] 

Roddie Kieley commented on PROTON-2105:
---

Thanks for the details and direction [~aconway]! Perhaps I should have read the 
readme sooner as I had completely forgotten any of the details I had previously 
known about the magic branch. 

Will proceed to prepare the re-organization and go 1.12 based go.mod file as 
above along with any build related changes as required. 

> Support Go modules
> --
>
> Key: PROTON-2105
> URL: https://issues.apache.org/jira/browse/PROTON-2105
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: go-binding
>Reporter: Ulf Lilleengen
>Assignee: Roddie Kieley
>Priority: Major
>
> As of Go 1.12, go module support is available. In order to manage 
> dependencies using go modules, dependencies must also be using go modules. 
> Therefore, adding a go.mod file to each module would allow qpid proton go 
> bindings to be managed as a go module.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Commented] (DISPATCH-1418) The default forwarding treatment is not overridden by the treatment in the address configuration

2019-10-02 Thread ASF subversion and git services (Jira)


[ 
https://issues.apache.org/jira/browse/DISPATCH-1418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943177#comment-16943177
 ] 

ASF subversion and git services commented on DISPATCH-1418:
---

Commit fc9c4380d796656ad964e04bb389d3223d94b1c5 in qpid-dispatch's branch 
refs/heads/master from Ken Giusti
[ https://gitbox.apache.org/repos/asf?p=qpid-dispatch.git;h=fc9c438 ]

DISPATCH-1418: use proper outcome for deliveries to unavailable addresses

Use the configured address treatment if available. Otherwise use the
router default treatment.

This closes #579


> The default forwarding treatment is not overridden by the treatment in the 
> address configuration
> 
>
> Key: DISPATCH-1418
> URL: https://issues.apache.org/jira/browse/DISPATCH-1418
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Routing Engine
>Affects Versions: 1.8.0, 1.9.0
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Major
>
> When a message cannot be forwarded the message should be released.
> However, when the forwarding treatment is "unavailable" that message must be 
> REJECTED (as per the description of the "unavailable" treatment).
> When the router tries to determine if the outcome should be RELEASED or 
> REJECTED it does not check for a matching router.config.address configuration 
> entity.  This entity contains a treatment for the given address.  If an 
> address configuration matches the address the treatment should come from the 
> address configuration - not the router default configuration.
> To reproduce:
> Configure a router with defaultTreatment set to unavailable.
> Configure an address prefix that uses the "closest" treatment.
> Attach a sender to the router using an anonymous link.
> Send a message to an address that will match the configured address prefix 
> while there are no subscribers.
> Expect: the message be RELEASED by the router
> Actual: the message is REJECTED by the router



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Commented] (DISPATCH-1418) The default forwarding treatment is not overridden by the treatment in the address configuration

2019-10-02 Thread ASF GitHub Bot (Jira)


[ 
https://issues.apache.org/jira/browse/DISPATCH-1418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943178#comment-16943178
 ] 

ASF GitHub Bot commented on DISPATCH-1418:
--

asfgit commented on pull request #579: DISPATCH-1418: use proper outcome for 
deliveries to unavailable addre…
URL: https://github.com/apache/qpid-dispatch/pull/579
 
 
   
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> The default forwarding treatment is not overridden by the treatment in the 
> address configuration
> 
>
> Key: DISPATCH-1418
> URL: https://issues.apache.org/jira/browse/DISPATCH-1418
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Routing Engine
>Affects Versions: 1.8.0, 1.9.0
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Major
>
> When a message cannot be forwarded the message should be released.
> However, when the forwarding treatment is "unavailable" that message must be 
> REJECTED (as per the description of the "unavailable" treatment).
> When the router tries to determine if the outcome should be RELEASED or 
> REJECTED it does not check for a matching router.config.address configuration 
> entity.  This entity contains a treatment for the given address.  If an 
> address configuration matches the address the treatment should come from the 
> address configuration - not the router default configuration.
> To reproduce:
> Configure a router with defaultTreatment set to unavailable.
> Configure an address prefix that uses the "closest" treatment.
> Attach a sender to the router using an anonymous link.
> Send a message to an address that will match the configured address prefix 
> while there are no subscribers.
> Expect: the message be RELEASED by the router
> Actual: the message is REJECTED by the router



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[GitHub] [qpid-dispatch] asfgit closed pull request #579: DISPATCH-1418: use proper outcome for deliveries to unavailable addre…

2019-10-02 Thread GitBox
asfgit closed pull request #579: DISPATCH-1418: use proper outcome for 
deliveries to unavailable addre…
URL: https://github.com/apache/qpid-dispatch/pull/579
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Updated] (DISPATCH-1418) The default forwarding treatment is not overridden by the treatment in the address configuration

2019-10-02 Thread Ken Giusti (Jira)


 [ 
https://issues.apache.org/jira/browse/DISPATCH-1418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ken Giusti updated DISPATCH-1418:
-
Description: 
When a message cannot be forwarded the message should be released.

However, when the forwarding treatment is "unavailable" that message must be 
REJECTED (as per the description of the "unavailable" treatment).

When the router tries to determine if the outcome should be RELEASED or 
REJECTED it does not check for a matching router.config.address configuration 
entity.  This entity contains a treatment for the given address.  If an address 
configuration matches the address the treatment should come from the address 
configuration - not the router default configuration.

To reproduce:
Configure a router with defaultTreatment set to unavailable.
Configure an address prefix that uses the "closest" treatment.
Attach a sender to the router using an anonymous link.
Send a message to an address that will match the configured address prefix 
while there are no subscribers.

Expect: the message be RELEASED by the router
Actual: the message is REJECTED by the router



  was:
When a message cannot be forwarded the message should be released.

However, when the forwarding treatment is "unavailable" that message must be 
REJECTED (as per the description of the "unavailable treatment).

When the router tries to determine if the outcome should be RELEASED or 
REJECTED it does not check for a matching router.config.address configuration 
entity.  This entity contains a treatment for the given address.  If an address 
configuration matches the address the treatment should come from the address 
configuration - not the router default configuration.

To reproduce:
Configure a router with defaultTreatment set to unavailable.
Configure an address prefix that uses the "closest" treatment.
Attach a sender to the router using an anonymous link.
Send a message to an address that will match the configured address prefix 
while there are no subscribers.

Expect: the message be RELEASED by the router
Actual: the message is REJECTED by the router




> The default forwarding treatment is not overridden by the treatment in the 
> address configuration
> 
>
> Key: DISPATCH-1418
> URL: https://issues.apache.org/jira/browse/DISPATCH-1418
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Routing Engine
>Affects Versions: 1.8.0, 1.9.0
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Major
>
> When a message cannot be forwarded the message should be released.
> However, when the forwarding treatment is "unavailable" that message must be 
> REJECTED (as per the description of the "unavailable" treatment).
> When the router tries to determine if the outcome should be RELEASED or 
> REJECTED it does not check for a matching router.config.address configuration 
> entity.  This entity contains a treatment for the given address.  If an 
> address configuration matches the address the treatment should come from the 
> address configuration - not the router default configuration.
> To reproduce:
> Configure a router with defaultTreatment set to unavailable.
> Configure an address prefix that uses the "closest" treatment.
> Attach a sender to the router using an anonymous link.
> Send a message to an address that will match the configured address prefix 
> while there are no subscribers.
> Expect: the message be RELEASED by the router
> Actual: the message is REJECTED by the router



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Updated] (DISPATCH-1418) The default forwarding treatment is not overridden by the treatment in the address configuration

2019-10-02 Thread Ken Giusti (Jira)


 [ 
https://issues.apache.org/jira/browse/DISPATCH-1418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ken Giusti updated DISPATCH-1418:
-
Description: 
When a message cannot be forwarded the message should be released.

However, when the forwarding treatment is "unavailable" that message must be 
REJECTED (as per the description of the "unavailable treatment).

When the router tries to determine if the outcome should be RELEASED or 
REJECTED it does not check for a matching router.config.address configuration 
entity.  This entity contains a treatment for the given address.  If an address 
configuration matches the address the treatment should come from the address 
configuration - not the router default configuration.

To reproduce:
Configure a router with defaultTreatment set to unavailable.
Configure an address prefix that uses the "closest" treatment.
Attach a sender to the router using an anonymous link.
Send a message to an address that will match the configured address prefix 
while there are no subscribers.

Expect: the message be RELEASED by the router
Actual: the message is REJECTED by the router



  was:
Attach a sender to the router using an anonymous link.
Send a message to an address that is pre-configured (say "closest/foo") while 
there are no subscribers.

Expect: the message be RELEASED by the router
Actual: the message is REJECTED by the router

See system_tests_router_mesh.py


> The default forwarding treatment is not overridden by the treatment in the 
> address configuration
> 
>
> Key: DISPATCH-1418
> URL: https://issues.apache.org/jira/browse/DISPATCH-1418
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Routing Engine
>Affects Versions: 1.8.0, 1.9.0
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Major
>
> When a message cannot be forwarded the message should be released.
> However, when the forwarding treatment is "unavailable" that message must be 
> REJECTED (as per the description of the "unavailable treatment).
> When the router tries to determine if the outcome should be RELEASED or 
> REJECTED it does not check for a matching router.config.address configuration 
> entity.  This entity contains a treatment for the given address.  If an 
> address configuration matches the address the treatment should come from the 
> address configuration - not the router default configuration.
> To reproduce:
> Configure a router with defaultTreatment set to unavailable.
> Configure an address prefix that uses the "closest" treatment.
> Attach a sender to the router using an anonymous link.
> Send a message to an address that will match the configured address prefix 
> while there are no subscribers.
> Expect: the message be RELEASED by the router
> Actual: the message is REJECTED by the router



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Updated] (DISPATCH-1418) The default forwarding treatment is not overridden by the treatment in the address configuration

2019-10-02 Thread Ken Giusti (Jira)


 [ 
https://issues.apache.org/jira/browse/DISPATCH-1418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ken Giusti updated DISPATCH-1418:
-
Summary: The default forwarding treatment is not overridden by the 
treatment in the address configuration  (was: sending a msg to a configured 
address w/o subscribers should RELEASE not REJECT)

> The default forwarding treatment is not overridden by the treatment in the 
> address configuration
> 
>
> Key: DISPATCH-1418
> URL: https://issues.apache.org/jira/browse/DISPATCH-1418
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Routing Engine
>Affects Versions: 1.8.0, 1.9.0
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Major
>
> Attach a sender to the router using an anonymous link.
> Send a message to an address that is pre-configured (say "closest/foo") while 
> there are no subscribers.
> Expect: the message be RELEASED by the router
> Actual: the message is REJECTED by the router
> See system_tests_router_mesh.py



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Resolved] (DISPATCH-1327) Router stops forwarding multicast deliveries (large messages) to connected receivers after a receiver closes its connection

2019-10-02 Thread Ken Giusti (Jira)


 [ 
https://issues.apache.org/jira/browse/DISPATCH-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ken Giusti resolved DISPATCH-1327.
--
Resolution: Cannot Reproduce

I have not been able to repro this with the latest master (10/02/2019).

If this problem is still present please re-open this bug.

> Router stops forwarding multicast deliveries (large messages) to connected 
> receivers after a receiver closes its connection
> ---
>
> Key: DISPATCH-1327
> URL: https://issues.apache.org/jira/browse/DISPATCH-1327
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Routing Engine
>Affects Versions: 1.7.0
>Reporter: Fernando Giorgetti
>Assignee: Ken Giusti
>Priority: Major
>
> The problem can be observed running 
> *test_40_drop_rx_client_multicast_large_message*** from 
> *system_tests_edge_router*.
> It does not happen all the time, but after some attempts it will fail and we 
> can observe receivers won't get all sent messages and then test times out.
> Further info to be attached.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Resolved] (DISPATCH-1431) system_tests_one_router_failing on test_19_semantics_multicast

2019-10-02 Thread Ken Giusti (Jira)


 [ 
https://issues.apache.org/jira/browse/DISPATCH-1431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ken Giusti resolved DISPATCH-1431.
--
Resolution: Fixed

> system_tests_one_router_failing on test_19_semantics_multicast
> --
>
> Key: DISPATCH-1431
> URL: https://issues.apache.org/jira/browse/DISPATCH-1431
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Tests
>Affects Versions: 1.9.0
>Reporter: Ganesh Murthy
>Assignee: Ken Giusti
>Priority: Major
> Fix For: 1.10.0
>
>
> Turn on valgrind and compile the router code.
> {noformat}
> make clean
> cmake .. -DUSE_VALGRIND=Yes -DVALGRIND_XML=Yes
> make install{noformat}
> Then run test_19_semantics_multicast
> {noformat}
> [gmurthy@localhost build]$ /usr/bin/python 
> "/home/gmurthy/opensource/qpid-dispatch/build/tests/run.py" "-m" "unittest" 
> "-v" "system_tests_one_router.OneRouterTest.test_19_semantics_multicast"
> test_19_semantics_multicast (system_tests_one_router.OneRouterTest) ... 
> FAIL==
> FAIL: test_19_semantics_multicast (system_tests_one_router.OneRouterTest)
> --
> Traceback (most recent call last):
>   File 
> "/home/gmurthy/opensource/qpid-dispatch/tests/system_tests_one_router.py", 
> line 264, in test_19_semantics_multicast
> self.assertEqual(None, test.error)
> AssertionError: None != u'Timeout Expired: sent=1 
> rcvd=0/1/0'--
> Ran 1 test in 65.460sFAILED (failures=1)
> [gmurthy@localhost build]$ 
>  {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Commented] (DISPATCH-1431) system_tests_one_router_failing on test_19_semantics_multicast

2019-10-02 Thread ASF subversion and git services (Jira)


[ 
https://issues.apache.org/jira/browse/DISPATCH-1431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943155#comment-16943155
 ] 

ASF subversion and git services commented on DISPATCH-1431:
---

Commit ff971d416bc20048f0576176b54c36ef7ebcea38 in qpid-dispatch's branch 
refs/heads/master from Ken Giusti
[ https://gitbox.apache.org/repos/asf?p=qpid-dispatch.git;h=ff971d4 ]

DISPATCH-1431: fix system_tests_one_router multicast test client race


> system_tests_one_router_failing on test_19_semantics_multicast
> --
>
> Key: DISPATCH-1431
> URL: https://issues.apache.org/jira/browse/DISPATCH-1431
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Tests
>Affects Versions: 1.9.0
>Reporter: Ganesh Murthy
>Assignee: Ken Giusti
>Priority: Major
> Fix For: 1.10.0
>
>
> Turn on valgrind and compile the router code.
> {noformat}
> make clean
> cmake .. -DUSE_VALGRIND=Yes -DVALGRIND_XML=Yes
> make install{noformat}
> Then run test_19_semantics_multicast
> {noformat}
> [gmurthy@localhost build]$ /usr/bin/python 
> "/home/gmurthy/opensource/qpid-dispatch/build/tests/run.py" "-m" "unittest" 
> "-v" "system_tests_one_router.OneRouterTest.test_19_semantics_multicast"
> test_19_semantics_multicast (system_tests_one_router.OneRouterTest) ... 
> FAIL==
> FAIL: test_19_semantics_multicast (system_tests_one_router.OneRouterTest)
> --
> Traceback (most recent call last):
>   File 
> "/home/gmurthy/opensource/qpid-dispatch/tests/system_tests_one_router.py", 
> line 264, in test_19_semantics_multicast
> self.assertEqual(None, test.error)
> AssertionError: None != u'Timeout Expired: sent=1 
> rcvd=0/1/0'--
> Ran 1 test in 65.460sFAILED (failures=1)
> [gmurthy@localhost build]$ 
>  {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Commented] (DISPATCH-1431) system_tests_one_router_failing on test_19_semantics_multicast

2019-10-02 Thread Ken Giusti (Jira)


[ 
https://issues.apache.org/jira/browse/DISPATCH-1431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943130#comment-16943130
 ] 

Ken Giusti commented on DISPATCH-1431:
--

This is a race condition on the test itself:

The sender is sending it's one test message before all receivers have completed 
attaching.  So the multicast only goes to one or two clients and the test times 
out since it is waiting for all three receivers to get a copy.

> system_tests_one_router_failing on test_19_semantics_multicast
> --
>
> Key: DISPATCH-1431
> URL: https://issues.apache.org/jira/browse/DISPATCH-1431
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Tests
>Affects Versions: 1.9.0
>Reporter: Ganesh Murthy
>Assignee: Ken Giusti
>Priority: Major
> Fix For: 1.10.0
>
>
> Turn on valgrind and compile the router code.
> {noformat}
> make clean
> cmake .. -DUSE_VALGRIND=Yes -DVALGRIND_XML=Yes
> make install{noformat}
> Then run test_19_semantics_multicast
> {noformat}
> [gmurthy@localhost build]$ /usr/bin/python 
> "/home/gmurthy/opensource/qpid-dispatch/build/tests/run.py" "-m" "unittest" 
> "-v" "system_tests_one_router.OneRouterTest.test_19_semantics_multicast"
> test_19_semantics_multicast (system_tests_one_router.OneRouterTest) ... 
> FAIL==
> FAIL: test_19_semantics_multicast (system_tests_one_router.OneRouterTest)
> --
> Traceback (most recent call last):
>   File 
> "/home/gmurthy/opensource/qpid-dispatch/tests/system_tests_one_router.py", 
> line 264, in test_19_semantics_multicast
> self.assertEqual(None, test.error)
> AssertionError: None != u'Timeout Expired: sent=1 
> rcvd=0/1/0'--
> Ran 1 test in 65.460sFAILED (failures=1)
> [gmurthy@localhost build]$ 
>  {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Commented] (DISPATCH-1418) sending a msg to a configured address w/o subscribers should RELEASE not REJECT

2019-10-02 Thread ASF GitHub Bot (Jira)


[ 
https://issues.apache.org/jira/browse/DISPATCH-1418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943123#comment-16943123
 ] 

ASF GitHub Bot commented on DISPATCH-1418:
--

kgiusti commented on pull request #579: DISPATCH-1418: use proper outcome for 
deliveries to unavailable addre…
URL: https://github.com/apache/qpid-dispatch/pull/579
 
 
   …sses
   
   Use the configured address treatment if available. Otherwise use the
   router default treatment.
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> sending a msg to a configured address w/o subscribers should RELEASE not 
> REJECT
> ---
>
> Key: DISPATCH-1418
> URL: https://issues.apache.org/jira/browse/DISPATCH-1418
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Routing Engine
>Affects Versions: 1.8.0, 1.9.0
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Major
>
> Attach a sender to the router using an anonymous link.
> Send a message to an address that is pre-configured (say "closest/foo") while 
> there are no subscribers.
> Expect: the message be RELEASED by the router
> Actual: the message is REJECTED by the router
> See system_tests_router_mesh.py



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[GitHub] [qpid-dispatch] kgiusti opened a new pull request #579: DISPATCH-1418: use proper outcome for deliveries to unavailable addre…

2019-10-02 Thread GitBox
kgiusti opened a new pull request #579: DISPATCH-1418: use proper outcome for 
deliveries to unavailable addre…
URL: https://github.com/apache/qpid-dispatch/pull/579
 
 
   …sses
   
   Use the configured address treatment if available. Otherwise use the
   router default treatment.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Resolved] (DISPATCH-1399) Allow arrows on console's topology page to be disabled

2019-10-02 Thread Ernest Allen (Jira)


 [ 
https://issues.apache.org/jira/browse/DISPATCH-1399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ernest Allen resolved DISPATCH-1399.

Fix Version/s: 1.10.0
   Resolution: Implemented

> Allow arrows on console's topology page to be disabled
> --
>
> Key: DISPATCH-1399
> URL: https://issues.apache.org/jira/browse/DISPATCH-1399
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Console
>Affects Versions: 1.8.0
>Reporter: Ernest Allen
>Assignee: Ernest Allen
>Priority: Major
> Fix For: 1.10.0
>
>
> The topology diagram shows the direction that connections are initiated. The 
> router with the listener has the arrow pointing to it.
> This can be confusing since there is actually bi-directional traffic going 
> over the connection's links.
> There should be an option to hide the arrows.
> The arrows should be hidden by default.
> The current state of the arrows (visible/hidden) should be remembered (per 
> browser) and restored.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Updated] (DISPATCH-1434) Add new attribute saslPasswordFile to the connector entity

2019-10-02 Thread John Andrunas (Jira)


 [ 
https://issues.apache.org/jira/browse/DISPATCH-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Andrunas updated DISPATCH-1434:

Reporter: Ganesh Murthy  (was: gmurthy-foo)

> Add new attribute saslPasswordFile to the connector entity
> --
>
> Key: DISPATCH-1434
> URL: https://issues.apache.org/jira/browse/DISPATCH-1434
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Container
>Affects Versions: 1.9.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.10.0
>
>
> Add a new attribute called saslPasswordFile to the connector entity. This 
> will enable users to specify the saslPassword in a file instead of specifying 
> it in the config file.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Updated] (DISPATCH-1436) Don't allow both password and passwordFile to be specified in sslProfile

2019-10-02 Thread John Andrunas (Jira)


 [ 
https://issues.apache.org/jira/browse/DISPATCH-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Andrunas updated DISPATCH-1436:

Reporter: Ganesh Murthy  (was: gmurthy-foo)

> Don't allow both password and passwordFile to be specified in sslProfile  
> --
>
> Key: DISPATCH-1436
> URL: https://issues.apache.org/jira/browse/DISPATCH-1436
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Container, Management Agent
>Affects Versions: 1.9.0
>Reporter: Ganesh Murthy
>Assignee: gmurthy-foo
>Priority: Major
>
> Currently, the password field takes precedence over passwordFile when both 
> are specified in the sslProfile entity.
> The router should not start if both are specified.
> qdmanage commands specifying both must result in Bad Request.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Assigned] (DISPATCH-1433) system_tests_delivery_abort failing due to receiver connecting late

2019-10-02 Thread John Andrunas (Jira)


 [ 
https://issues.apache.org/jira/browse/DISPATCH-1433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Andrunas reassigned DISPATCH-1433:
---

Assignee: Ganesh Murthy  (was: gmurthy-foo)

> system_tests_delivery_abort failing due to receiver connecting late
> ---
>
> Key: DISPATCH-1433
> URL: https://issues.apache.org/jira/browse/DISPATCH-1433
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 1.9.0
>Reporter: gmurthy-foo
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.10.0
>
>
> {noformat}
> "40: test_07_multicast_truncate_one_router 
> (system_tests_delivery_abort.RouterTest) ... FAIL", 
> "40: ", 
> "40: 
> ==", 
> "40: FAIL: test_07_multicast_truncate_one_router 
> (system_tests_delivery_abort.RouterTest)", 
> "40: 
> --", 
> "40: Traceback (most recent call last):", 
> "40:   File 
> \"/opt/qpid-dispatch-src/tests/system_tests_delivery_abort.py\", line 127, in 
> test_07_multicast_truncate_one_router", 
> "40: self.assertEqual(None, test.error)", 
> "40: AssertionError: None != u\"Expected: [u'Send_Short_1', 
> u'Aborted_Delivery', u'2', u'2', u'2', u'2', u'2', u'2', u'2', u'2', u'2', 
> u'2', u'Send_Short_2', u'3', u'3', u'3', u'3', u'3', u'3', u'3', u'3', u'3', 
> u'3', u'Send_Short_3'], Actuals: [u'Aborted_Delivery', u'2', u'2', u'2', 
> u'2', u'2', u'2', u'2', u'2', u'2', u'2', u'Send_Short_2', u'3', u'3', u'3', 
> u'3', u'3', u'3', u'3', u'3', u'3', u'3', u'Send_Short_3'], [u'Send_Short_1', 
> u'Aborted_Delivery', u'2', u'2', u'2', u'2', u'2', u'2', u'2', u'2', u'2', 
> u'2', u'Send_Short_2', u'3', u'3', u'3', u'3', u'3', u'3', u'3', u'3', u'3', 
> u'3', u'Send_Short_3']\"", 
> "40: ", 
> "40: 
> --", 
> "40: Ran 7 tests in 15.769s", 
> "40: ", 
> "40: FAILED (failures=1)", 
> "40/59 Test #40: system_tests_delivery_abort 
> ...***Failed   15.93 sec", 
> "test 41",  {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Updated] (DISPATCH-1433) system_tests_delivery_abort failing due to receiver connecting late

2019-10-02 Thread John Andrunas (Jira)


 [ 
https://issues.apache.org/jira/browse/DISPATCH-1433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Andrunas updated DISPATCH-1433:

Reporter: Ganesh Murthy  (was: gmurthy-foo)

> system_tests_delivery_abort failing due to receiver connecting late
> ---
>
> Key: DISPATCH-1433
> URL: https://issues.apache.org/jira/browse/DISPATCH-1433
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 1.9.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.10.0
>
>
> {noformat}
> "40: test_07_multicast_truncate_one_router 
> (system_tests_delivery_abort.RouterTest) ... FAIL", 
> "40: ", 
> "40: 
> ==", 
> "40: FAIL: test_07_multicast_truncate_one_router 
> (system_tests_delivery_abort.RouterTest)", 
> "40: 
> --", 
> "40: Traceback (most recent call last):", 
> "40:   File 
> \"/opt/qpid-dispatch-src/tests/system_tests_delivery_abort.py\", line 127, in 
> test_07_multicast_truncate_one_router", 
> "40: self.assertEqual(None, test.error)", 
> "40: AssertionError: None != u\"Expected: [u'Send_Short_1', 
> u'Aborted_Delivery', u'2', u'2', u'2', u'2', u'2', u'2', u'2', u'2', u'2', 
> u'2', u'Send_Short_2', u'3', u'3', u'3', u'3', u'3', u'3', u'3', u'3', u'3', 
> u'3', u'Send_Short_3'], Actuals: [u'Aborted_Delivery', u'2', u'2', u'2', 
> u'2', u'2', u'2', u'2', u'2', u'2', u'2', u'Send_Short_2', u'3', u'3', u'3', 
> u'3', u'3', u'3', u'3', u'3', u'3', u'3', u'Send_Short_3'], [u'Send_Short_1', 
> u'Aborted_Delivery', u'2', u'2', u'2', u'2', u'2', u'2', u'2', u'2', u'2', 
> u'2', u'Send_Short_2', u'3', u'3', u'3', u'3', u'3', u'3', u'3', u'3', u'3', 
> u'3', u'Send_Short_3']\"", 
> "40: ", 
> "40: 
> --", 
> "40: Ran 7 tests in 15.769s", 
> "40: ", 
> "40: FAILED (failures=1)", 
> "40/59 Test #40: system_tests_delivery_abort 
> ...***Failed   15.93 sec", 
> "test 41",  {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Assigned] (DISPATCH-1436) Don't allow both password and passwordFile to be specified in sslProfile

2019-10-02 Thread John Andrunas (Jira)


 [ 
https://issues.apache.org/jira/browse/DISPATCH-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Andrunas reassigned DISPATCH-1436:
---

Assignee: Ganesh Murthy  (was: gmurthy-foo)

> Don't allow both password and passwordFile to be specified in sslProfile  
> --
>
> Key: DISPATCH-1436
> URL: https://issues.apache.org/jira/browse/DISPATCH-1436
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Container, Management Agent
>Affects Versions: 1.9.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
>
> Currently, the password field takes precedence over passwordFile when both 
> are specified in the sslProfile entity.
> The router should not start if both are specified.
> qdmanage commands specifying both must result in Bad Request.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Closed] (DISPATCH-1437) TEST ISSUE CREATION - WILL CLOSE THIS

2019-10-02 Thread Ganesh Murthy (Jira)


 [ 
https://issues.apache.org/jira/browse/DISPATCH-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ganesh Murthy closed DISPATCH-1437.
---

> TEST ISSUE CREATION - WILL CLOSE THIS
> -
>
> Key: DISPATCH-1437
> URL: https://issues.apache.org/jira/browse/DISPATCH-1437
> Project: Qpid Dispatch
>  Issue Type: Task
>  Components: Management Agent
>Affects Versions: 1.9.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.10.0
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Created] (DISPATCH-1437) TEST ISSUE CREATION - WILL CLOSE THIS

2019-10-02 Thread Ganesh Murthy (Jira)
Ganesh Murthy created DISPATCH-1437:
---

 Summary: TEST ISSUE CREATION - WILL CLOSE THIS
 Key: DISPATCH-1437
 URL: https://issues.apache.org/jira/browse/DISPATCH-1437
 Project: Qpid Dispatch
  Issue Type: Task
  Components: Management Agent
Affects Versions: 1.9.0
Reporter: Ganesh Murthy
Assignee: Ganesh Murthy
 Fix For: 1.10.0






--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Resolved] (DISPATCH-1437) TEST ISSUE CREATION - WILL CLOSE THIS

2019-10-02 Thread Ganesh Murthy (Jira)


 [ 
https://issues.apache.org/jira/browse/DISPATCH-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ganesh Murthy resolved DISPATCH-1437.
-
Resolution: Invalid

> TEST ISSUE CREATION - WILL CLOSE THIS
> -
>
> Key: DISPATCH-1437
> URL: https://issues.apache.org/jira/browse/DISPATCH-1437
> Project: Qpid Dispatch
>  Issue Type: Task
>  Components: Management Agent
>Affects Versions: 1.9.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.10.0
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Assigned] (DISPATCH-1434) Add new attribute saslPasswordFile to the connector entity

2019-10-02 Thread Ganesh Murthy (Jira)


 [ 
https://issues.apache.org/jira/browse/DISPATCH-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ganesh Murthy reassigned DISPATCH-1434:
---

Assignee: Ganesh Murthy  (was: gmurthy#1)

> Add new attribute saslPasswordFile to the connector entity
> --
>
> Key: DISPATCH-1434
> URL: https://issues.apache.org/jira/browse/DISPATCH-1434
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Container
>Affects Versions: 1.9.0
>Reporter: gmurthy#1
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.10.0
>
>
> Add a new attribute called saslPasswordFile to the connector entity. This 
> will enable users to specify the saslPassword in a file instead of specifying 
> it in the config file.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Commented] (QPID-8364) [Broker-J] Add support for SPNEGO authentication into HTTP management

2019-10-02 Thread ASF subversion and git services (Jira)


[ 
https://issues.apache.org/jira/browse/QPID-8364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943028#comment-16943028
 ] 

ASF subversion and git services commented on QPID-8364:
---

Commit 748ec6880feb2f25242586332937e299aee0f485 in qpid-broker-j's branch 
refs/heads/7.1.x from Alex Rudyy
[ https://gitbox.apache.org/repos/asf?p=qpid-broker-j.git;h=748ec68 ]

QPID-8364: [Broker-J] Fix tests

(cherry picked from commit 19ad881bf2297742ac5aff7a1538277464550df0)


> [Broker-J] Add support for SPNEGO authentication into HTTP management
> -
>
> Key: QPID-8364
> URL: https://issues.apache.org/jira/browse/QPID-8364
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.5
>
>
> The Kerberos Authentication is only supported for messaging connections. The 
> support for Kerberos SPENEGO Authentication needs to be implemented for HTTP 
> management. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Commented] (QPID-8364) [Broker-J] Add support for SPNEGO authentication into HTTP management

2019-10-02 Thread ASF subversion and git services (Jira)


[ 
https://issues.apache.org/jira/browse/QPID-8364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943027#comment-16943027
 ] 

ASF subversion and git services commented on QPID-8364:
---

Commit 19ad881bf2297742ac5aff7a1538277464550df0 in qpid-broker-j's branch 
refs/heads/master from Alex Rudyy
[ https://gitbox.apache.org/repos/asf?p=qpid-broker-j.git;h=19ad881 ]

QPID-8364: [Broker-J] Fix tests


> [Broker-J] Add support for SPNEGO authentication into HTTP management
> -
>
> Key: QPID-8364
> URL: https://issues.apache.org/jira/browse/QPID-8364
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.5
>
>
> The Kerberos Authentication is only supported for messaging connections. The 
> support for Kerberos SPENEGO Authentication needs to be implemented for HTTP 
> management. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Commented] (QPID-8357) [Broker-J][AMQP 1.0] Broker-J does not set property 'open' performative property 'sole-connection-eforcement-policy' when 'close-existing' eforcement policy is requested

2019-10-02 Thread ASF subversion and git services (Jira)


[ 
https://issues.apache.org/jira/browse/QPID-8357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942987#comment-16942987
 ] 

ASF subversion and git services commented on QPID-8357:
---

Commit 5589cd139515fbb1e3a73911c30e3ea235c7b3a6 in qpid-broker-j's branch 
refs/heads/7.1.x from Alex Rudyy
[ https://gitbox.apache.org/repos/asf?p=qpid-broker-j.git;h=5589cd1 ]

QPID-8357: [Broker-J][AMQP 1.0][Sole connection] Broker should set open 
property 'sole-connection-eforcement-policy' when 'close-existing' eforcement 
policy is requested

(cherry picked from commit c4fae61eb8d89c9b20122e75691307ce82a8aaeb)


> [Broker-J][AMQP 1.0] Broker-J does not set property 'open' performative 
> property 'sole-connection-eforcement-policy' when 'close-existing' eforcement 
> policy is requested
> -
>
> Key: QPID-8357
> URL: https://issues.apache.org/jira/browse/QPID-8357
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.4
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.5
>
>
> Broker should set {{open}} performative property 
> {{sole-connection-eforcement-policy'}} when {{close-existing}} eforcement 
> policy is requested. Otherwise, peer might assume that policy 
> {{refuse-connection}} is used.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Updated] (QPID-8357) [Broker-J][AMQP 1.0] Broker-J does not set property 'open' performative property 'sole-connection-eforcement-policy' when 'close-existing' eforcement policy is requested

2019-10-02 Thread Alex Rudyy (Jira)


 [ 
https://issues.apache.org/jira/browse/QPID-8357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8357:
-
Fix Version/s: qpid-java-broker-8.0.0

> [Broker-J][AMQP 1.0] Broker-J does not set property 'open' performative 
> property 'sole-connection-eforcement-policy' when 'close-existing' eforcement 
> policy is requested
> -
>
> Key: QPID-8357
> URL: https://issues.apache.org/jira/browse/QPID-8357
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.4
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.5
>
>
> Broker should set {{open}} performative property 
> {{sole-connection-eforcement-policy'}} when {{close-existing}} eforcement 
> policy is requested. Otherwise, peer might assume that policy 
> {{refuse-connection}} is used.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[GitHub] [qpid-proton] gemmellr commented on issue #194: ENTMQCL-1062:[CMake] Fixing an issue with cmake not compiling c++11 e…

2019-10-02 Thread GitBox
gemmellr commented on issue #194: ENTMQCL-1062:[CMake] Fixing an issue with 
cmake not compiling c++11 e…
URL: https://github.com/apache/qpid-proton/pull/194#issuecomment-537572146
 
 
   Can you please [raise and/or] reference a PROTON Jira key in your PR titles 
and commit logs.
   
   https://issues.apache.org/jira/projects/PROTON


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Resolved] (DISPATCH-1434) Add new attribute saslPasswordFile to the connector entity

2019-10-02 Thread Ganesh Murthy (Jira)


 [ 
https://issues.apache.org/jira/browse/DISPATCH-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ganesh Murthy resolved DISPATCH-1434.
-
Fix Version/s: 1.10.0
   Resolution: Fixed

> Add new attribute saslPasswordFile to the connector entity
> --
>
> Key: DISPATCH-1434
> URL: https://issues.apache.org/jira/browse/DISPATCH-1434
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Container
>Affects Versions: 1.9.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.10.0
>
>
> Add a new attribute called saslPasswordFile to the connector entity. This 
> will enable users to specify the saslPassword in a file instead of specifying 
> it in the config file.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Commented] (DISPATCH-1434) Add new attribute saslPasswordFile to the connector entity

2019-10-02 Thread ASF GitHub Bot (Jira)


[ 
https://issues.apache.org/jira/browse/DISPATCH-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942944#comment-16942944
 ] 

ASF GitHub Bot commented on DISPATCH-1434:
--

asfgit commented on pull request #578: DISPATCH-1434 - Added new attribute 
saslPasswordFile to the connector…
URL: https://github.com/apache/qpid-dispatch/pull/578
 
 
   
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Add new attribute saslPasswordFile to the connector entity
> --
>
> Key: DISPATCH-1434
> URL: https://issues.apache.org/jira/browse/DISPATCH-1434
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Container
>Affects Versions: 1.9.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
>
> Add a new attribute called saslPasswordFile to the connector entity. This 
> will enable users to specify the saslPassword in a file instead of specifying 
> it in the config file.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Commented] (DISPATCH-1434) Add new attribute saslPasswordFile to the connector entity

2019-10-02 Thread ASF subversion and git services (Jira)


[ 
https://issues.apache.org/jira/browse/DISPATCH-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942943#comment-16942943
 ] 

ASF subversion and git services commented on DISPATCH-1434:
---

Commit a97dea9aace6142d58f70caf66710386dc3e1156 in qpid-dispatch's branch 
refs/heads/master from Ganesh Murthy
[ https://gitbox.apache.org/repos/asf?p=qpid-dispatch.git;h=a97dea9 ]

DISPATCH-1434 - Added new attribute saslPasswordFile to the connector entity. 
saslPassword entity has been deprecated. This closes #578.


> Add new attribute saslPasswordFile to the connector entity
> --
>
> Key: DISPATCH-1434
> URL: https://issues.apache.org/jira/browse/DISPATCH-1434
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Container
>Affects Versions: 1.9.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
>
> Add a new attribute called saslPasswordFile to the connector entity. This 
> will enable users to specify the saslPassword in a file instead of specifying 
> it in the config file.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[GitHub] [qpid-dispatch] asfgit closed pull request #578: DISPATCH-1434 - Added new attribute saslPasswordFile to the connector…

2019-10-02 Thread GitBox
asfgit closed pull request #578: DISPATCH-1434 - Added new attribute 
saslPasswordFile to the connector…
URL: https://github.com/apache/qpid-dispatch/pull/578
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Commented] (QPID-8361) [Broker-J] Create a developer guide for Qpid Broker-J

2019-10-02 Thread ASF subversion and git services (Jira)


[ 
https://issues.apache.org/jira/browse/QPID-8361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942940#comment-16942940
 ] 

ASF subversion and git services commented on QPID-8361:
---

Commit a5453d5b05a0c4fdb12da36410917145e518ef30 in qpid-broker-j's branch 
refs/heads/master from Alex Rudyy
[ https://gitbox.apache.org/repos/asf?p=qpid-broker-j.git;h=a5453d5 ]

QPID-8361: [Broker-J] Update TOC


> [Broker-J] Create a developer guide for Qpid Broker-J
> -
>
> Key: QPID-8361
> URL: https://issues.apache.org/jira/browse/QPID-8361
> Project: Qpid
>  Issue Type: Task
>  Components: Broker-J
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0
>
>
> The developer documentation is currently scattered over various Qpid 
> confluence pages. It could be challenging for people interested in 
> contributing to the project to find that documentation. A developer guide 
> could be added to cover such aspects as
> * Environment Setup
> * Building project
> * Running tests
> * Releasing
> * Architecture overview
> The following wiki pages are good candidates for inclusion into a developer 
> guide:
> [High Level 
> Architecture|https://cwiki.apache.org/confluence/display/qpid/High+Level+Architecture]
> [How To Build Qpid 
> Broker-J|https://cwiki.apache.org/confluence/display/qpid/How+To+Build+Qpid+Broker-J]
> [Releasing Qpid 
> Broker-J|https://cwiki.apache.org/confluence/display/qpid/Releasing+Qpid+Broker-J]
> The wiki pages below might be included as well
> [Java Coding 
> Standards|https://cwiki.apache.org/confluence/display/qpid/Java+Coding+Standards]
> [Qpid Java Run 
> Scripts|https://cwiki.apache.org/confluence/display/qpid/Qpid+Java+Run+Scripts]
> The developer documentation should be easy to modify, maintain and preview. 
> Thus, it can be written in  markdown or 
> [asciidoc|https://asciidoctor.org/docs/asciidoc-syntax-quick-reference/]. The 
> latter is also supported on github. 
> Potentially, it can be published on Qpid  project site as part of release 
> process.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Commented] (QPID-8361) [Broker-J] Create a developer guide for Qpid Broker-J

2019-10-02 Thread ASF subversion and git services (Jira)


[ 
https://issues.apache.org/jira/browse/QPID-8361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942938#comment-16942938
 ] 

ASF subversion and git services commented on QPID-8361:
---

Commit fb0d8b9b7981a890d31e037e9f3157b11ef44c2f in qpid-broker-j's branch 
refs/heads/master from Alex Rudyy
[ https://gitbox.apache.org/repos/asf?p=qpid-broker-j.git;h=fb0d8b9 ]

QPID-8361: [Broker-J] Add description for ACL model


> [Broker-J] Create a developer guide for Qpid Broker-J
> -
>
> Key: QPID-8361
> URL: https://issues.apache.org/jira/browse/QPID-8361
> Project: Qpid
>  Issue Type: Task
>  Components: Broker-J
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0
>
>
> The developer documentation is currently scattered over various Qpid 
> confluence pages. It could be challenging for people interested in 
> contributing to the project to find that documentation. A developer guide 
> could be added to cover such aspects as
> * Environment Setup
> * Building project
> * Running tests
> * Releasing
> * Architecture overview
> The following wiki pages are good candidates for inclusion into a developer 
> guide:
> [High Level 
> Architecture|https://cwiki.apache.org/confluence/display/qpid/High+Level+Architecture]
> [How To Build Qpid 
> Broker-J|https://cwiki.apache.org/confluence/display/qpid/How+To+Build+Qpid+Broker-J]
> [Releasing Qpid 
> Broker-J|https://cwiki.apache.org/confluence/display/qpid/Releasing+Qpid+Broker-J]
> The wiki pages below might be included as well
> [Java Coding 
> Standards|https://cwiki.apache.org/confluence/display/qpid/Java+Coding+Standards]
> [Qpid Java Run 
> Scripts|https://cwiki.apache.org/confluence/display/qpid/Qpid+Java+Run+Scripts]
> The developer documentation should be easy to modify, maintain and preview. 
> Thus, it can be written in  markdown or 
> [asciidoc|https://asciidoctor.org/docs/asciidoc-syntax-quick-reference/]. The 
> latter is also supported on github. 
> Potentially, it can be published on Qpid  project site as part of release 
> process.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Comment Edited] (PROTON-2105) Support Go modules

2019-10-02 Thread Alan Conway (Jira)


[ 
https://issues.apache.org/jira/browse/PROTON-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942919#comment-16942919
 ] 

Alan Conway edited comment on PROTON-2105 at 10/2/19 4:05 PM:
--

Yep, I started looking at that before I was dragged off elsewhere. There's a 
history of my blunders here:
 # The directory layout is wrong: `go/src/qpid.apache.org/` is laid out 
like a workspace, not a project. Classic newbie mistake by me long ago and 
never corrected.
 # The qpid.apache.org/... illusion is created by a "magic" go1 branch, and 
some redirecting metadata tags on the qpid.apache.org website. The release 
process to update the go1 branch is explained here: 
[https://github.com/apache/qpid-proton/blob/master/go/src/qpid.apache.org/readme-go-get.md|https://github.com/apache/qpid-proton/blob/master/go/src/qpid.apache.org/readme-go-get.md#L1]

The magic go1 branch and HTTP redirect is nowadays deprecated in favour of 
modules, we should get rid of it.

First re-organize the directory tree to be `proton/go/pkg/...` - as we're 
changing package name we should take the chance to clean up.

Now  go/go.mod is simply:
{code}
module github.com/apache/qpid-proton/go
go 1.12
{code}
(I wouldn't jump straight to 1.13, lots of distros are still on 1.12 including 
Fedora 30)

The import names will be "github.com/apache/qpid-proton/go/pkg/electron" etc.

I would do all of the above in a single release cycle and leave the 
qpid.apache.org redirect stuck at the last release. That way existing users 
won't be broken, new users use the new names.

It is possible we could make the qpid.apache.org/... names continue to work, 
but I think it's better to make a clean break. The redirect-via-website is 
bewildering compared to the straightforward "package-name-equals-git-repo" 
convention which allows developers to easily find the source code, godocs etc.


was (Author: aconway):
Yep, I started looking at that before I was dragged off elsewhere. There's a 
history of my blunders here:
 # The directory layout is wrong: `proton/go/src/qpid.apache.org/` is laid 
out like a workspace, not a project. Classic newbie mistake by me long ago and 
never corrected.
 # The qpid.apache.org/... illusion is created by a "magic" go1 branch, and 
some redirecting metadata tags on the qpid.apache.org website. The release 
process to update the go1 branch is explained here: 
[https://github.com/apache/qpid-proton/blob/master/go/src/qpid.apache.org/readme-go-get.md|https://github.com/apache/qpid-proton/blob/master/go/src/qpid.apache.org/readme-go-get.md#L1]

The magic go1 branch and HTTP redirect is nowadays deprecated in favour of 
modules, we should get rid of it. We have to change the package names, so we 
want to get it right the first time :) 

First re-organize the directory tree to be `proton/go/pkg/...` - as we're 
changing package name we should take the chance to clean up.

Now  go/go.mod is simply:
{code}
module github.com/apache/qpid-proton/go
go 1.12
{code}
(I wouldn't jump straight to 1.13, lots of distros are still on 1.12 including 
Fedora 30)

The import names will be "github.com/apache/qpid-proton/go/pkg/electron" etc.

I would do all of the above in a single release cycle and leave the 
qpid.apache.org redirect stuck at the current release. That way existing users 
won't be broken, new users use the new names.

It is possible we could make the qpid.apache.org/... names continue to work, 
but I think it's better to make a clean break. The redirect-via-website is 
bewildering compared to the straightforward "package-name-equals-git-repo" 
convention which allows developers to easily find the source code, godocs etc.

> Support Go modules
> --
>
> Key: PROTON-2105
> URL: https://issues.apache.org/jira/browse/PROTON-2105
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: go-binding
>Reporter: Ulf Lilleengen
>Assignee: Roddie Kieley
>Priority: Major
>
> As of Go 1.12, go module support is available. In order to manage 
> dependencies using go modules, dependencies must also be using go modules. 
> Therefore, adding a go.mod file to each module would allow qpid proton go 
> bindings to be managed as a go module.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Comment Edited] (PROTON-2105) Support Go modules

2019-10-02 Thread Alan Conway (Jira)


[ 
https://issues.apache.org/jira/browse/PROTON-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942919#comment-16942919
 ] 

Alan Conway edited comment on PROTON-2105 at 10/2/19 4:04 PM:
--

Yep, I started looking at that before I was dragged off elsewhere. There's a 
history of my blunders here:
 # The directory layout is wrong: `proton/go/src/qpid.apache.org/` is laid 
out like a workspace, not a project. Classic newbie mistake by me long ago and 
never corrected.
 # The qpid.apache.org/... illusion is created by a "magic" go1 branch, and 
some redirecting metadata tags on the qpid.apache.org website. The release 
process to update the go1 branch is explained here: 
[https://github.com/apache/qpid-proton/blob/master/go/src/qpid.apache.org/readme-go-get.md|https://github.com/apache/qpid-proton/blob/master/go/src/qpid.apache.org/readme-go-get.md#L1]

The magic go1 branch and HTTP redirect is nowadays deprecated in favour of 
modules, we should get rid of it. We have to change the package names, so we 
want to get it right the first time :) 

First re-organize the directory tree to be `proton/go/pkg/...` - as we're 
changing package name we should take the chance to clean up.

Now  go/go.mod is simply:
{code}
module github.com/apache/qpid-proton/go
go 1.12
{code}
(I wouldn't jump straight to 1.13, lots of distros are still on 1.12 including 
Fedora 30)

The import names will be "github.com/apache/qpid-proton/go/pkg/electron" etc.

I would do all of the above in a single release cycle and leave the 
qpid.apache.org redirect stuck at the current release. That way existing users 
won't be broken, new users use the new names.

It is possible we could make the qpid.apache.org/... names continue to work, 
but I think it's better to make a clean break. The redirect-via-website is 
bewildering compared to the straightforward "package-name-equals-git-repo" 
convention which allows developers to easily find the source code, godocs etc.


was (Author: aconway):
Yep, I started looking at that before I was dragged off elsewhere. There's a 
history of my blunders here:
 # The directory layout is wrong: `proton/go/src/qpid.apache.org/` is laid 
out like a workspace, not a project. Classic newbie mistake by me long ago and 
never corrected.
 # The qpid.apache.org/... illusion is created by a "magic" go1 branch, and 
some redirecting metadata tags on the qpid.apache.org website. The release 
process to update the go1 branch is explained here: 
[https://github.com/apache/qpid-proton/blob/master/go/src/qpid.apache.org/readme-go-get.md|https://github.com/apache/qpid-proton/blob/master/go/src/qpid.apache.org/readme-go-get.md#L1]

The magic go1 branch and HTTP redirect is nowadays deprecated in favour of 
modules, we should get rid of it. We have to change the package names, so we 
want to get it right the first time :) 

Steps:
 # Re-organize the directory tree to be `proton/go/pkg/...` otherwise we'll 
have horrid long package names.
 # Pick a hostname: github.com or gitbox.apache.org. It's a political decision 
- github is more visible, but someone should check if apache policy requires 
the word "apache" in the "official" package names. I'm staying out of it.
 # Once the decision is made it's easy - assuming we choose github and 
re-organize the directories as above it would be:

{code:java}
module github.com/qpid-proton/go/ 
go 1.12
{code}
(I wouldn't jump straight to 1.13, lots of distros are still on 1.12 including 
Fedora 30)

I would do all of the above in a single release cycle and leave the 
qpid.apache.org redirect stuck at the current release. That way existing users 
won't be broken, new users use the new names.

It is possible we could make the qpid.apache.org/... names continue to work, 
but I think it's better to make a clean break. The redirect-via-website is 
bewildering compared to the straightforward "package-name-equals-git-repo" 
convention which allows developers to easily find the source code, godocs etc.

> Support Go modules
> --
>
> Key: PROTON-2105
> URL: https://issues.apache.org/jira/browse/PROTON-2105
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: go-binding
>Reporter: Ulf Lilleengen
>Assignee: Roddie Kieley
>Priority: Major
>
> As of Go 1.12, go module support is available. In order to manage 
> dependencies using go modules, dependencies must also be using go modules. 
> Therefore, adding a go.mod file to each module would allow qpid proton go 
> bindings to be managed as a go module.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Commented] (DISPATCH-1436) Don't allow both password and passwordFile to be specified in sslProfile

2019-10-02 Thread Ganesh Murthy (Jira)


[ 
https://issues.apache.org/jira/browse/DISPATCH-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942936#comment-16942936
 ] 

Ganesh Murthy commented on DISPATCH-1436:
-

This applies for saslPassword and saslPasswordFile as well.

> Don't allow both password and passwordFile to be specified in sslProfile  
> --
>
> Key: DISPATCH-1436
> URL: https://issues.apache.org/jira/browse/DISPATCH-1436
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Container, Management Agent
>Affects Versions: 1.9.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
>
> Currently, the password field takes precedence over passwordFile when both 
> are specified in the sslProfile entity.
> The router should not start if both are specified.
> qdmanage commands specifying both must result in Bad Request.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Created] (DISPATCH-1436) Don't allow both password and passwordFile to be specified in sslProfile

2019-10-02 Thread Ganesh Murthy (Jira)
Ganesh Murthy created DISPATCH-1436:
---

 Summary: Don't allow both password and passwordFile to be 
specified in sslProfile  
 Key: DISPATCH-1436
 URL: https://issues.apache.org/jira/browse/DISPATCH-1436
 Project: Qpid Dispatch
  Issue Type: Improvement
  Components: Container, Management Agent
Affects Versions: 1.9.0
Reporter: Ganesh Murthy
Assignee: Ganesh Murthy


Currently, the password field takes precedence over passwordFile when both are 
specified in the sslProfile entity.

The router should not start if both are specified.

qdmanage commands specifying both must result in Bad Request.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Commented] (PROTON-2105) Support Go modules

2019-10-02 Thread Alan Conway (Jira)


[ 
https://issues.apache.org/jira/browse/PROTON-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942919#comment-16942919
 ] 

Alan Conway commented on PROTON-2105:
-

Yep, I started looking at that before I was dragged off elsewhere. There's a 
history of my blunders here:
 # The directory layout is wrong: `proton/go/src/qpid.apache.org/` is laid 
out like a workspace, not a project. Classic newbie mistake by me long ago and 
never corrected.
 # The qpid.apache.org/... illusion is created by a "magic" go1 branch, and 
some redirecting metadata tags on the qpid.apache.org website. The release 
process to update the go1 branch is explained here: 
[https://github.com/apache/qpid-proton/blob/master/go/src/qpid.apache.org/readme-go-get.md|https://github.com/apache/qpid-proton/blob/master/go/src/qpid.apache.org/readme-go-get.md#L1]

The magic go1 branch and HTTP redirect is nowadays deprecated in favour of 
modules, we should get rid of it. We have to change the package names, so we 
want to get it right the first time :) 

Steps:
 # Re-organize the directory tree to be `proton/go/pkg/...` otherwise we'll 
have horrid long package names.
 # Pick a hostname: github.com or gitbox.apache.org. It's a political decision 
- github is more visible, but someone should check if apache policy requires 
the word "apache" in the "official" package names. I'm staying out of it.
 # Once the decision is made it's easy - assuming we choose github and 
re-organize the directories as above it would be:

{code:java}
module github.com/qpid-proton/go/ 
go 1.12
{code}
(I wouldn't jump straight to 1.13, lots of distros are still on 1.12 including 
Fedora 30)

I would do all of the above in a single release cycle and leave the 
qpid.apache.org redirect stuck at the current release. That way existing users 
won't be broken, new users use the new names.

It is possible we could make the qpid.apache.org/... names continue to work, 
but I think it's better to make a clean break. The redirect-via-website is 
bewildering compared to the straightforward "package-name-equals-git-repo" 
convention which allows developers to easily find the source code, godocs etc.

> Support Go modules
> --
>
> Key: PROTON-2105
> URL: https://issues.apache.org/jira/browse/PROTON-2105
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: go-binding
>Reporter: Ulf Lilleengen
>Assignee: Roddie Kieley
>Priority: Major
>
> As of Go 1.12, go module support is available. In order to manage 
> dependencies using go modules, dependencies must also be using go modules. 
> Therefore, adding a go.mod file to each module would allow qpid proton go 
> bindings to be managed as a go module.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Created] (DISPATCH-1435) Special handling of SSL password text is not documented nor consistent with SASL

2019-10-02 Thread Ken Giusti (Jira)
Ken Giusti created DISPATCH-1435:


 Summary: Special handling of SSL password text is not documented 
nor consistent with SASL
 Key: DISPATCH-1435
 URL: https://issues.apache.org/jira/browse/DISPATCH-1435
 Project: Qpid Dispatch
  Issue Type: Bug
  Components: Documentation, Management Agent
Affects Versions: 1.9.0
Reporter: Ken Giusti


The router currently checks the SSL password for the prefixes "env:" or 
"literal:" - see 
[qd_config_ssl_profile_process_password()|https://github.com/apache/qpid-dispatch/blob/master/src/connection_manager.c#L213]

Two issues with this:

1) It is not documented.  It needs to be documented in the qdrouter.json file 
as well as in the configuration section of the user guide
2) the SASL password does not provide the same feature - should it be added 
there as well?




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Commented] (DISPATCH-1434) Add new attribute saslPasswordFile to the connector entity

2019-10-02 Thread ASF GitHub Bot (Jira)


[ 
https://issues.apache.org/jira/browse/DISPATCH-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942883#comment-16942883
 ] 

ASF GitHub Bot commented on DISPATCH-1434:
--

codecov-io commented on issue #578: DISPATCH-1434 - Added new attribute 
saslPasswordFile to the connector…
URL: https://github.com/apache/qpid-dispatch/pull/578#issuecomment-537273937
 
 
   # 
[Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=h1) 
Report
   > Merging 
[#578](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=desc) into 
[master](https://codecov.io/gh/apache/qpid-dispatch/commit/b08babc21637ef99af60da893837c5b40c8c0ceb?src=pr=desc)
 will **increase** coverage by `<.01%`.
   > The diff coverage is `100%`.
   
   [![Impacted file tree 
graph](https://codecov.io/gh/apache/qpid-dispatch/pull/578/graphs/tree.svg?width=650=rk2Cgd27pP=150=pr)](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=tree)
   
   ```diff
   @@Coverage Diff @@
   ##   master #578  +/-   ##
   ==
   + Coverage   86.29%   86.29%   +<.01% 
   ==
 Files  90   90  
 Lines   2038620394   +8 
   ==
   + Hits1759217600   +8 
 Misses   2794 2794
   ```
   
   
   | [Impacted 
Files](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=tree) | 
Coverage Δ | |
   |---|---|---|
   | 
[src/connection\_manager.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL2Nvbm5lY3Rpb25fbWFuYWdlci5j)
 | `89.71% <100%> (+0.14%)` | :arrow_up: |
   | 
[src/iterator.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL2l0ZXJhdG9yLmM=)
 | `89.17% <0%> (-0.36%)` | :arrow_down: |
   | 
[src/parse.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL3BhcnNlLmM=)
 | `87.64% <0%> (-0.23%)` | :arrow_down: |
   | 
[src/router\_core/connections.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL2Nvbm5lY3Rpb25zLmM=)
 | `93.97% <0%> (-0.12%)` | :arrow_down: |
   | 
[src/router\_node.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9ub2RlLmM=)
 | `93.1% <0%> (+0.24%)` | :arrow_up: |
   | 
[src/router\_core/transfer.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL3RyYW5zZmVyLmM=)
 | `94.45% <0%> (+0.25%)` | :arrow_up: |
   | 
[src/router\_core/agent\_link.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL2FnZW50X2xpbmsuYw==)
 | `67.33% <0%> (+0.5%)` | :arrow_up: |
   
   --
   
   [Continue to review full report at 
Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=continue).
   > **Legend** - [Click here to learn 
more](https://docs.codecov.io/docs/codecov-delta)
   > `Δ = absolute  (impact)`, `ø = not affected`, `? = missing data`
   > Powered by 
[Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=footer).
 Last update 
[b08babc...b72060c](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=lastupdated).
 Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).
   
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Add new attribute saslPasswordFile to the connector entity
> --
>
> Key: DISPATCH-1434
> URL: https://issues.apache.org/jira/browse/DISPATCH-1434
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Container
>Affects Versions: 1.9.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
>
> Add a new attribute called saslPasswordFile to the connector entity. This 
> will enable users to specify the saslPassword in a file instead of specifying 
> it in the config file.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[GitHub] [qpid-dispatch] codecov-io edited a comment on issue #578: DISPATCH-1434 - Added new attribute saslPasswordFile to the connector…

2019-10-02 Thread GitBox
codecov-io edited a comment on issue #578: DISPATCH-1434 - Added new attribute 
saslPasswordFile to the connector…
URL: https://github.com/apache/qpid-dispatch/pull/578#issuecomment-537273937
 
 
   # 
[Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=h1) 
Report
   > Merging 
[#578](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=desc) into 
[master](https://codecov.io/gh/apache/qpid-dispatch/commit/b08babc21637ef99af60da893837c5b40c8c0ceb?src=pr=desc)
 will **increase** coverage by `<.01%`.
   > The diff coverage is `100%`.
   
   [![Impacted file tree 
graph](https://codecov.io/gh/apache/qpid-dispatch/pull/578/graphs/tree.svg?width=650=rk2Cgd27pP=150=pr)](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=tree)
   
   ```diff
   @@Coverage Diff @@
   ##   master #578  +/-   ##
   ==
   + Coverage   86.29%   86.29%   +<.01% 
   ==
 Files  90   90  
 Lines   2038620394   +8 
   ==
   + Hits1759217600   +8 
 Misses   2794 2794
   ```
   
   
   | [Impacted 
Files](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=tree) | 
Coverage Δ | |
   |---|---|---|
   | 
[src/connection\_manager.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL2Nvbm5lY3Rpb25fbWFuYWdlci5j)
 | `89.71% <100%> (+0.14%)` | :arrow_up: |
   | 
[src/iterator.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL2l0ZXJhdG9yLmM=)
 | `89.17% <0%> (-0.36%)` | :arrow_down: |
   | 
[src/parse.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL3BhcnNlLmM=)
 | `87.64% <0%> (-0.23%)` | :arrow_down: |
   | 
[src/router\_core/connections.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL2Nvbm5lY3Rpb25zLmM=)
 | `93.97% <0%> (-0.12%)` | :arrow_down: |
   | 
[src/router\_node.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9ub2RlLmM=)
 | `93.1% <0%> (+0.24%)` | :arrow_up: |
   | 
[src/router\_core/transfer.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL3RyYW5zZmVyLmM=)
 | `94.45% <0%> (+0.25%)` | :arrow_up: |
   | 
[src/router\_core/agent\_link.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL2FnZW50X2xpbmsuYw==)
 | `67.33% <0%> (+0.5%)` | :arrow_up: |
   
   --
   
   [Continue to review full report at 
Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=continue).
   > **Legend** - [Click here to learn 
more](https://docs.codecov.io/docs/codecov-delta)
   > `Δ = absolute  (impact)`, `ø = not affected`, `? = missing data`
   > Powered by 
[Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=footer).
 Last update 
[b08babc...b72060c](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=lastupdated).
 Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Commented] (DISPATCH-1434) Add new attribute saslPasswordFile to the connector entity

2019-10-02 Thread ASF GitHub Bot (Jira)


[ 
https://issues.apache.org/jira/browse/DISPATCH-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942873#comment-16942873
 ] 

ASF GitHub Bot commented on DISPATCH-1434:
--

codecov-io commented on issue #578: DISPATCH-1434 - Added new attribute 
saslPasswordFile to the connector…
URL: https://github.com/apache/qpid-dispatch/pull/578#issuecomment-537273937
 
 
   # 
[Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=h1) 
Report
   > Merging 
[#578](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=desc) into 
[master](https://codecov.io/gh/apache/qpid-dispatch/commit/b08babc21637ef99af60da893837c5b40c8c0ceb?src=pr=desc)
 will **decrease** coverage by `0.01%`.
   > The diff coverage is `100%`.
   
   [![Impacted file tree 
graph](https://codecov.io/gh/apache/qpid-dispatch/pull/578/graphs/tree.svg?width=650=rk2Cgd27pP=150=pr)](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=tree)
   
   ```diff
   @@Coverage Diff @@
   ##   master #578  +/-   ##
   ==
   - Coverage   86.29%   86.28%   -0.02% 
   ==
 Files  90   90  
 Lines   2038620393   +7 
   ==
   + Hits1759217596   +4 
   - Misses   2794 2797   +3
   ```
   
   
   | [Impacted 
Files](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=tree) | 
Coverage Δ | |
   |---|---|---|
   | 
[src/connection\_manager.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL2Nvbm5lY3Rpb25fbWFuYWdlci5j)
 | `89.71% <100%> (+0.14%)` | :arrow_up: |
   | 
[src/router\_core/transfer.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL3RyYW5zZmVyLmM=)
 | `93.7% <0%> (-0.51%)` | :arrow_down: |
   | 
[src/parse.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL3BhcnNlLmM=)
 | `87.64% <0%> (-0.23%)` | :arrow_down: |
   | 
[src/iterator.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL2l0ZXJhdG9yLmM=)
 | `89.34% <0%> (-0.19%)` | :arrow_down: |
   | 
[src/container.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL2NvbnRhaW5lci5j)
 | `81.19% <0%> (-0.19%)` | :arrow_down: |
   | 
[src/router\_node.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9ub2RlLmM=)
 | `92.98% <0%> (+0.12%)` | :arrow_up: |
   | 
[src/router\_core/agent\_link.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL2FnZW50X2xpbmsuYw==)
 | `67.33% <0%> (+0.5%)` | :arrow_up: |
   
   --
   
   [Continue to review full report at 
Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=continue).
   > **Legend** - [Click here to learn 
more](https://docs.codecov.io/docs/codecov-delta)
   > `Δ = absolute  (impact)`, `ø = not affected`, `? = missing data`
   > Powered by 
[Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=footer).
 Last update 
[b08babc...b72060c](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=lastupdated).
 Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).
   
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Add new attribute saslPasswordFile to the connector entity
> --
>
> Key: DISPATCH-1434
> URL: https://issues.apache.org/jira/browse/DISPATCH-1434
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Container
>Affects Versions: 1.9.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
>
> Add a new attribute called saslPasswordFile to the connector entity. This 
> will enable users to specify the saslPassword in a file instead of specifying 
> it in the config file.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[GitHub] [qpid-dispatch] codecov-io edited a comment on issue #578: DISPATCH-1434 - Added new attribute saslPasswordFile to the connector…

2019-10-02 Thread GitBox
codecov-io edited a comment on issue #578: DISPATCH-1434 - Added new attribute 
saslPasswordFile to the connector…
URL: https://github.com/apache/qpid-dispatch/pull/578#issuecomment-537273937
 
 
   # 
[Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=h1) 
Report
   > Merging 
[#578](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=desc) into 
[master](https://codecov.io/gh/apache/qpid-dispatch/commit/b08babc21637ef99af60da893837c5b40c8c0ceb?src=pr=desc)
 will **decrease** coverage by `0.01%`.
   > The diff coverage is `100%`.
   
   [![Impacted file tree 
graph](https://codecov.io/gh/apache/qpid-dispatch/pull/578/graphs/tree.svg?width=650=rk2Cgd27pP=150=pr)](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=tree)
   
   ```diff
   @@Coverage Diff @@
   ##   master #578  +/-   ##
   ==
   - Coverage   86.29%   86.28%   -0.02% 
   ==
 Files  90   90  
 Lines   2038620393   +7 
   ==
   + Hits1759217596   +4 
   - Misses   2794 2797   +3
   ```
   
   
   | [Impacted 
Files](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=tree) | 
Coverage Δ | |
   |---|---|---|
   | 
[src/connection\_manager.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL2Nvbm5lY3Rpb25fbWFuYWdlci5j)
 | `89.71% <100%> (+0.14%)` | :arrow_up: |
   | 
[src/router\_core/transfer.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL3RyYW5zZmVyLmM=)
 | `93.7% <0%> (-0.51%)` | :arrow_down: |
   | 
[src/parse.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL3BhcnNlLmM=)
 | `87.64% <0%> (-0.23%)` | :arrow_down: |
   | 
[src/iterator.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL2l0ZXJhdG9yLmM=)
 | `89.34% <0%> (-0.19%)` | :arrow_down: |
   | 
[src/container.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL2NvbnRhaW5lci5j)
 | `81.19% <0%> (-0.19%)` | :arrow_down: |
   | 
[src/router\_node.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9ub2RlLmM=)
 | `92.98% <0%> (+0.12%)` | :arrow_up: |
   | 
[src/router\_core/agent\_link.c](https://codecov.io/gh/apache/qpid-dispatch/pull/578/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL2FnZW50X2xpbmsuYw==)
 | `67.33% <0%> (+0.5%)` | :arrow_up: |
   
   --
   
   [Continue to review full report at 
Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=continue).
   > **Legend** - [Click here to learn 
more](https://docs.codecov.io/docs/codecov-delta)
   > `Δ = absolute  (impact)`, `ø = not affected`, `? = missing data`
   > Powered by 
[Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=footer).
 Last update 
[b08babc...b72060c](https://codecov.io/gh/apache/qpid-dispatch/pull/578?src=pr=lastupdated).
 Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Commented] (DISPATCH-1434) Add new attribute saslPasswordFile to the connector entity

2019-10-02 Thread ASF GitHub Bot (Jira)


[ 
https://issues.apache.org/jira/browse/DISPATCH-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942867#comment-16942867
 ] 

ASF GitHub Bot commented on DISPATCH-1434:
--

ganeshmurthy commented on pull request #578: DISPATCH-1434 - Added new 
attribute saslPasswordFile to the connector…
URL: https://github.com/apache/qpid-dispatch/pull/578#discussion_r330587020
 
 

 ##
 File path: python/qpid_dispatch/management/qdrouter.json
 ##
 @@ -1002,10 +1002,17 @@
 "saslPassword": {
 "type": "string",
 "required": false,
-"description": "The password that the connector is using 
to connect to a peer.",
+"description": "(DEPRECATED) The password that the 
connector is using to connect to a peer.",
 
 Review comment:
   Done
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Add new attribute saslPasswordFile to the connector entity
> --
>
> Key: DISPATCH-1434
> URL: https://issues.apache.org/jira/browse/DISPATCH-1434
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Container
>Affects Versions: 1.9.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
>
> Add a new attribute called saslPasswordFile to the connector entity. This 
> will enable users to specify the saslPassword in a file instead of specifying 
> it in the config file.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[GitHub] [qpid-dispatch] ganeshmurthy commented on a change in pull request #578: DISPATCH-1434 - Added new attribute saslPasswordFile to the connector…

2019-10-02 Thread GitBox
ganeshmurthy commented on a change in pull request #578: DISPATCH-1434 - Added 
new attribute saslPasswordFile to the connector…
URL: https://github.com/apache/qpid-dispatch/pull/578#discussion_r330587020
 
 

 ##
 File path: python/qpid_dispatch/management/qdrouter.json
 ##
 @@ -1002,10 +1002,17 @@
 "saslPassword": {
 "type": "string",
 "required": false,
-"description": "The password that the connector is using 
to connect to a peer.",
+"description": "(DEPRECATED) The password that the 
connector is using to connect to a peer.",
 
 Review comment:
   Done


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[GitHub] [qpid-proton] ncau opened a new pull request #194: ENTMQCL-1062:[CMake] Fixing an issue with cmake not compiling c++11 e…

2019-10-02 Thread GitBox
ncau opened a new pull request #194: ENTMQCL-1062:[CMake] Fixing an issue with 
cmake not compiling c++11 e…
URL: https://github.com/apache/qpid-proton/pull/194
 
 
   On versions prior to CMake 3.0 the C++11 examples are not being compiled as 
the CMake code does not correctly check for c++11 compatibility. 


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Commented] (DISPATCH-1434) Add new attribute saslPasswordFile to the connector entity

2019-10-02 Thread ASF GitHub Bot (Jira)


[ 
https://issues.apache.org/jira/browse/DISPATCH-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942859#comment-16942859
 ] 

ASF GitHub Bot commented on DISPATCH-1434:
--

ganeshmurthy commented on pull request #578: DISPATCH-1434 - Added new 
attribute saslPasswordFile to the connector…
URL: https://github.com/apache/qpid-dispatch/pull/578#discussion_r330580810
 
 

 ##
 File path: src/connection_manager.c
 ##
 @@ -327,6 +329,41 @@ static qd_error_t load_server_config(qd_dispatch_t *qd, 
qd_server_config_t *conf
 }
 config->sasl_username= qd_entity_opt_string(entity, 
"saslUsername", 0);   CHECK();
 config->sasl_password= qd_entity_opt_string(entity, 
"saslPassword", 0);   CHECK();
+
+if (config->sasl_password) {
+qd_log(cm->log_source, QD_LOG_WARNING, "Attribute saslPassword of 
entity connector has been deprecated. Use saslPasswordFile instead.");
+}
+else {
+// saslPassword not provided. Check if saslPasswordFile property is 
specified.
+char *password_file = qd_entity_opt_string(entity, "saslPasswordFile", 
0); CHECK();
+
+if (password_file) {
+FILE *file = fopen(password_file, "r");
+
+if (file) {
+char buffer[200];
+
+int c;
+int i=0;
+
+while (i < 200 - 1) {
+c = fgetc(file);
+if (c == EOF || c == '\n')
+break;
+buffer[i++] = c;
+}
+
+if (i != 0) {
+buffer[i] = '\0';
+free(config->sasl_password);
+config->sasl_password = strdup(buffer);
+}
+fclose(file);
+}
+}
+free(password_file);
+}
+
 
 Review comment:
   Done
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Add new attribute saslPasswordFile to the connector entity
> --
>
> Key: DISPATCH-1434
> URL: https://issues.apache.org/jira/browse/DISPATCH-1434
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Container
>Affects Versions: 1.9.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
>
> Add a new attribute called saslPasswordFile to the connector entity. This 
> will enable users to specify the saslPassword in a file instead of specifying 
> it in the config file.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[GitHub] [qpid-dispatch] ganeshmurthy commented on a change in pull request #578: DISPATCH-1434 - Added new attribute saslPasswordFile to the connector…

2019-10-02 Thread GitBox
ganeshmurthy commented on a change in pull request #578: DISPATCH-1434 - Added 
new attribute saslPasswordFile to the connector…
URL: https://github.com/apache/qpid-dispatch/pull/578#discussion_r330580810
 
 

 ##
 File path: src/connection_manager.c
 ##
 @@ -327,6 +329,41 @@ static qd_error_t load_server_config(qd_dispatch_t *qd, 
qd_server_config_t *conf
 }
 config->sasl_username= qd_entity_opt_string(entity, 
"saslUsername", 0);   CHECK();
 config->sasl_password= qd_entity_opt_string(entity, 
"saslPassword", 0);   CHECK();
+
+if (config->sasl_password) {
+qd_log(cm->log_source, QD_LOG_WARNING, "Attribute saslPassword of 
entity connector has been deprecated. Use saslPasswordFile instead.");
+}
+else {
+// saslPassword not provided. Check if saslPasswordFile property is 
specified.
+char *password_file = qd_entity_opt_string(entity, "saslPasswordFile", 
0); CHECK();
+
+if (password_file) {
+FILE *file = fopen(password_file, "r");
+
+if (file) {
+char buffer[200];
+
+int c;
+int i=0;
+
+while (i < 200 - 1) {
+c = fgetc(file);
+if (c == EOF || c == '\n')
+break;
+buffer[i++] = c;
+}
+
+if (i != 0) {
+buffer[i] = '\0';
+free(config->sasl_password);
+config->sasl_password = strdup(buffer);
+}
+fclose(file);
+}
+}
+free(password_file);
+}
+
 
 Review comment:
   Done


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Commented] (DISPATCH-1434) Add new attribute saslPasswordFile to the connector entity

2019-10-02 Thread ASF GitHub Bot (Jira)


[ 
https://issues.apache.org/jira/browse/DISPATCH-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942854#comment-16942854
 ] 

ASF GitHub Bot commented on DISPATCH-1434:
--

kgiusti commented on pull request #578: DISPATCH-1434 - Added new attribute 
saslPasswordFile to the connector…
URL: https://github.com/apache/qpid-dispatch/pull/578#discussion_r330577701
 
 

 ##
 File path: python/qpid_dispatch/management/qdrouter.json
 ##
 @@ -1002,10 +1002,17 @@
 "saslPassword": {
 "type": "string",
 "required": false,
-"description": "The password that the connector is using 
to connect to a peer.",
+"description": "(DEPRECATED) The password that the 
connector is using to connect to a peer.",
 
 Review comment:
   Compare this to the text description for SSL's password.  SSL Password's 
description contains a bit more detail - can you update saslPassword's 
description to be consistent?
   
   > This attribute has been deprecated because it is unsafe to store plain 
text passwords in config files. Use the passwordFile instead
   
   
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Add new attribute saslPasswordFile to the connector entity
> --
>
> Key: DISPATCH-1434
> URL: https://issues.apache.org/jira/browse/DISPATCH-1434
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Container
>Affects Versions: 1.9.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
>
> Add a new attribute called saslPasswordFile to the connector entity. This 
> will enable users to specify the saslPassword in a file instead of specifying 
> it in the config file.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[GitHub] [qpid-dispatch] kgiusti commented on a change in pull request #578: DISPATCH-1434 - Added new attribute saslPasswordFile to the connector…

2019-10-02 Thread GitBox
kgiusti commented on a change in pull request #578: DISPATCH-1434 - Added new 
attribute saslPasswordFile to the connector…
URL: https://github.com/apache/qpid-dispatch/pull/578#discussion_r330577701
 
 

 ##
 File path: python/qpid_dispatch/management/qdrouter.json
 ##
 @@ -1002,10 +1002,17 @@
 "saslPassword": {
 "type": "string",
 "required": false,
-"description": "The password that the connector is using 
to connect to a peer.",
+"description": "(DEPRECATED) The password that the 
connector is using to connect to a peer.",
 
 Review comment:
   Compare this to the text description for SSL's password.  SSL Password's 
description contains a bit more detail - can you update saslPassword's 
description to be consistent?
   
   > This attribute has been deprecated because it is unsafe to store plain 
text passwords in config files. Use the passwordFile instead
   
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Commented] (DISPATCH-1434) Add new attribute saslPasswordFile to the connector entity

2019-10-02 Thread ASF GitHub Bot (Jira)


[ 
https://issues.apache.org/jira/browse/DISPATCH-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942813#comment-16942813
 ] 

ASF GitHub Bot commented on DISPATCH-1434:
--

kgiusti commented on pull request #578: DISPATCH-1434 - Added new attribute 
saslPasswordFile to the connector…
URL: https://github.com/apache/qpid-dispatch/pull/578#discussion_r330550035
 
 

 ##
 File path: src/connection_manager.c
 ##
 @@ -327,6 +329,41 @@ static qd_error_t load_server_config(qd_dispatch_t *qd, 
qd_server_config_t *conf
 }
 config->sasl_username= qd_entity_opt_string(entity, 
"saslUsername", 0);   CHECK();
 config->sasl_password= qd_entity_opt_string(entity, 
"saslPassword", 0);   CHECK();
+
+if (config->sasl_password) {
+qd_log(cm->log_source, QD_LOG_WARNING, "Attribute saslPassword of 
entity connector has been deprecated. Use saslPasswordFile instead.");
+}
+else {
+// saslPassword not provided. Check if saslPasswordFile property is 
specified.
+char *password_file = qd_entity_opt_string(entity, "saslPasswordFile", 
0); CHECK();
+
+if (password_file) {
+FILE *file = fopen(password_file, "r");
+
+if (file) {
+char buffer[200];
+
+int c;
+int i=0;
+
+while (i < 200 - 1) {
+c = fgetc(file);
+if (c == EOF || c == '\n')
+break;
+buffer[i++] = c;
+}
+
+if (i != 0) {
+buffer[i] = '\0';
+free(config->sasl_password);
+config->sasl_password = strdup(buffer);
+}
+fclose(file);
+}
+}
+free(password_file);
+}
+
 
 Review comment:
   This chunk of code appears to be a cut'n'paste of the ssl password file 
parsing.
   Would it be possible to eliminate the redundancy an instead create a local 
(static) function that does this then have both the sasl and ssl codepaths call 
it?
   
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Add new attribute saslPasswordFile to the connector entity
> --
>
> Key: DISPATCH-1434
> URL: https://issues.apache.org/jira/browse/DISPATCH-1434
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Container
>Affects Versions: 1.9.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
>
> Add a new attribute called saslPasswordFile to the connector entity. This 
> will enable users to specify the saslPassword in a file instead of specifying 
> it in the config file.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[GitHub] [qpid-dispatch] kgiusti commented on a change in pull request #578: DISPATCH-1434 - Added new attribute saslPasswordFile to the connector…

2019-10-02 Thread GitBox
kgiusti commented on a change in pull request #578: DISPATCH-1434 - Added new 
attribute saslPasswordFile to the connector…
URL: https://github.com/apache/qpid-dispatch/pull/578#discussion_r330550035
 
 

 ##
 File path: src/connection_manager.c
 ##
 @@ -327,6 +329,41 @@ static qd_error_t load_server_config(qd_dispatch_t *qd, 
qd_server_config_t *conf
 }
 config->sasl_username= qd_entity_opt_string(entity, 
"saslUsername", 0);   CHECK();
 config->sasl_password= qd_entity_opt_string(entity, 
"saslPassword", 0);   CHECK();
+
+if (config->sasl_password) {
+qd_log(cm->log_source, QD_LOG_WARNING, "Attribute saslPassword of 
entity connector has been deprecated. Use saslPasswordFile instead.");
+}
+else {
+// saslPassword not provided. Check if saslPasswordFile property is 
specified.
+char *password_file = qd_entity_opt_string(entity, "saslPasswordFile", 
0); CHECK();
+
+if (password_file) {
+FILE *file = fopen(password_file, "r");
+
+if (file) {
+char buffer[200];
+
+int c;
+int i=0;
+
+while (i < 200 - 1) {
+c = fgetc(file);
+if (c == EOF || c == '\n')
+break;
+buffer[i++] = c;
+}
+
+if (i != 0) {
+buffer[i] = '\0';
+free(config->sasl_password);
+config->sasl_password = strdup(buffer);
+}
+fclose(file);
+}
+}
+free(password_file);
+}
+
 
 Review comment:
   This chunk of code appears to be a cut'n'paste of the ssl password file 
parsing.
   Would it be possible to eliminate the redundancy an instead create a local 
(static) function that does this then have both the sasl and ssl codepaths call 
it?
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Commented] (PROTON-2105) Support Go modules

2019-10-02 Thread Ulf Lilleengen (Jira)


[ 
https://issues.apache.org/jira/browse/PROTON-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942683#comment-16942683
 ] 

Ulf Lilleengen commented on PROTON-2105:


[~rkieley] thanks for looking at this. I'm thinking the problem with using 
github.com in the module URL is that this has not been the authorative module 
name in the past, so changing that I'm not sure is something we should do (i'm 
a bit confused after reading go/src/qpid.apache.org/readme-go-get.md).

 

After your first comment, I thought how it should be is that the following file 
should go into the go/src/qpid.apache.org folder:
{code:java}
module qpid.apache.org

go 1.13{code}
 

However, I don't see a way to properly test this without actually publishing 
the go module, because with go modules you're not supposed to use $GOPATH to 
look up dependencies, but I'm not sure how one can test it locally then. Maybe 
[~aconway] can shed some light on how the go artifacts are published?

> Support Go modules
> --
>
> Key: PROTON-2105
> URL: https://issues.apache.org/jira/browse/PROTON-2105
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: go-binding
>Reporter: Ulf Lilleengen
>Assignee: Roddie Kieley
>Priority: Major
>
> As of Go 1.12, go module support is available. In order to manage 
> dependencies using go modules, dependencies must also be using go modules. 
> Therefore, adding a go.mod file to each module would allow qpid proton go 
> bindings to be managed as a go module.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Commented] (QPID-8366) [Broker-J] The loss of BDB HA majority on invocation of house keeping operations can crash the broker

2019-10-02 Thread ASF subversion and git services (Jira)


[ 
https://issues.apache.org/jira/browse/QPID-8366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942681#comment-16942681
 ] 

ASF subversion and git services commented on QPID-8366:
---

Commit c3d0590b7687c19958da8ef963531104f801b904 in qpid-broker-j's branch 
refs/heads/7.1.x from Alex Rudyy
[ https://gitbox.apache.org/repos/asf?p=qpid-broker-j.git;h=c3d0590 ]

QPID-8366: [Broker-J] Handle ConnectionScopeRuntimeException on execution of 
HouseKeepingTaks

(cherry picked from commit 98261ad92020c11784a3be2ab890cbabddec5fbc)


> [Broker-J] The loss of BDB HA majority on invocation of house keeping 
> operations can crash the broker
> -
>
> Key: QPID-8366
> URL: https://issues.apache.org/jira/browse/QPID-8366
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.0, qpid-java-broker-7.0.4, 
> qpid-java-broker-7.0.5, qpid-java-broker-7.0.6, qpid-java-broker-7.0.7, 
> qpid-java-broker-7.1.1, qpid-java-broker-7.1.2, qpid-java-broker-7.0.8, 
> qpid-java-broker-7.1.3, qpid-java-broker-7.1.4
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.0.9, 
> qpid-java-broker-7.1.5
>
>
> The {{ConnectionScopedRuntimeException}} thrown from {{VirtualHost}} {{House 
> Keeping}} thread on invocation of {{MessageStore}} operations like 
> {{checkMessageStatus}} can crash the broker. An example of such exception 
> stack trace  (from Qpid Broker version 7.0.6) is provided below:
> {noformat}
> 2019-09-27 07:53:38,168 ERROR [virtualhost-test-pool-1] (o.a.q.s.Main) - 
> Uncaught exception, shutting down.
> org.apache.qpid.server.util.ConnectionScopedRuntimeException: Required number 
> of nodes not reachable
> at 
> org.apache.qpid.server.store.berkeleydb.replication.ReplicatedEnvironmentFacade.handleDatabaseException(ReplicatedEnvironmentFacade.java:495)
> at 
> org.apache.qpid.server.store.berkeleydb.replication.ReplicatedEnvironmentFacade.commit(ReplicatedEnvironmentFacade.java:332)
> at 
> org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.removeMessage(AbstractBDBMessageStore.java:288)
> at 
> org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore$StoredBDBMessage.remove(AbstractBDBMessageStore.java:1090)
> at 
> org.apache.qpid.server.message.AbstractServerMessageImpl.decrementReference(AbstractServerMessageImpl.java:118)
> at 
> org.apache.qpid.server.message.AbstractServerMessageImpl.access$500(AbstractServerMessageImpl.java:37)
> at 
> org.apache.qpid.server.message.AbstractServerMessageImpl$Reference.release(AbstractServerMessageImpl.java:309)
> at 
> org.apache.qpid.server.queue.QueueEntryImpl.dispose(QueueEntryImpl.java:557)
> at 
> org.apache.qpid.server.queue.QueueEntryImpl.delete(QueueEntryImpl.java:572)
> at 
> org.apache.qpid.server.queue.AbstractQueue$11.postCommit(AbstractQueue.java:1729)
> at 
> org.apache.qpid.server.txn.AutoCommitTransaction.dequeue(AutoCommitTransaction.java:92)
> at 
> org.apache.qpid.server.queue.AbstractQueue.dequeueEntry(AbstractQueue.java:1722)
> at 
> org.apache.qpid.server.queue.AbstractQueue.dequeueEntry(AbstractQueue.java:1717)
> at 
> org.apache.qpid.server.queue.AbstractQueue.deleteEntry(AbstractQueue.java:1761)
> at 
> org.apache.qpid.server.queue.AbstractQueue.checkMessageStatus(AbstractQueue.java:2165)
> at 
> org.apache.qpid.server.virtualhost.AbstractVirtualHost$VirtualHostHouseKeepingTask.execute(AbstractVirtualHost.java:1965)
> at 
> org.apache.qpid.server.virtualhost.HouseKeepingTask$1.run(HouseKeepingTask.java:56)
> at java.security.AccessController.doPrivileged(Native Method)
> at 
> org.apache.qpid.server.virtualhost.HouseKeepingTask.run(HouseKeepingTask.java:51)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at 
> org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.lambda$null$0(QpidByteBufferFactory.java:464)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: com.sleepycat.je.rep.InsufficientAcksException: (JE 

[jira] [Comment Edited] (QPID-8369) [Broker-J] Limit number of connections per user

2019-10-02 Thread Alex Rudyy (Jira)


[ 
https://issues.apache.org/jira/browse/QPID-8369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942677#comment-16942677
 ] 

Alex Rudyy edited comment on QPID-8369 at 10/2/19 10:10 AM:


The suggested limits (number of connections per user and maximum frequency of 
connections per user)  can be implemented as settings in ACL rules. We already 
have {{VirtualHost}} access rule which can be expressed like below:
{noformat}
ACL ALLOW-LOG quest ACCESS VIRTUALHOST
{noformat}
Potentially, the rule can be expanded to something like below
{noformat}
ACL ALLOW-LOG quest ACCESS VIRTUALHOST connection_limit=10 
connection_frequency_limit=60
{noformat} 

The {{connection_limit}} setting in the {{ALLOW}} ACL rule above would limit 
the number of connections allowed to create by "guest" to {{10}} . Whilst the 
{{connection_frequency_limit}}  would limit the maximum frequency of connection 
creation for "guest" to {{60}}.

Essentially, any user or a group of users could be limited in such way. Absence 
of  {{connection_limit}} and {{connection_frequency_limit}} settings would 
indicate about unlimited access.

Providing such settings in {{DENY}} rule does not looks to me as having much 
sense. Thus, only {{ALLOW}} ACL {{ACCESS}} rule can have such limits.

What do you think about such approach?

Obviously, the rule will limit only AMQP connections. If malicious user would 
try to perform DOS attack, the rule would be applied on finishing of 
authentication stage. Thus, before the authentication any number of TCP 
connections can be created. I am wondering whether a similar limits can be 
applied to IP or domain addresses in order to restrict the number of TCP 
connections which can be open from given host or domain address. Thus, if 
IP/domain address check is performed immediately after opening of TCP 
connection, it would eliminate the need to wait for applying the limit for 
connection principal, if IP/domain address limit is breached. Thus,  such 
breaching connection would be closed immediately and might save some host 
resources. I am not sure whether adding such check make sense.   Perhaps, it 
should be a responsibility of some proxy/gateway sitting in front of the broker 
instance. What do you think?




was (Author: alex.rufous):
The suggested limits (number of connections per user and maximum frequency of 
connections per user)  can be implemented as settings in ACL rules. We already 
have {{VirtualHost}} access rule which can be expressed like below:
{noformat}
ACL ALLOW-LOG quest ACCESS VIRTUALHOST
{noformat}
Potentially, the rule can be expanded to something like below
{noformat}
ACL ALLOW-LOG quest ACCESS VIRTUALHOST connection_limit=10 
connection_frequency_limit=60
{noformat} 

The {{connection_limit}} setting in the {{ALLOW}} ACL rule above would limit 
the number of connections allowed to create by "guest" to {{10}} . Whilst the 
{{connection_frequency_limit}}  would limit the maximum frequency of connection 
creation for "guest" to {{60}}.

Essentially, any user or a group of users could be limited in such way. Absence 
of  {{connection_limit}} and {{connection_frequency_limit}} settings would 
incicate about unlimited access.

Providing such settings in {{DENY}} rule does not looks to me as having much 
sense. Thus, only {{ALLOW}} ACL {{ACCESS}} rule can have such limits.

What do you think about such approach?

Obviously, the rule will limit only AMQP connections. If malicious user would 
try to perform DOS attack, the rule would be applied on finishing of 
authentication stage. Thus, before the authentication any number of TCP 
connections can be created. I am wondering whether a similar limits can be 
applied to IP or domain addresses in order to restrict the number of TCP 
connections which can be open from given host or domain address. Thus, if 
IP/domain address check is performed immediately after opening of TCP 
connection, it would eliminate the need to wait for applying the limit for 
connection principal, if IP/domain address limit is breached. Thus,  such 
breaching connection would be closed immediately and might save some host 
resources. I am not sure whether adding such check make sense.   Perhaps, it 
should be a responsibility of some proxy/gateway sitting in front of the broker 
instance. What do you think?



> [Broker-J] Limit number of connections per user
> ---
>
> Key: QPID-8369
> URL: https://issues.apache.org/jira/browse/QPID-8369
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Tomas Vavricka
>Priority: Major
>  Labels: connection, limit, user
> Fix For: qpid-java-broker-8.0.0
>
>
> There is only limit for number of connections per amqp/amqps port.
> If some user creates too much connections, he can 

[jira] [Comment Edited] (QPID-8369) [Broker-J] Limit number of connections per user

2019-10-02 Thread Alex Rudyy (Jira)


[ 
https://issues.apache.org/jira/browse/QPID-8369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942677#comment-16942677
 ] 

Alex Rudyy edited comment on QPID-8369 at 10/2/19 10:08 AM:


The suggested limits (number of connections per user and maximum frequency of 
connections per user)  can be implemented as settings in ACL rules. We already 
have {{VirtualHost}} access rule which can be expressed like below:
{noformat}
ACL ALLOW-LOG quest ACCESS VIRTUALHOST
{noformat}
Potentially, the rule can be expanded to something like below
{noformat}
ACL ALLOW-LOG quest ACCESS VIRTUALHOST connection_limit=10 
connection_frequency_limit=60
{noformat} 

The {{connection_limit}} setting in the {{ALLOW}} ACL rule above would limit 
the number of connections allowed to create by "guest" to {{10}} . Whilst the 
{{connection_frequency_limit}}  would limit the maximum frequency of connection 
creation for "guest" to {{60}}.

Essentially, any user or a group of users could be limited in such way. Absence 
of  {{connection_limit}} and {{connection_frequency_limit}} settings would 
incicate about unlimited access.

Providing such settings in {{DENY}} rule does not looks to me as having much 
sense. Thus, only {{ALLOW}} ACL {{ACCESS}} rule can have such limits.

What do you think about such approach?

Obviously, the rule will limit only AMQP connections. If malicious user would 
try to perform DOS attack, the rule would be applied on finishing of 
authentication stage. Thus, before the authentication any number of TCP 
connections can be created. I am wondering whether a similar limits can be 
applied to IP or domain addresses in order to restrict the number of TCP 
connections which can be open from given host or domain address. Thus, if 
IP/domain address check is performed immediately after opening of TCP 
connection, it would eliminate the need to wait for applying the limit for 
connection principal, if IP/domain address limit is breached. Thus,  such 
breaching connection would be closed immediately and might save some host 
resources. I am not sure whether adding such check make sense.   Perhaps, it 
should be a responsibility of some proxy/gateway sitting in front of the broker 
instance. What do you think?




was (Author: alex.rufous):
The suggested limits (number of connections per user and maximum frequency of 
connections per user)  can be implemented as settings in ACL rules. We already 
have {{VirtualHost}} access rule which can be expressed like below:
{noformat}
ACL ALLOW-LOG quest ACCESS VIRTUALHOST
{noformat}
Potentially, the rule can be expanded to something like below
{noformat}
ACL ALLOW-LOG quest ACCESS VIRTUALHOST connection_limit=10 
connection_frequency_limit=60
{noformat} 

The {{connection_limit}} setting in the {{ALLOW}} ACL rule above would limit 
the number of connections allowed to create by "guest" to {{10}} . Whilst the 
and {{connection_frequency_limit}}  would limit the maximum frequency of 
connection creation for "guest" to {{60}}.

Essentially, any user or a group of users could be limited in such way. Absence 
of  {{connection_limit}} and {{connection_frequency_limit}} settings would 
incicate about unlimited access.

Providing such settings in {{DENY}} rule does not looks to me as having much 
sense. Thus, only {{ALLOW}} ACL {{ACCESS}} rule can have such limits.

What do you think about such approach?

Obviously, the rule will limit only AMQP connections. If malicious user would 
try to perform DOS attack, the rule would be applied on finishing of 
authentication stage. Thus, before the authentication any number of TCP 
connections can be created. I am wondering whether a similar limits can be 
applied to IP or domain addresses in order to restrict the number of TCP 
connections which can be open from given host or domain address. Thus, if 
IP/domain address check is performed immediately after opening of TCP 
connection, it would eliminate the need to wait for applying the limit for 
connection principal, if IP/domain address limit is breached. Thus,  such 
breaching connection would be closed immediately and might save some host 
resources. I am not sure whether adding such check make sense.   Perhaps, it 
should be a responsibility of some proxy/gateway sitting in front of the broker 
instance. What do you think?



> [Broker-J] Limit number of connections per user
> ---
>
> Key: QPID-8369
> URL: https://issues.apache.org/jira/browse/QPID-8369
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Tomas Vavricka
>Priority: Major
>  Labels: connection, limit, user
> Fix For: qpid-java-broker-8.0.0
>
>
> There is only limit for number of connections per amqp/amqps port.
> If some user creates too much connections, he can 

[jira] [Commented] (QPID-8369) [Broker-J] Limit number of connections per user

2019-10-02 Thread Alex Rudyy (Jira)


[ 
https://issues.apache.org/jira/browse/QPID-8369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942677#comment-16942677
 ] 

Alex Rudyy commented on QPID-8369:
--

The suggested limits (number of connections per user and maximum frequency of 
connections per user)  can be implemented as settings in ACL rules. We already 
have {{VirtualHost}} access rule which can be expressed like below:
{noformat}
ACL ALLOW-LOG quest ACCESS VIRTUALHOST
{noformat}
Potentially, the rule can be expanded to something like below
{noformat}
ACL ALLOW-LOG quest ACCESS VIRTUALHOST connection_limit=10 
connection_frequency_limit=60
{noformat} 

The {{connection_limit}} setting in the {{ALLOW}} ACL rule above would limit 
the number of connections allowed to create by "guest" to {{10}} . Whilst the 
and {{connection_frequency_limit}}  would limit the maximum frequency of 
connection creation for "guest" to {{60}}.

Essentially, any user or a group of users could be limited in such way. Absence 
of  {{connection_limit}} and {{connection_frequency_limit}} settings would 
incicate about unlimited access.

Providing such settings in {{DENY}} rule does not looks to me as having much 
sense. Thus, only {{ALLOW}} ACL {{ACCESS}} rule can have such limits.

What do you think about such approach?

Obviously, the rule will limit only AMQP connections. If malicious user would 
try to perform DOS attack, the rule would be applied on finishing of 
authentication stage. Thus, before the authentication any number of TCP 
connections can be created. I am wondering whether a similar limits can be 
applied to IP or domain addresses in order to restrict the number of TCP 
connections which can be open from given host or domain address. Thus, if 
IP/domain address check is performed immediately after opening of TCP 
connection, it would eliminate the need to wait for applying the limit for 
connection principal, if IP/domain address limit is breached. Thus,  such 
breaching connection would be closed immediately and might save some host 
resources. I am not sure whether adding such check make sense.   Perhaps, it 
should be a responsibility of some proxy/gateway sitting in front of the broker 
instance. What do you think?



> [Broker-J] Limit number of connections per user
> ---
>
> Key: QPID-8369
> URL: https://issues.apache.org/jira/browse/QPID-8369
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Tomas Vavricka
>Priority: Major
>  Labels: connection, limit, user
> Fix For: qpid-java-broker-8.0.0
>
>
> There is only limit for number of connections per amqp/amqps port.
> If some user creates too much connections, he can prevent other users from 
> connecting to amqp ports.
> Qpid Broker-J should support some limitation for connections per user.
> Broker should also support limitation of number of created connections per 
> time frame ex: create 60 connections per one minute at maximum



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Updated] (QPID-8366) [Broker-J] The loss of BDB HA majority on invocation of house keeping operations can crash the broker

2019-10-02 Thread Alex Rudyy (Jira)


 [ 
https://issues.apache.org/jira/browse/QPID-8366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8366:
-
Status: Reviewable  (was: In Progress)

> [Broker-J] The loss of BDB HA majority on invocation of house keeping 
> operations can crash the broker
> -
>
> Key: QPID-8366
> URL: https://issues.apache.org/jira/browse/QPID-8366
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.0, qpid-java-broker-7.0.4, 
> qpid-java-broker-7.0.5, qpid-java-broker-7.0.6, qpid-java-broker-7.0.7, 
> qpid-java-broker-7.1.1, qpid-java-broker-7.1.2, qpid-java-broker-7.0.8, 
> qpid-java-broker-7.1.3, qpid-java-broker-7.1.4
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.0.9, 
> qpid-java-broker-7.1.5
>
>
> The {{ConnectionScopedRuntimeException}} thrown from {{VirtualHost}} {{House 
> Keeping}} thread on invocation of {{MessageStore}} operations like 
> {{checkMessageStatus}} can crash the broker. An example of such exception 
> stack trace  (from Qpid Broker version 7.0.6) is provided below:
> {noformat}
> 2019-09-27 07:53:38,168 ERROR [virtualhost-test-pool-1] (o.a.q.s.Main) - 
> Uncaught exception, shutting down.
> org.apache.qpid.server.util.ConnectionScopedRuntimeException: Required number 
> of nodes not reachable
> at 
> org.apache.qpid.server.store.berkeleydb.replication.ReplicatedEnvironmentFacade.handleDatabaseException(ReplicatedEnvironmentFacade.java:495)
> at 
> org.apache.qpid.server.store.berkeleydb.replication.ReplicatedEnvironmentFacade.commit(ReplicatedEnvironmentFacade.java:332)
> at 
> org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.removeMessage(AbstractBDBMessageStore.java:288)
> at 
> org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore$StoredBDBMessage.remove(AbstractBDBMessageStore.java:1090)
> at 
> org.apache.qpid.server.message.AbstractServerMessageImpl.decrementReference(AbstractServerMessageImpl.java:118)
> at 
> org.apache.qpid.server.message.AbstractServerMessageImpl.access$500(AbstractServerMessageImpl.java:37)
> at 
> org.apache.qpid.server.message.AbstractServerMessageImpl$Reference.release(AbstractServerMessageImpl.java:309)
> at 
> org.apache.qpid.server.queue.QueueEntryImpl.dispose(QueueEntryImpl.java:557)
> at 
> org.apache.qpid.server.queue.QueueEntryImpl.delete(QueueEntryImpl.java:572)
> at 
> org.apache.qpid.server.queue.AbstractQueue$11.postCommit(AbstractQueue.java:1729)
> at 
> org.apache.qpid.server.txn.AutoCommitTransaction.dequeue(AutoCommitTransaction.java:92)
> at 
> org.apache.qpid.server.queue.AbstractQueue.dequeueEntry(AbstractQueue.java:1722)
> at 
> org.apache.qpid.server.queue.AbstractQueue.dequeueEntry(AbstractQueue.java:1717)
> at 
> org.apache.qpid.server.queue.AbstractQueue.deleteEntry(AbstractQueue.java:1761)
> at 
> org.apache.qpid.server.queue.AbstractQueue.checkMessageStatus(AbstractQueue.java:2165)
> at 
> org.apache.qpid.server.virtualhost.AbstractVirtualHost$VirtualHostHouseKeepingTask.execute(AbstractVirtualHost.java:1965)
> at 
> org.apache.qpid.server.virtualhost.HouseKeepingTask$1.run(HouseKeepingTask.java:56)
> at java.security.AccessController.doPrivileged(Native Method)
> at 
> org.apache.qpid.server.virtualhost.HouseKeepingTask.run(HouseKeepingTask.java:51)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at 
> org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.lambda$null$0(QpidByteBufferFactory.java:464)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: com.sleepycat.je.rep.InsufficientAcksException: (JE 7.4.5) 
> Transaction: -3459038252  VLSN: 10,380,435,448, initiated at: 07:53:20.  
> Insufficient acks for policy:SIMPLE_MAJORITY. Need replica acks: 2. Missing 
> replica acks: 2. Timeout: 15000ms. FeederState=acc3_2(3)[MASTER]
> Current feeds:
>  acc3_1: feederVLSN=10,380,435,456 replicaTxnEndVLSN=10,380,435,396
>  acc3: feederVLSN=10,380,435,456 replicaTxnEndVLSN=10,380,435,396
> 

[jira] [Assigned] (QPID-8366) [Broker-J] The loss of BDB HA majority on invocation of house keeping operations can crash the broker

2019-10-02 Thread Alex Rudyy (Jira)


 [ 
https://issues.apache.org/jira/browse/QPID-8366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy reassigned QPID-8366:


Assignee: Alex Rudyy

> [Broker-J] The loss of BDB HA majority on invocation of house keeping 
> operations can crash the broker
> -
>
> Key: QPID-8366
> URL: https://issues.apache.org/jira/browse/QPID-8366
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.0, qpid-java-broker-7.0.4, 
> qpid-java-broker-7.0.5, qpid-java-broker-7.0.6, qpid-java-broker-7.0.7, 
> qpid-java-broker-7.1.1, qpid-java-broker-7.1.2, qpid-java-broker-7.0.8, 
> qpid-java-broker-7.1.3, qpid-java-broker-7.1.4
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.0.9, 
> qpid-java-broker-7.1.5
>
>
> The {{ConnectionScopedRuntimeException}} thrown from {{VirtualHost}} {{House 
> Keeping}} thread on invocation of {{MessageStore}} operations like 
> {{checkMessageStatus}} can crash the broker. An example of such exception 
> stack trace  (from Qpid Broker version 7.0.6) is provided below:
> {noformat}
> 2019-09-27 07:53:38,168 ERROR [virtualhost-test-pool-1] (o.a.q.s.Main) - 
> Uncaught exception, shutting down.
> org.apache.qpid.server.util.ConnectionScopedRuntimeException: Required number 
> of nodes not reachable
> at 
> org.apache.qpid.server.store.berkeleydb.replication.ReplicatedEnvironmentFacade.handleDatabaseException(ReplicatedEnvironmentFacade.java:495)
> at 
> org.apache.qpid.server.store.berkeleydb.replication.ReplicatedEnvironmentFacade.commit(ReplicatedEnvironmentFacade.java:332)
> at 
> org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.removeMessage(AbstractBDBMessageStore.java:288)
> at 
> org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore$StoredBDBMessage.remove(AbstractBDBMessageStore.java:1090)
> at 
> org.apache.qpid.server.message.AbstractServerMessageImpl.decrementReference(AbstractServerMessageImpl.java:118)
> at 
> org.apache.qpid.server.message.AbstractServerMessageImpl.access$500(AbstractServerMessageImpl.java:37)
> at 
> org.apache.qpid.server.message.AbstractServerMessageImpl$Reference.release(AbstractServerMessageImpl.java:309)
> at 
> org.apache.qpid.server.queue.QueueEntryImpl.dispose(QueueEntryImpl.java:557)
> at 
> org.apache.qpid.server.queue.QueueEntryImpl.delete(QueueEntryImpl.java:572)
> at 
> org.apache.qpid.server.queue.AbstractQueue$11.postCommit(AbstractQueue.java:1729)
> at 
> org.apache.qpid.server.txn.AutoCommitTransaction.dequeue(AutoCommitTransaction.java:92)
> at 
> org.apache.qpid.server.queue.AbstractQueue.dequeueEntry(AbstractQueue.java:1722)
> at 
> org.apache.qpid.server.queue.AbstractQueue.dequeueEntry(AbstractQueue.java:1717)
> at 
> org.apache.qpid.server.queue.AbstractQueue.deleteEntry(AbstractQueue.java:1761)
> at 
> org.apache.qpid.server.queue.AbstractQueue.checkMessageStatus(AbstractQueue.java:2165)
> at 
> org.apache.qpid.server.virtualhost.AbstractVirtualHost$VirtualHostHouseKeepingTask.execute(AbstractVirtualHost.java:1965)
> at 
> org.apache.qpid.server.virtualhost.HouseKeepingTask$1.run(HouseKeepingTask.java:56)
> at java.security.AccessController.doPrivileged(Native Method)
> at 
> org.apache.qpid.server.virtualhost.HouseKeepingTask.run(HouseKeepingTask.java:51)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at 
> org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.lambda$null$0(QpidByteBufferFactory.java:464)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: com.sleepycat.je.rep.InsufficientAcksException: (JE 7.4.5) 
> Transaction: -3459038252  VLSN: 10,380,435,448, initiated at: 07:53:20.  
> Insufficient acks for policy:SIMPLE_MAJORITY. Need replica acks: 2. Missing 
> replica acks: 2. Timeout: 15000ms. FeederState=acc3_2(3)[MASTER]
> Current feeds:
>  acc3_1: feederVLSN=10,380,435,456 replicaTxnEndVLSN=10,380,435,396
>  acc3: feederVLSN=10,380,435,456 replicaTxnEndVLSN=10,380,435,396
> at 

[jira] [Created] (QPID-8370) [Broker-J] Option to disable WebGUI

2019-10-02 Thread Tomas Vavricka (Jira)
Tomas Vavricka created QPID-8370:


 Summary: [Broker-J] Option to disable WebGUI
 Key: QPID-8370
 URL: https://issues.apache.org/jira/browse/QPID-8370
 Project: Qpid
  Issue Type: Improvement
  Components: Broker-J
Reporter: Tomas Vavricka
 Fix For: qpid-java-broker-8.0.0


Qpid Broker-J should support disabling of WebGui by configuration parameter.

Broker REST API should be enabled even if broker's WebGui is disabled.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Created] (QPID-8369) [Broker-J] Limit number of connections per user

2019-10-02 Thread Tomas Vavricka (Jira)
Tomas Vavricka created QPID-8369:


 Summary: [Broker-J] Limit number of connections per user
 Key: QPID-8369
 URL: https://issues.apache.org/jira/browse/QPID-8369
 Project: Qpid
  Issue Type: Improvement
  Components: Broker-J
Reporter: Tomas Vavricka
 Fix For: qpid-java-broker-8.0.0


There is only limit for number of connections per amqp/amqps port.

If some user creates too much connections, he can prevent other users from 
connecting to amqp ports.

Qpid Broker-J should support some limitation for connections per user.
Broker should also support limitation of number of created connections per time 
frame ex: create 60 connections per one minute at maximum



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Updated] (QPID-8368) [Broker-J] Graylog support

2019-10-02 Thread Tomas Vavricka (Jira)


 [ 
https://issues.apache.org/jira/browse/QPID-8368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tomas Vavricka updated QPID-8368:
-
Fix Version/s: (was: Future)
   qpid-java-broker-8.0.0

> [Broker-J] Graylog support
> --
>
> Key: QPID-8368
> URL: https://issues.apache.org/jira/browse/QPID-8368
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Tomas Vavricka
>Priority: Major
>  Labels: logging
> Fix For: qpid-java-broker-8.0.0
>
>
> Graylog is widely used logging service based on ElasticSearch. Qpid Broker-J 
> should support Graylog as one of Broker Loggers type.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Updated] (QPID-8367) [Broker-J] Trusted CA revocation list

2019-10-02 Thread Tomas Vavricka (Jira)


 [ 
https://issues.apache.org/jira/browse/QPID-8367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tomas Vavricka updated QPID-8367:
-
Fix Version/s: (was: Future)
   qpid-java-broker-8.0.0

> [Broker-J] Trusted CA revocation list
> -
>
> Key: QPID-8367
> URL: https://issues.apache.org/jira/browse/QPID-8367
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Tomas Vavricka
>Priority: Major
> Fix For: qpid-java-broker-8.0.0
>
>
> Qpid Broker-J supports custom CA. When in place clients then can connect with 
> certificate signed by custom CA. 
> However there is no way to reject compromised certificates. Implementation of 
> revocation list for custom CA can solve this issue.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Created] (QPID-8368) [Broker-J] Graylog support

2019-10-02 Thread Tomas Vavricka (Jira)
Tomas Vavricka created QPID-8368:


 Summary: [Broker-J] Graylog support
 Key: QPID-8368
 URL: https://issues.apache.org/jira/browse/QPID-8368
 Project: Qpid
  Issue Type: Improvement
  Components: Broker-J
Reporter: Tomas Vavricka
 Fix For: Future


Graylog is widely used logging service based on ElasticSearch. Qpid Broker-J 
should support Graylog as one of Broker Loggers type.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Created] (QPID-8367) [Broker-J] Trusted CA revocation list

2019-10-02 Thread Tomas Vavricka (Jira)
Tomas Vavricka created QPID-8367:


 Summary: [Broker-J] Trusted CA revocation list
 Key: QPID-8367
 URL: https://issues.apache.org/jira/browse/QPID-8367
 Project: Qpid
  Issue Type: Improvement
  Components: Broker-J
Reporter: Tomas Vavricka
 Fix For: Future


Qpid Broker-J supports custom CA. When in place clients then can connect with 
certificate signed by custom CA. 

However there is no way to reject compromised certificates. Implementation of 
revocation list for custom CA can solve this issue.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org