[jira] [Commented] (PROTON-1293) Support username and password in electron go binding

[Richard Laos (JIRA)]

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

Richard Laos commented on PROTON-1293:
--

This enhancement request was to enable the use of the electron api with Azure. 
It looks like PROTON-1255 may resolve this.

> Support username and password in electron go binding
> 
>
> Key: PROTON-1293
> URL: https://issues.apache.org/jira/browse/PROTON-1293
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: go-binding
>Affects Versions: 0.15.0
>Reporter: Richard Laos
>Assignee: Alan Conway
>Priority: Minor
>
> It appears that the electron api does not support a username and password as 
> part of an amqp connection. However maybe the example just needs to included 
> this if it is supported.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (QPIDJMS-204) Race condition on Producer / Consumer create can miss remote close signal

[Timothy Bish (JIRA)]

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

Timothy Bish updated QPIDJMS-204:
-
Summary: Race condition on Producer / Consumer create can miss remote close 
signal  (was: Test case testRemotelyCloseProducer in ProducerIntegrationTest 
intermittently fails)

> Race condition on Producer / Consumer create can miss remote close signal
> -
>
> Key: QPIDJMS-204
> URL: https://issues.apache.org/jira/browse/QPIDJMS-204
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.10.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
>Priority: Minor
> Fix For: 0.11.0
>
>
> Need to investigate why this fails in CI occasionally.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (QPIDJMS-204) Test case testRemotelyCloseProducer in ProducerIntegrationTest intermittently fails

[Timothy Bish (JIRA)]

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

Timothy Bish resolved QPIDJMS-204.
--
   Resolution: Fixed
Fix Version/s: 0.11.0

> Test case testRemotelyCloseProducer in ProducerIntegrationTest intermittently 
> fails
> ---
>
> Key: QPIDJMS-204
> URL: https://issues.apache.org/jira/browse/QPIDJMS-204
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.10.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
>Priority: Minor
> Fix For: 0.11.0
>
>
> Need to investigate why this fails in CI occasionally.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (QPIDJMS-204) Test case testRemotelyCloseProducer in ProducerIntegrationTest intermittently fails

[Timothy Bish (JIRA)]

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

Timothy Bish updated QPIDJMS-204:
-
Issue Type: Bug  (was: Task)

> Test case testRemotelyCloseProducer in ProducerIntegrationTest intermittently 
> fails
> ---
>
> Key: QPIDJMS-204
> URL: https://issues.apache.org/jira/browse/QPIDJMS-204
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.10.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
>Priority: Minor
>
> Need to investigate why this fails in CI occasionally.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (QPIDJMS-204) Test case testRemotelyCloseProducer in ProducerIntegrationTest intermittently fails

[Timothy Bish (JIRA)]

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

Timothy Bish updated QPIDJMS-204:
-
Affects Version/s: 0.10.0

> Test case testRemotelyCloseProducer in ProducerIntegrationTest intermittently 
> fails
> ---
>
> Key: QPIDJMS-204
> URL: https://issues.apache.org/jira/browse/QPIDJMS-204
> Project: Qpid JMS
>  Issue Type: Task
>  Components: qpid-jms-client
>Affects Versions: 0.10.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
>Priority: Minor
>
> Need to investigate why this fails in CI occasionally.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPIDJMS-204) Test case testRemotelyCloseProducer in ProducerIntegrationTest intermittently fails

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPIDJMS-204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15456252#comment-15456252
 ] 

ASF subversion and git services commented on QPIDJMS-204:
-

Commit c676404d8e2aa49a2ed1811e9ba3dc53a3eed5b2 in qpid-jms's branch 
refs/heads/master from [~tabish121]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=c676404 ]

QPIDJMS-204 Fix intermittent test failure

The remote close occurs so close to the open that it showed a small race
where the session did not yet know about the producer and as such the
remote close event could not be propagated to it.  Consumer code has the
same issue and is fixed here as well. 

> Test case testRemotelyCloseProducer in ProducerIntegrationTest intermittently 
> fails
> ---
>
> Key: QPIDJMS-204
> URL: https://issues.apache.org/jira/browse/QPIDJMS-204
> Project: Qpid JMS
>  Issue Type: Task
>  Components: qpid-jms-client
>Reporter: Timothy Bish
>Assignee: Timothy Bish
>Priority: Minor
>
> Need to investigate why this fails in CI occasionally.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

RE: Dispute of CVSS Score for CVE-2016-4974

[Wergin, Charles (Assoc)]

Good afternoon,

Thank you for contacting the NVD regarding this issue.  We have adjusted the 
attack vectors based on the information you have provided.
Based on the CVSSv3 specification and scoring guidance, we feel the metrics for 
impact are accurate based on the current available information.  If you can 
provide additional publically available information that justifies other 
changes, we will investigate and perhaps further adjust the score.

Respectfully,

Chuck Wergin
National Vulnerability Database
nvd.nist.gov

-Original Message-
From: Lorenz Quack [mailto:quack.lor...@gmail.com] 
Sent: Thursday, September 01, 2016 8:23 AM
To: nvd 
Cc: dev@qpid.apache.org; secur...@apache.org
Subject: Dispute of CVSS Score for CVE-2016-4974

Dear Madam or Sir,

I would like to dispute the CVSS score of CVE-2016-4974 [1].

Upon our request the MITRE description [2] was recently changed to more 
accurately describe the circumstances under which this vulnerability can be 
exploited.  The original description read:

 Apache Qpid AMQP 0-x JMS client before 6.0.4 and JMS (AMQP
 1.0) before 0.10.0 does not restrict the use of classes
 available on the classpath, which might allow remote
 attackers to deserialize arbitrary objects and execute
 arbitrary code by leveraging a crafted serialized object in a
 JMS ObjectMessage that is handled by the getObject function.

This has been changed in the following way:

 [...] which might allow remote authenticated users with
 permission to send messages to deserialize arbitrary objects
 [...]

I can see that this change is already reflected in the NVD database.  However, 
the CVSS severity score has not been adjusted.

Our impression is that the current high rating is mainly due to the 
misunderstanding that this vulnerability could be exploited by a 
unauthenticated remote attacker which is not correct. To exploit the 
vulnerability the following conditions need to be
met:

  * The attacker needs authorization to send messages to the
target system.

  * The target application needs to call getObject() on the
received JMS message.

  * The target application needs to have additional exploitable
classes (e.g., Apache Commons Collections [3]) on the JVM
classpath.

For reference, Red Hat's CVVSv3 severity assessment [4] resulted in a score of 
5.6, whereas NVD's assessment [1] resulted in a score of 9.8.

Please let me know if you require further information to consider changing the 
CVSS score.


Kind regards,

Lorenz Quack
on behalf of the Apache Qpid Project Management Committee


[1] https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-4974
[2] https://cve.mitre.org/cgi-bin/cvename.cgi?name=2016-4974
[3] https://issues.apache.org/jira/browse/COLLECTIONS-580
[4] https://access.redhat.com/security/cve/CVE-2016-4974



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

[jira] [Commented] (PROTON-1294) c++ examples: remove un-necessary 64 bit integers.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on PROTON-1294:
-

Commit 76285f04e36cdbff68e98877cbc01bf4fb53 in qpid-proton's branch 
refs/heads/master from [~aconway]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=762 ]

PROTON-1294: c++ examples: remove un-necessary 64-bit integers

64 bit integers cause portability problems on some platforms (e.g. need extra
atomic library support on ppc 32 bit) and do not enhance the examples, keep 
them simple.


> c++ examples: remove un-necessary 64 bit integers.
> --
>
> Key: PROTON-1294
> URL: https://issues.apache.org/jira/browse/PROTON-1294
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: examples
>Affects Versions: 0.14.0
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Minor
> Fix For: 0.15.0
>
>
> 64 bit integers cause portability problems on some platforms (e.g. need extra 
> atomic library support on ppc 32 bit) and do not enhance the examples,
> keep them simple.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (PROTON-1294) c++ examples: remove un-necessary 64 bit integers.

[Alan Conway (JIRA)]

Alan Conway created PROTON-1294:
---

 Summary: c++ examples: remove un-necessary 64 bit integers.
 Key: PROTON-1294
 URL: https://issues.apache.org/jira/browse/PROTON-1294
 Project: Qpid Proton
  Issue Type: Improvement
  Components: examples
Affects Versions: 0.14.0
Reporter: Alan Conway
Assignee: Alan Conway
Priority: Minor
 Fix For: 0.15.0


64 bit integers cause portability problems on some platforms (e.g. need extra 
atomic library support on ppc 32 bit) and do not enhance the examples,
keep them simple.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPIDJMS-189) update JMSMessageID and JMSCorrelationID handling to address interop issues with non-JMS peers

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPIDJMS-189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15455979#comment-15455979
 ] 

ASF subversion and git services commented on QPIDJMS-189:
-

Commit ae12a5a73d6cbc0d5c4e6c44d73ec5ff45b70749 in qpid-jms's branch 
refs/heads/master from Robert Gemmell
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=ae12a5a ]

QPIDJMS-189: include new option value in the config docs


> update JMSMessageID and JMSCorrelationID handling to address interop issues 
> with non-JMS peers
> --
>
> Key: QPIDJMS-189
> URL: https://issues.apache.org/jira/browse/QPIDJMS-189
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.9.0, 0.10.0
>Reporter: Kai Hudalla
>Assignee: Robbie Gemmell
> Fix For: 0.11.0
>
> Attachments: 
> 0001-WIP-QPIDJMS-189-candidate-for-changes-to-JMSMessageI.patch
>
>
> When a JMS application sets JMSCorrelationID on a Message, it can do so 
> either using a JMSMessageID value (a String beginning with "ID:") or an 
> application-specific string value. Previously we decided that the "ID:" 
> prefix of a JMSMessageID should not be sent on the wire so other non-JMS 
> client need not deal with it, and a message-id recieved from a non-JMS client 
> would round-trip correctly as a correlation-id value. An annotation was used 
> on messages to record whether an application-specific JMSCorrelationID value 
> was in use so that recieving JMS clients would restore the 'ID:' prefix for 
> JMSCorrelationID if needed. 
> This approach has an issue in that if a correlation-id value is rountripped 
> into a response message by a client/service that doesnt understand the 
> annotations use and include it in the response, then the JMSCorrelationID 
> value retrieved from the response message may not match the value sent on the 
> original message. 
> Additionally, as originally noticed on this JIRA (details below), a bug and 
> loose test has meant that the client HAS begun sending the 'ID:' prefix for 
> JMSMessageID values inadvertantly, which when roundtripped to a response 
> message by a non-JMS peer, results in the JMSCorrelationID getting a second 
> erroneous 'ID:' prefix added when the response is examined by the original 
> JMS application.
> This JIRA will serve to introduce changes to the JMSMessageID and 
> JMSCorrelationID handling to help resolve these interop issues, changing 
> things such that the 'ID:' prefix is deliberately sent on the wire and for a 
> correlation ids is used in place of the annotation to discriminate between 
> one which is a message id string and one which is an application specific 
> string.
> 
> Original description
> I am trying to use Qpid JMS client to send a message to a non-JMS application 
> which returns a message to the client based on the request's reply-to 
> property.
> In order to correlate the response received from the non-JMS app with the 
> request, I want to use the incoming message's JMSCorrelationID property.
> The non-JMS application simply takes the incoming message's message-id 
> property and puts it into the outgoing response's correlation-id property.
> However, when I send a message using Qpid JMS with default configuration, 
> e.g. using a connection URI like {{amqp://myhost:myport}}, then the message 
> ID of the sent message retrieved via {{Message.getJMSMessageId()}} looks 
> something like {{ID:aef45f-...}} and the message-id of the incoming request 
> in the non-JMS app contains the same ID, i.e. {{ID:aef45f-...}}. However, the 
> correlation ID retrieved from the response via 
> {{Message.getJMSCorrelationId()}} at the JMS client starts with 
> {{ID:ID:aef45f-...}}, i.e. having a duplicate _ID:_ prefix, and thus cannot 
> be matched to the original message ID.
> I have tracked down the problem to the inconsistent implementation of 
> {{AmqpJmsMessageFacade}}'s {{getMessageId()}} and {{getCorrelationId()}} 
> methods. The former only adds an _ID:_ prefix to the underlying message ID if 
> it doesn't already contain that prefix whereas the latter always adds the 
> prefix (unless the {{x-opt-app-correlation-id}} header is set).
> The problem can be worked around by explicitly setting another connection ID 
> prefix using the {{jms.connectionIDPrefix}} connection URI parameter ni order 
> to define a different prefix than the default one (_ID_).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (QPIDJMS-187) remove deprecated configuration options

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell resolved QPIDJMS-187.

   Resolution: Fixed
 Assignee: Robbie Gemmell
Fix Version/s: 0.11.0

> remove deprecated configuration options
> ---
>
> Key: QPIDJMS-187
> URL: https://issues.apache.org/jira/browse/QPIDJMS-187
> Project: Qpid JMS
>  Issue Type: Improvement
>  Components: qpid-jms-client
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
> Fix For: 0.11.0
>
>
> This is a holder JIRA.
> The linked JIRAs deprecated certain configuration options, which we should 
> remove at some point.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPIDJMS-187) remove deprecated configuration options

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPIDJMS-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15455965#comment-15455965
 ] 

ASF subversion and git services commented on QPIDJMS-187:
-

Commit 8bdc6ee8bc1f9414e599032359a210fe0f7a72a4 in qpid-jms's branch 
refs/heads/master from Robert Gemmell
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=8bdc6ee ]

QPIDJMS-187: remove support for some previously deprecated options


> remove deprecated configuration options
> ---
>
> Key: QPIDJMS-187
> URL: https://issues.apache.org/jira/browse/QPIDJMS-187
> Project: Qpid JMS
>  Issue Type: Improvement
>  Components: qpid-jms-client
>Reporter: Robbie Gemmell
>
> This is a holder JIRA.
> The linked JIRAs deprecated certain configuration options, which we should 
> remove at some point.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (DISPATCH-494) Policy objects do not support management update and delete directives

[Chuck Rolke (JIRA)]

Chuck Rolke created DISPATCH-494:


 Summary: Policy objects do not support management update and 
delete directives
 Key: DISPATCH-494
 URL: https://issues.apache.org/jira/browse/DISPATCH-494
 Project: Qpid Dispatch
  Issue Type: Bug
  Components: Policy Engine
Affects Versions: 0.6.1
Reporter: Chuck Rolke
Assignee: Chuck Rolke






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPID-7413) [Java Broker, WMC] Fix minor defects and usability issues in query and dashboard UI

[Alex Rudyy (JIRA)]

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

Alex Rudyy commented on QPID-7413:
--

Here are the list of further changes which need to be added into query and 
dashboard UI:

"Scope" should be replaced with: 
"Associate query with" (for query)
"Associate dashboard with" (for dashboard)

Query Category should be replaced with:
"What to query for"

A tooltip for the query scope ("Associate query with") would be:

If Broker is selected then any entity within the Broker can be queried.
If Virtual Host is selected then only entities on the selected Virtual Host can 
be queried.
Queries associated with a Virtual Host will be replicated across HA nodes.
Queries can be added to the dashboards having the same associated object.  

A tooltip for query category ("What to query for") would be:
Determines the category of configured objects to select.

A tooltip for dashboard would be:
Detremines where to save the dashboard. 
Only queries with the same associated object can be added to the dashboard.
Dashboards associated with a Virtual Host will be replicated across HA nodes.

> [Java Broker, WMC] Fix minor defects and usability issues in query and 
> dashboard UI
> ---
>
> Key: QPID-7413
> URL: https://issues.apache.org/jira/browse/QPID-7413
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.0.1
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
> Fix For: qpid-java-6.1
>
>
> # Menu bar - the serialized form of the username in the menu bar looks ugly
> # Menu bar is a muddle of some with icons some with text and some with both.  
> We said all menu titles would have a word and icon.  We said menu entries 
> would not have an icon.
> # Rename Show Xxx Browser => Browse Xx
> # Add explanatory text to the Create Query and Create Dashboard dialogues to 
> help the user understand what scope and category mean.
> # In the save dialogues, the fully qualified name of the group should be 
> visible to the user, perhaps as a hover.
> # A newly cloned query does not warn if it is closed before save has been 
> pressed.
> # Use qpid confirmation dialogue box instead of system confirmation dialogue 
> universally
> # On the Query and Dashboard browsers rename "Mine" to "Created by me"
> # Add the ability select a query from the query browser with the Return key.
> # Add an icon to the "Add Widget" button
> # Add units to the refresh period in the widget customization dialogue
> # Defect:  With a group of HA nodes, create a virtualhost scoped dashboard 
> containing a virtualhost scoped query,   Flip the mastership Expected 
> behaviour - dashboard and widget should be present on the new master.  
> Actual: dashboard was present but was empty.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[HEADS UP] JMS client 0.11.0 release etc

[Robbie Gemmell]

Hi folks,

Just a heads up that I'll be looking at doing a 0.11.0 JMS client
release next week, likely cutting earlier in the week to hopefully
allow completing later in the week.

Beyond that, I'll likely skip master a little up to 0.20.0-SNAPSHOT so
it can begin taking work on implementing JMS 2 support, giving some
room for some more interim 0.1X.Y releases if need be.

Robbie

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

[jira] [Resolved] (QPIDJMS-191) Add a WebSocket based transport to the client

[Timothy Bish (JIRA)]

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

Timothy Bish resolved QPIDJMS-191.
--
Resolution: Fixed

> Add a WebSocket based transport to the client
> -
>
> Key: QPIDJMS-191
> URL: https://issues.apache.org/jira/browse/QPIDJMS-191
> Project: Qpid JMS
>  Issue Type: New Feature
>  Components: qpid-jms-client
>Affects Versions: 0.10.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
> Fix For: 0.11.0
>
>
> Add a WebSocket based Transport to the client 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (QPIDJMS-199) Remote close of a session with producer blocked waiting for credit doesn't fail the send

[Timothy Bish (JIRA)]

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

Timothy Bish resolved QPIDJMS-199.
--
Resolution: Fixed

Tests are stable now, resources are closed as expected. 

> Remote close of a session with producer blocked waiting for credit doesn't 
> fail the send
> 
>
> Key: QPIDJMS-199
> URL: https://issues.apache.org/jira/browse/QPIDJMS-199
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.10.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
> Fix For: 0.11.0
>
>
> If a session is remotely ended and there happens to be a producer trying to 
> send but the send is blocked because the link does not have credit the 
> session will be closed but the send operation that is blocked is not failed 
> and unblocked.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (QPIDJMS-201) Consumer handling of no drain response can unsubscribe a durable subscription

[Timothy Bish (JIRA)]

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

Timothy Bish resolved QPIDJMS-201.
--
Resolution: Fixed

The tests for this seem stable now.

> Consumer handling of no drain response can unsubscribe a durable subscription
> -
>
> Key: QPIDJMS-201
> URL: https://issues.apache.org/jira/browse/QPIDJMS-201
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.10.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
> Fix For: 0.11.0
>
>
> When a MessageConsumer fails to receive a response to a drain request it 
> closes the consumer instance which triggers the link to be closed, if that 
> happens to be a consumer on a durable subscription it also results in the 
> subscription being unsubscribed.  The handler needs to detach the receiver in 
> this case instead of closing it.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (QPIDJMS-189) update JMSMessageID and JMSCorrelationID handling to address interop issues with non-JMS peers

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell resolved QPIDJMS-189.

Resolution: Fixed

> update JMSMessageID and JMSCorrelationID handling to address interop issues 
> with non-JMS peers
> --
>
> Key: QPIDJMS-189
> URL: https://issues.apache.org/jira/browse/QPIDJMS-189
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.9.0, 0.10.0
>Reporter: Kai Hudalla
>Assignee: Robbie Gemmell
> Fix For: 0.11.0
>
> Attachments: 
> 0001-WIP-QPIDJMS-189-candidate-for-changes-to-JMSMessageI.patch
>
>
> When a JMS application sets JMSCorrelationID on a Message, it can do so 
> either using a JMSMessageID value (a String beginning with "ID:") or an 
> application-specific string value. Previously we decided that the "ID:" 
> prefix of a JMSMessageID should not be sent on the wire so other non-JMS 
> client need not deal with it, and a message-id recieved from a non-JMS client 
> would round-trip correctly as a correlation-id value. An annotation was used 
> on messages to record whether an application-specific JMSCorrelationID value 
> was in use so that recieving JMS clients would restore the 'ID:' prefix for 
> JMSCorrelationID if needed. 
> This approach has an issue in that if a correlation-id value is rountripped 
> into a response message by a client/service that doesnt understand the 
> annotations use and include it in the response, then the JMSCorrelationID 
> value retrieved from the response message may not match the value sent on the 
> original message. 
> Additionally, as originally noticed on this JIRA (details below), a bug and 
> loose test has meant that the client HAS begun sending the 'ID:' prefix for 
> JMSMessageID values inadvertantly, which when roundtripped to a response 
> message by a non-JMS peer, results in the JMSCorrelationID getting a second 
> erroneous 'ID:' prefix added when the response is examined by the original 
> JMS application.
> This JIRA will serve to introduce changes to the JMSMessageID and 
> JMSCorrelationID handling to help resolve these interop issues, changing 
> things such that the 'ID:' prefix is deliberately sent on the wire and for a 
> correlation ids is used in place of the annotation to discriminate between 
> one which is a message id string and one which is an application specific 
> string.
> 
> Original description
> I am trying to use Qpid JMS client to send a message to a non-JMS application 
> which returns a message to the client based on the request's reply-to 
> property.
> In order to correlate the response received from the non-JMS app with the 
> request, I want to use the incoming message's JMSCorrelationID property.
> The non-JMS application simply takes the incoming message's message-id 
> property and puts it into the outgoing response's correlation-id property.
> However, when I send a message using Qpid JMS with default configuration, 
> e.g. using a connection URI like {{amqp://myhost:myport}}, then the message 
> ID of the sent message retrieved via {{Message.getJMSMessageId()}} looks 
> something like {{ID:aef45f-...}} and the message-id of the incoming request 
> in the non-JMS app contains the same ID, i.e. {{ID:aef45f-...}}. However, the 
> correlation ID retrieved from the response via 
> {{Message.getJMSCorrelationId()}} at the JMS client starts with 
> {{ID:ID:aef45f-...}}, i.e. having a duplicate _ID:_ prefix, and thus cannot 
> be matched to the original message ID.
> I have tracked down the problem to the inconsistent implementation of 
> {{AmqpJmsMessageFacade}}'s {{getMessageId()}} and {{getCorrelationId()}} 
> methods. The former only adds an _ID:_ prefix to the underlying message ID if 
> it doesn't already contain that prefix whereas the latter always adds the 
> prefix (unless the {{x-opt-app-correlation-id}} header is set).
> The problem can be worked around by explicitly setting another connection ID 
> prefix using the {{jms.connectionIDPrefix}} connection URI parameter ni order 
> to define a different prefix than the default one (_ID_).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPIDJMS-189) update JMSMessageID and JMSCorrelationID handling to address interop issues with non-JMS peers

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPIDJMS-189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15455694#comment-15455694
 ] 

ASF subversion and git services commented on QPIDJMS-189:
-

Commit 443a54d6c9fa919253316f01bbeed83bb27e7aef in qpid-jms's branch 
refs/heads/master from Robert Gemmell
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=443a54d ]

QPIDJMS-189: some test cleanup


> update JMSMessageID and JMSCorrelationID handling to address interop issues 
> with non-JMS peers
> --
>
> Key: QPIDJMS-189
> URL: https://issues.apache.org/jira/browse/QPIDJMS-189
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.9.0, 0.10.0
>Reporter: Kai Hudalla
>Assignee: Robbie Gemmell
> Fix For: 0.11.0
>
> Attachments: 
> 0001-WIP-QPIDJMS-189-candidate-for-changes-to-JMSMessageI.patch
>
>
> When a JMS application sets JMSCorrelationID on a Message, it can do so 
> either using a JMSMessageID value (a String beginning with "ID:") or an 
> application-specific string value. Previously we decided that the "ID:" 
> prefix of a JMSMessageID should not be sent on the wire so other non-JMS 
> client need not deal with it, and a message-id recieved from a non-JMS client 
> would round-trip correctly as a correlation-id value. An annotation was used 
> on messages to record whether an application-specific JMSCorrelationID value 
> was in use so that recieving JMS clients would restore the 'ID:' prefix for 
> JMSCorrelationID if needed. 
> This approach has an issue in that if a correlation-id value is rountripped 
> into a response message by a client/service that doesnt understand the 
> annotations use and include it in the response, then the JMSCorrelationID 
> value retrieved from the response message may not match the value sent on the 
> original message. 
> Additionally, as originally noticed on this JIRA (details below), a bug and 
> loose test has meant that the client HAS begun sending the 'ID:' prefix for 
> JMSMessageID values inadvertantly, which when roundtripped to a response 
> message by a non-JMS peer, results in the JMSCorrelationID getting a second 
> erroneous 'ID:' prefix added when the response is examined by the original 
> JMS application.
> This JIRA will serve to introduce changes to the JMSMessageID and 
> JMSCorrelationID handling to help resolve these interop issues, changing 
> things such that the 'ID:' prefix is deliberately sent on the wire and for a 
> correlation ids is used in place of the annotation to discriminate between 
> one which is a message id string and one which is an application specific 
> string.
> 
> Original description
> I am trying to use Qpid JMS client to send a message to a non-JMS application 
> which returns a message to the client based on the request's reply-to 
> property.
> In order to correlate the response received from the non-JMS app with the 
> request, I want to use the incoming message's JMSCorrelationID property.
> The non-JMS application simply takes the incoming message's message-id 
> property and puts it into the outgoing response's correlation-id property.
> However, when I send a message using Qpid JMS with default configuration, 
> e.g. using a connection URI like {{amqp://myhost:myport}}, then the message 
> ID of the sent message retrieved via {{Message.getJMSMessageId()}} looks 
> something like {{ID:aef45f-...}} and the message-id of the incoming request 
> in the non-JMS app contains the same ID, i.e. {{ID:aef45f-...}}. However, the 
> correlation ID retrieved from the response via 
> {{Message.getJMSCorrelationId()}} at the JMS client starts with 
> {{ID:ID:aef45f-...}}, i.e. having a duplicate _ID:_ prefix, and thus cannot 
> be matched to the original message ID.
> I have tracked down the problem to the inconsistent implementation of 
> {{AmqpJmsMessageFacade}}'s {{getMessageId()}} and {{getCorrelationId()}} 
> methods. The former only adds an _ID:_ prefix to the underlying message ID if 
> it doesn't already contain that prefix whereas the latter always adds the 
> prefix (unless the {{x-opt-app-correlation-id}} header is set).
> The problem can be worked around by explicitly setting another connection ID 
> prefix using the {{jms.connectionIDPrefix}} connection URI parameter ni order 
> to define a different prefix than the default one (_ID_).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPIDJMS-189) update JMSMessageID and JMSCorrelationID handling to address interop issues with non-JMS peers

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPIDJMS-189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15455692#comment-15455692
 ] 

ASF subversion and git services commented on QPIDJMS-189:
-

Commit 7b34f4fc3f62bc04dff36cdf0e110e6436a66dc9 in qpid-jms's branch 
refs/heads/master from Robert Gemmell
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=7b34f4f ]

QPIDJMS-189: update handling of JMSMessageID and JMSCorrelationID, facilitate 
better interop with non-JMS peers when round tripping for correlation

- Send the 'ID:' prefix of JMSMessageID values on the wire [Deliberately, as 
opposed to accidentally as started happening].
- Use the 'ID:' prefix on the wire for string based correlation-id values to 
distinguish whether they are application-specific or JMSMessageID based values.
- Use AMQP_NO_PREFIX to escape arriving message-id strings that dont have the 
'ID:' prefix so they can be correctly round tripped back as correlation-id.
- Account for arriving message-id and correlation-id strings that start with 
'ID:' *then* an encoding prefix, ensure they roundtrip correctly to 
JMSCorrelationID.
- Add PREFIXED_UUID_STRING option for sent message-id, leave existing option 
sending stringified UUID only.


> update JMSMessageID and JMSCorrelationID handling to address interop issues 
> with non-JMS peers
> --
>
> Key: QPIDJMS-189
> URL: https://issues.apache.org/jira/browse/QPIDJMS-189
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.9.0, 0.10.0
>Reporter: Kai Hudalla
>Assignee: Robbie Gemmell
> Fix For: 0.11.0
>
> Attachments: 
> 0001-WIP-QPIDJMS-189-candidate-for-changes-to-JMSMessageI.patch
>
>
> When a JMS application sets JMSCorrelationID on a Message, it can do so 
> either using a JMSMessageID value (a String beginning with "ID:") or an 
> application-specific string value. Previously we decided that the "ID:" 
> prefix of a JMSMessageID should not be sent on the wire so other non-JMS 
> client need not deal with it, and a message-id recieved from a non-JMS client 
> would round-trip correctly as a correlation-id value. An annotation was used 
> on messages to record whether an application-specific JMSCorrelationID value 
> was in use so that recieving JMS clients would restore the 'ID:' prefix for 
> JMSCorrelationID if needed. 
> This approach has an issue in that if a correlation-id value is rountripped 
> into a response message by a client/service that doesnt understand the 
> annotations use and include it in the response, then the JMSCorrelationID 
> value retrieved from the response message may not match the value sent on the 
> original message. 
> Additionally, as originally noticed on this JIRA (details below), a bug and 
> loose test has meant that the client HAS begun sending the 'ID:' prefix for 
> JMSMessageID values inadvertantly, which when roundtripped to a response 
> message by a non-JMS peer, results in the JMSCorrelationID getting a second 
> erroneous 'ID:' prefix added when the response is examined by the original 
> JMS application.
> This JIRA will serve to introduce changes to the JMSMessageID and 
> JMSCorrelationID handling to help resolve these interop issues, changing 
> things such that the 'ID:' prefix is deliberately sent on the wire and for a 
> correlation ids is used in place of the annotation to discriminate between 
> one which is a message id string and one which is an application specific 
> string.
> 
> Original description
> I am trying to use Qpid JMS client to send a message to a non-JMS application 
> which returns a message to the client based on the request's reply-to 
> property.
> In order to correlate the response received from the non-JMS app with the 
> request, I want to use the incoming message's JMSCorrelationID property.
> The non-JMS application simply takes the incoming message's message-id 
> property and puts it into the outgoing response's correlation-id property.
> However, when I send a message using Qpid JMS with default configuration, 
> e.g. using a connection URI like {{amqp://myhost:myport}}, then the message 
> ID of the sent message retrieved via {{Message.getJMSMessageId()}} looks 
> something like {{ID:aef45f-...}} and the message-id of the incoming request 
> in the non-JMS app contains the same ID, i.e. {{ID:aef45f-...}}. However, the 
> correlation ID retrieved from the response via 
> {{Message.getJMSCorrelationId()}} at the JMS client starts with 
> {{ID:ID:aef45f-...}}, i.e. having a duplicate _ID:_ prefix, and thus cannot 
> be matched to the original message ID.
> I have tracked down the problem to the inconsistent implementation of 
> {{AmqpJmsMessageFacade}}'s 

[jira] [Updated] (QPIDJMS-189) update JMSMessageID and JMSCorrelationID handling to address interop issues with non-JMS peers

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell updated QPIDJMS-189:
---
 Assignee: Robbie Gemmell
Affects Version/s: 0.10.0
  Description: 
When a JMS application sets JMSCorrelationID on a Message, it can do so either 
using a JMSMessageID value (a String beginning with "ID:") or an 
application-specific string value. Previously we decided that the "ID:" prefix 
of a JMSMessageID should not be sent on the wire so other non-JMS client need 
not deal with it, and a message-id recieved from a non-JMS client would 
round-trip correctly as a correlation-id value. An annotation was used on 
messages to record whether an application-specific JMSCorrelationID value was 
in use so that recieving JMS clients would restore the 'ID:' prefix for 
JMSCorrelationID if needed. 

This approach has an issue in that if a correlation-id value is rountripped 
into a response message by a client/service that doesnt understand the 
annotations use and include it in the response, then the JMSCorrelationID value 
retrieved from the response message may not match the value sent on the 
original message. 

Additionally, as originally noticed on this JIRA (details below), a bug and 
loose test has meant that the client HAS begun sending the 'ID:' prefix for 
JMSMessageID values inadvertantly, which when roundtripped to a response 
message by a non-JMS peer, results in the JMSCorrelationID getting a second 
erroneous 'ID:' prefix added when the response is examined by the original JMS 
application.

This JIRA will serve to introduce changes to the JMSMessageID and 
JMSCorrelationID handling to help resolve these interop issues, changing things 
such that the 'ID:' prefix is deliberately sent on the wire and for a 
correlation ids is used in place of the annotation to discriminate between one 
which is a message id string and one which is an application specific string.


Original description

I am trying to use Qpid JMS client to send a message to a non-JMS application 
which returns a message to the client based on the request's reply-to property.
In order to correlate the response received from the non-JMS app with the 
request, I want to use the incoming message's JMSCorrelationID property.
The non-JMS application simply takes the incoming message's message-id property 
and puts it into the outgoing response's correlation-id property.

However, when I send a message using Qpid JMS with default configuration, e.g. 
using a connection URI like {{amqp://myhost:myport}}, then the message ID of 
the sent message retrieved via {{Message.getJMSMessageId()}} looks something 
like {{ID:aef45f-...}} and the message-id of the incoming request in the 
non-JMS app contains the same ID, i.e. {{ID:aef45f-...}}. However, the 
correlation ID retrieved from the response via 
{{Message.getJMSCorrelationId()}} at the JMS client starts with 
{{ID:ID:aef45f-...}}, i.e. having a duplicate _ID:_ prefix, and thus cannot be 
matched to the original message ID.

I have tracked down the problem to the inconsistent implementation of 
{{AmqpJmsMessageFacade}}'s {{getMessageId()}} and {{getCorrelationId()}} 
methods. The former only adds an _ID:_ prefix to the underlying message ID if 
it doesn't already contain that prefix whereas the latter always adds the 
prefix (unless the {{x-opt-app-correlation-id}} header is set).

The problem can be worked around by explicitly setting another connection ID 
prefix using the {{jms.connectionIDPrefix}} connection URI parameter ni order 
to define a different prefix than the default one (_ID_).

  was:
I am trying to use Qpid JMS client to send a message to a non-JMS application 
which returns a message to the client based on the request's reply-to property.
In order to correlate the response received from the non-JMS app with the 
request, I want to use the incoming message's JMSCorrelationID property.
The non-JMS application simply takes the incoming message's message-id property 
and puts it into the outgoing response's correlation-id property.

However, when I send a message using Qpid JMS with default configuration, e.g. 
using a connection URI like {{amqp://myhost:myport}}, then the message ID of 
the sent message retrieved via {{Message.getJMSMessageId()}} looks something 
like {{ID:aef45f-...}} and the message-id of the incoming request in the 
non-JMS app contains the same ID, i.e. {{ID:aef45f-...}}. However, the 
correlation ID retrieved from the response via 
{{Message.getJMSCorrelationId()}} at the JMS client starts with 
{{ID:ID:aef45f-...}}, i.e. having a duplicate _ID:_ prefix, and thus cannot be 
matched to the original message ID.

I have tracked down the problem to the inconsistent implementation of 
{{AmqpJmsMessageFacade}}'s {{getMessageId()}} and {{getCorrelationId()}} 
methods. The former only adds an _ID:_ prefix to the underlying 

[jira] [Commented] (QPID-7413) [Java Broker, WMC] Fix minor defects and usability issues in query and dashboard UI

[ASF subversion and git services (JIRA)]

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

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

Commit 1758782 from oru...@apache.org in branch 'java/trunk'
[ https://svn.apache.org/r1758782 ]

QPID-7413: [Java Broker, WMC] Display only name for the principals in 
serialized format

> [Java Broker, WMC] Fix minor defects and usability issues in query and 
> dashboard UI
> ---
>
> Key: QPID-7413
> URL: https://issues.apache.org/jira/browse/QPID-7413
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.0.1
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
> Fix For: qpid-java-6.1
>
>
> # Menu bar - the serialized form of the username in the menu bar looks ugly
> # Menu bar is a muddle of some with icons some with text and some with both.  
> We said all menu titles would have a word and icon.  We said menu entries 
> would not have an icon.
> # Rename Show Xxx Browser => Browse Xx
> # Add explanatory text to the Create Query and Create Dashboard dialogues to 
> help the user understand what scope and category mean.
> # In the save dialogues, the fully qualified name of the group should be 
> visible to the user, perhaps as a hover.
> # A newly cloned query does not warn if it is closed before save has been 
> pressed.
> # Use qpid confirmation dialogue box instead of system confirmation dialogue 
> universally
> # On the Query and Dashboard browsers rename "Mine" to "Created by me"
> # Add the ability select a query from the query browser with the Return key.
> # Add an icon to the "Add Widget" button
> # Add units to the refresh period in the widget customization dialogue
> # Defect:  With a group of HA nodes, create a virtualhost scoped dashboard 
> containing a virtualhost scoped query,   Flip the mastership Expected 
> behaviour - dashboard and widget should be present on the new master.  
> Actual: dashboard was present but was empty.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPID-7413) [Java Broker, WMC] Fix minor defects and usability issues in query and dashboard UI

[Lorenz Quack (JIRA)]

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

Lorenz Quack commented on QPID-7413:


Tested in Firefox:
* Opening the "Broker Manual" results in a JavaScript error: {{newWindow is 
null}} in {{ConsoleHelper.js:45}}
* The description of scope and category in the Dashboard/Query create dialogue 
is very terse and seems to be more in terms of implementation than in user 
related terms.
* The Query create dialogue still has the pointless notification icon and text 
which IMHO serves no purpose.
* The Dashboard/Query Browser has no hover for the table cells which we need in 
case the columns are to narrow to display the full information.
* "Use qpid confirmation dialogue box instead of system confirmation dialogue 
universally" There are still places in the WMC (unrelated to Query and 
Dashboard) using confirm. Should this be addressed here or a JIRA raised?


> [Java Broker, WMC] Fix minor defects and usability issues in query and 
> dashboard UI
> ---
>
> Key: QPID-7413
> URL: https://issues.apache.org/jira/browse/QPID-7413
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.0.1
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
> Fix For: qpid-java-6.1
>
>
> # Menu bar - the serialized form of the username in the menu bar looks ugly
> # Menu bar is a muddle of some with icons some with text and some with both.  
> We said all menu titles would have a word and icon.  We said menu entries 
> would not have an icon.
> # Rename Show Xxx Browser => Browse Xx
> # Add explanatory text to the Create Query and Create Dashboard dialogues to 
> help the user understand what scope and category mean.
> # In the save dialogues, the fully qualified name of the group should be 
> visible to the user, perhaps as a hover.
> # A newly cloned query does not warn if it is closed before save has been 
> pressed.
> # Use qpid confirmation dialogue box instead of system confirmation dialogue 
> universally
> # On the Query and Dashboard browsers rename "Mine" to "Created by me"
> # Add the ability select a query from the query browser with the Return key.
> # Add an icon to the "Add Widget" button
> # Add units to the refresh period in the widget customization dialogue
> # Defect:  With a group of HA nodes, create a virtualhost scoped dashboard 
> containing a virtualhost scoped query,   Flip the mastership Expected 
> behaviour - dashboard and widget should be present on the new master.  
> Actual: dashboard was present but was empty.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPID-7413) [Java Broker, WMC] Fix minor defects and usability issues in query and dashboard UI

[ASF subversion and git services (JIRA)]

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

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

Commit 1758772 from oru...@apache.org in branch 'java/trunk'
[ https://svn.apache.org/r1758772 ]

QPID-7413: [Java Broker, WMC] Reuse PreferenceSaveDialogContent for saving of 
queries and delete dedicated query saving widget

> [Java Broker, WMC] Fix minor defects and usability issues in query and 
> dashboard UI
> ---
>
> Key: QPID-7413
> URL: https://issues.apache.org/jira/browse/QPID-7413
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.0.1
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
> Fix For: qpid-java-6.1
>
>
> # Menu bar - the serialized form of the username in the menu bar looks ugly
> # Menu bar is a muddle of some with icons some with text and some with both.  
> We said all menu titles would have a word and icon.  We said menu entries 
> would not have an icon.
> # Rename Show Xxx Browser => Browse Xx
> # Add explanatory text to the Create Query and Create Dashboard dialogues to 
> help the user understand what scope and category mean.
> # In the save dialogues, the fully qualified name of the group should be 
> visible to the user, perhaps as a hover.
> # A newly cloned query does not warn if it is closed before save has been 
> pressed.
> # Use qpid confirmation dialogue box instead of system confirmation dialogue 
> universally
> # On the Query and Dashboard browsers rename "Mine" to "Created by me"
> # Add the ability select a query from the query browser with the Return key.
> # Add an icon to the "Add Widget" button
> # Add units to the refresh period in the widget customization dialogue
> # Defect:  With a group of HA nodes, create a virtualhost scoped dashboard 
> containing a virtualhost scoped query,   Flip the mastership Expected 
> behaviour - dashboard and widget should be present on the new master.  
> Actual: dashboard was present but was empty.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (QPID-6894) [Java Broker] VirtualHostNode of type REDIRECTOR cannot be stopped through web UI

[Lorenz Quack (JIRA)]

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

Lorenz Quack resolved QPID-6894.

Resolution: Fixed

Yes, it seems this was resolved. Can no longer reproduce.

> [Java Broker] VirtualHostNode of type REDIRECTOR cannot be stopped through 
> web UI
> -
>
> Key: QPID-6894
> URL: https://issues.apache.org/jira/browse/QPID-6894
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
> Environment: Internet Explorer
>Reporter: Lorenz Quack
>Assignee: Lorenz Quack
> Fix For: qpid-java-6.1
>
>
> clicking on the stop button has seemingly no effect.
> Also the associated VirtualHost is shown as UNAVAILABLE



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (DISPATCH-493) Add a way to request the number of log entries per module

[Ernest Allen (JIRA)]

Ernest Allen created DISPATCH-493:
-

 Summary: Add a way to request the number of log entries per module
 Key: DISPATCH-493
 URL: https://issues.apache.org/jira/browse/DISPATCH-493
 Project: Qpid Dispatch
  Issue Type: Improvement
  Components: Management Agent
Reporter: Ernest Allen
Priority: Minor


The console is displaying a log summary page that shows the number of log 
entries per module. Currently it is using the GET-LOG method to get all logs 
and then count for each module.

It would be more efficient if there was a way to get only the count of log 
messages for each module in a single request. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (DISPATCH-492) Add a way to request logs for a specific module

[Ernest Allen (JIRA)]

Ernest Allen created DISPATCH-492:
-

 Summary: Add a way to request logs for a specific module
 Key: DISPATCH-492
 URL: https://issues.apache.org/jira/browse/DISPATCH-492
 Project: Qpid Dispatch
  Issue Type: Improvement
  Components: Management Agent
Reporter: Ernest Allen


The current GET-LOGS method returns log entries from all module types. 
The console is then filtering the returned list to get only the entries for a 
specific module (like log/ERROR, log/AGENT, etc.) 

It would be more efficient to have a way to specify which module's logs are 
needed and return only those.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPID-7412) [Java Broker] Set default max message size to 100 MB

[ASF subversion and git services (JIRA)]

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

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

Commit 1758768 from [~lorenz.quack] in branch 'java/branches/6.0.x'
[ https://svn.apache.org/r1758768 ]

QPID-7412: [Java Broker] Set default max message size to 100 MB

merged from trunk via:
$ svn merge -c 1758766 ^/qpid/java/trunk

variable moved from AMQPPort to Connection

> [Java Broker] Set default max message size to 100 MB
> 
>
> Key: QPID-7412
> URL: https://issues.apache.org/jira/browse/QPID-7412
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Lorenz Quack
>Priority: Trivial
> Fix For: qpid-java-6.1, qpid-java-6.0.5
>
>
> {{Connection#DEFAULT_MAX_MESSAGE_SIZE}} is currently set to {{0x1f4}} 
> which is approx 32 MB. The intent was to set it to 500 MB which is 
> {{0x1f40}}
> New intent is 100 MB (see below comment)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPID-7412) [Java Broker] Set default max message size to 100 MB

[ASF subversion and git services (JIRA)]

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

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

Commit 1758766 from [~lorenz.quack] in branch 'java/trunk'
[ https://svn.apache.org/r1758766 ]

QPID-7412: [Java Broker] Set default max message size to 100 MB

> [Java Broker] Set default max message size to 100 MB
> 
>
> Key: QPID-7412
> URL: https://issues.apache.org/jira/browse/QPID-7412
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Lorenz Quack
>Priority: Trivial
> Fix For: qpid-java-6.1, qpid-java-6.0.5
>
>
> {{Connection#DEFAULT_MAX_MESSAGE_SIZE}} is currently set to {{0x1f4}} 
> which is approx 32 MB. The intent was to set it to 500 MB which is 
> {{0x1f40}}
> New intent is 100 MB (see below comment)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (QPID-7412) [Java Broker] Set default max message size to 100 MB

[Lorenz Quack (JIRA)]

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

Lorenz Quack updated QPID-7412:
---
Description: 
{{Connection#DEFAULT_MAX_MESSAGE_SIZE}} is currently set to {{0x1f4}} which 
is approx 32 MB. The intent was to set it to 500 MB which is {{0x1f40}}

New intent is 100 MB (see below comment)

  was:{{Connection#DEFAULT_MAX_MESSAGE_SIZE}} is currently set to {{0x1f4}} 
which is approx 32 MB. The intent was to set it to 500 MB which is 
{{0x1f40}}


> [Java Broker] Set default max message size to 100 MB
> 
>
> Key: QPID-7412
> URL: https://issues.apache.org/jira/browse/QPID-7412
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Lorenz Quack
>Priority: Trivial
> Fix For: qpid-java-6.1, qpid-java-6.0.5
>
>
> {{Connection#DEFAULT_MAX_MESSAGE_SIZE}} is currently set to {{0x1f4}} 
> which is approx 32 MB. The intent was to set it to 500 MB which is 
> {{0x1f40}}
> New intent is 100 MB (see below comment)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPID-7412) [Java Broker] Set default max message size to 500 MB

[Lorenz Quack (JIRA)]

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

Lorenz Quack commented on QPID-7412:


After discussion it was decided to lower the default max message size to 100 MB 
to avoid the broker running OOM when running with default heap configuration of 
512 MB.


> [Java Broker] Set default max message size to 500 MB
> 
>
> Key: QPID-7412
> URL: https://issues.apache.org/jira/browse/QPID-7412
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Lorenz Quack
>Priority: Trivial
> Fix For: qpid-java-6.1, qpid-java-6.0.5
>
>
> {{Connection#DEFAULT_MAX_MESSAGE_SIZE}} is currently set to {{0x1f4}} 
> which is approx 32 MB. The intent was to set it to 500 MB which is 
> {{0x1f40}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (QPID-7412) [Java Broker] Set default max message size to 100 MB

[Lorenz Quack (JIRA)]

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

Lorenz Quack updated QPID-7412:
---
Summary: [Java Broker] Set default max message size to 100 MB  (was: [Java 
Broker] Set default max message size to 500 MB)

> [Java Broker] Set default max message size to 100 MB
> 
>
> Key: QPID-7412
> URL: https://issues.apache.org/jira/browse/QPID-7412
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Lorenz Quack
>Priority: Trivial
> Fix For: qpid-java-6.1, qpid-java-6.0.5
>
>
> {{Connection#DEFAULT_MAX_MESSAGE_SIZE}} is currently set to {{0x1f4}} 
> which is approx 32 MB. The intent was to set it to 500 MB which is 
> {{0x1f40}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Dispute of CVSS Score for CVE-2016-4974

[Lorenz Quack]

Dear Madam or Sir,

I would like to dispute the CVSS score of CVE-2016-4974 [1].

Upon our request the MITRE description [2] was recently changed
to more accurately describe the circumstances under which this
vulnerability can be exploited.  The original description read:

Apache Qpid AMQP 0-x JMS client before 6.0.4 and JMS (AMQP
1.0) before 0.10.0 does not restrict the use of classes
available on the classpath, which might allow remote
attackers to deserialize arbitrary objects and execute
arbitrary code by leveraging a crafted serialized object in a
JMS ObjectMessage that is handled by the getObject function.

This has been changed in the following way:

[...] which might allow remote authenticated users with
permission to send messages to deserialize arbitrary objects
[...]

I can see that this change is already reflected in the NVD
database.  However, the CVSS severity score has not been
adjusted.

Our impression is that the current high rating is mainly due to
the misunderstanding that this vulnerability could be exploited
by a unauthenticated remote attacker which is not correct. To
exploit the vulnerability the following conditions need to be
met:

 * The attacker needs authorization to send messages to the
   target system.

 * The target application needs to call getObject() on the
   received JMS message.

 * The target application needs to have additional exploitable
   classes (e.g., Apache Commons Collections [3]) on the JVM
   classpath.

For reference, Red Hat's CVVSv3 severity assessment [4] resulted
in a score of 5.6, whereas NVD's assessment [1] resulted in a
score of 9.8.

Please let me know if you require further information to consider
changing the CVSS score.


Kind regards,

Lorenz Quack
on behalf of the Apache Qpid Project Management Committee


[1] https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-4974
[2] https://cve.mitre.org/cgi-bin/cvename.cgi?name=2016-4974
[3] https://issues.apache.org/jira/browse/COLLECTIONS-580
[4] https://access.redhat.com/security/cve/CVE-2016-4974



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

[jira] [Closed] (PROTON-612) [proton-j] SslEngineFacadeFactory causes warnings to be logged due to optional dependency not being present, even when it isnt required

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell closed PROTON-612.
-
Resolution: Done

Prior refactoring may have already stopped this happening, but if not then 
PROTON-1224 will as it changes how the loading is handled and removes the 
logging in question.

> [proton-j] SslEngineFacadeFactory causes warnings to be logged due to 
> optional dependency not being present, even when it isnt required
> ---
>
> Key: PROTON-612
> URL: https://issues.apache.org/jira/browse/PROTON-612
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.7
>Reporter: Robbie Gemmell
>
> When using Messenger (e.g the send/recv examples), and when running some of 
> the tests, message can be seen getting logged warnings that the 
> SslEngineFacadeFactory has been unable to load certain classes, because the 
> BouncyCastle dependency isn't present. This occurs despite the dependency 
> being optional, and SSL not actually being used at the time.
> {noformat}
> Jun 20, 2014 3:31:11 PM 
> org.apache.qpid.proton.engine.impl.ssl.SslEngineFacadeFactory getClass
> WARNING: unable to load org.bouncycastle.openssl.PEMReader
> Jun 20, 2014 3:31:11 PM 
> org.apache.qpid.proton.engine.impl.ssl.SslEngineFacadeFactory getClass
> WARNING: unable to load org.bouncycastle.openssl.PasswordFinder
> Jun 20, 2014 3:31:11 PM 
> org.apache.qpid.proton.engine.impl.ssl.SslEngineFacadeFactory 
> WARNING: unable to load bouncycastle provider
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (QPID-7401) [Java Broker] Ensure getContextValue is only called after model has been resolved

[Keith Wall (JIRA)]

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

Keith Wall resolved QPID-7401.
--
Resolution: Fixed

> [Java Broker] Ensure getContextValue is only called after model has been 
> resolved
> -
>
> Key: QPID-7401
> URL: https://issues.apache.org/jira/browse/QPID-7401
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Lorenz Quack
> Fix For: qpid-java-6.1
>
>
> Currently in a couple of places we call getContextValue before the model is 
> fully resolved (e.g., in constructors or field initialisations). This means 
> values will not be interpolated correctly.
> We should ensure that context variables are looked up after the model is 
> resolved (e.g., in onOpen or similar).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPID-7401) [Java Broker] Ensure getContextValue is only called after model has been resolved

[Keith Wall (JIRA)]

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

Keith Wall commented on QPID-7401:
--

Changes look reasonable to me.

> [Java Broker] Ensure getContextValue is only called after model has been 
> resolved
> -
>
> Key: QPID-7401
> URL: https://issues.apache.org/jira/browse/QPID-7401
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Lorenz Quack
> Fix For: qpid-java-6.1
>
>
> Currently in a couple of places we call getContextValue before the model is 
> fully resolved (e.g., in constructors or field initialisations). This means 
> values will not be interpolated correctly.
> We should ensure that context variables are looked up after the model is 
> resolved (e.g., in onOpen or similar).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Closed] (PROTON-1271) 0.14.0 release tasks

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell closed PROTON-1271.
--
Resolution: Fixed

> 0.14.0 release tasks
> 
>
> Key: PROTON-1271
> URL: https://issues.apache.org/jira/browse/PROTON-1271
> Project: Qpid Proton
>  Issue Type: Task
>  Components: release
>Reporter: Justin Ross
>Assignee: Justin Ross
> Fix For: 0.14.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (PROTON-1259) c: libuv multi-threaded example driver.

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell updated PROTON-1259:
---
Fix Version/s: (was: 0.14.0)
   0.15.0

This doesn't seem to have anything in 0.14.0, so bumping to 0.15.0 fix version.

> c: libuv multi-threaded example driver.
> ---
>
> Key: PROTON-1259
> URL: https://issues.apache.org/jira/browse/PROTON-1259
> Project: Qpid Proton
>  Issue Type: New Feature
>  Components: proton-c
>Affects Versions: 0.12.2
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.15.0
>
>
> Implement a multi-threaded C++ proton::container implementation also built on 
> libuv.  Demonstrate use of the C connection_engine_t to integrate with an 
> external proactive IO library.
> Strucuture:
> - pn_container API to replace reactor (based on C++ container but simplified)
> - pn_container_impl SPI to allow multiple container implementations
> - libuv implementation of pn_container_impl
> - examples baesd on pn_container API, running on libuv (for now, but could 
> run on any container impl)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (PROTON-1224) [proton-j] use newer versions of BouncyCastle

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell resolved PROTON-1224.

Resolution: Fixed

> [proton-j] use newer versions of BouncyCastle
> -
>
> Key: PROTON-1224
> URL: https://issues.apache.org/jira/browse/PROTON-1224
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-j
>Affects Versions: 0.14.0
>Reporter: Jem Day
>Assignee: Robbie Gemmell
> Fix For: 0.15.0
>
>
> The BouncyCastle project deprecated functionality used by the proton-j driver 
> in version 1.48. This causes run-time issues for us as our application 
> containers are using newer BC versions.
> Thanks for you patience with this, hopefully this is now cleaner PR, I have 
> closed the original PR #75
> Jem



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (PROTON-1224) [proton-j] use newer versions of BouncyCastle

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on PROTON-1224:


Github user asfgit closed the pull request at:

https://github.com/apache/qpid-proton/pull/78


> [proton-j] use newer versions of BouncyCastle
> -
>
> Key: PROTON-1224
> URL: https://issues.apache.org/jira/browse/PROTON-1224
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-j
>Affects Versions: 0.14.0
>Reporter: Jem Day
>Assignee: Robbie Gemmell
> Fix For: 0.15.0
>
>
> The BouncyCastle project deprecated functionality used by the proton-j driver 
> in version 1.48. This causes run-time issues for us as our application 
> containers are using newer BC versions.
> Thanks for you patience with this, hopefully this is now cleaner PR, I have 
> closed the original PR #75
> Jem



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (PROTON-1224) [proton-j] use newer versions of BouncyCastle

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on PROTON-1224:


Github user asfgit closed the pull request at:

https://github.com/apache/qpid-proton/pull/79


> [proton-j] use newer versions of BouncyCastle
> -
>
> Key: PROTON-1224
> URL: https://issues.apache.org/jira/browse/PROTON-1224
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-j
>Affects Versions: 0.14.0
>Reporter: Jem Day
>Assignee: Robbie Gemmell
> Fix For: 0.15.0
>
>
> The BouncyCastle project deprecated functionality used by the proton-j driver 
> in version 1.48. This causes run-time issues for us as our application 
> containers are using newer BC versions.
> Thanks for you patience with this, hopefully this is now cleaner PR, I have 
> closed the original PR #75
> Jem



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[GitHub] qpid-proton pull request #78: PROTON-1224: Support newer BouncyCastle Implem...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/qpid-proton/pull/78


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] qpid-proton pull request #79: PROTON-1224: support newer BouncyCastle versio...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/qpid-proton/pull/79


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[jira] [Commented] (PROTON-1224) [proton-j] use newer versions of BouncyCastle

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on PROTON-1224:
-

Commit e4be12a69a753c133975bff0a57ed82af43aa51e in qpid-proton's branch 
refs/heads/master from [~jday]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=e4be12a ]

PROTON-1224: Support newer BouncyCastle Implementations

Support new version of BouncyCastle library via existing reflection
mechanism.
Added Unit-tests


> [proton-j] use newer versions of BouncyCastle
> -
>
> Key: PROTON-1224
> URL: https://issues.apache.org/jira/browse/PROTON-1224
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-j
>Affects Versions: 0.14.0
>Reporter: Jem Day
>Assignee: Robbie Gemmell
> Fix For: 0.15.0
>
>
> The BouncyCastle project deprecated functionality used by the proton-j driver 
> in version 1.48. This causes run-time issues for us as our application 
> containers are using newer BC versions.
> Thanks for you patience with this, hopefully this is now cleaner PR, I have 
> closed the original PR #75
> Jem



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (PROTON-1224) [proton-j] use newer versions of BouncyCastle

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on PROTON-1224:
-

Commit eaa7ea78def295d091e4dc35cfbb30cb148ad9f6 in qpid-proton's branch 
refs/heads/master from Robert Gemmell
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=eaa7ea7 ]

PROTON-1224: rework loading of bouncycastle to ensure failure is detected, but 
suppressed since its optional, and actually reported at the point usage would 
fail. Fix up various whitespace etc issues.


> [proton-j] use newer versions of BouncyCastle
> -
>
> Key: PROTON-1224
> URL: https://issues.apache.org/jira/browse/PROTON-1224
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-j
>Affects Versions: 0.14.0
>Reporter: Jem Day
>Assignee: Robbie Gemmell
> Fix For: 0.15.0
>
>
> The BouncyCastle project deprecated functionality used by the proton-j driver 
> in version 1.48. This causes run-time issues for us as our application 
> containers are using newer BC versions.
> Thanks for you patience with this, hopefully this is now cleaner PR, I have 
> closed the original PR #75
> Jem



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (PROTON-1224) [proton-j] use newer versions of BouncyCastle

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on PROTON-1224:
-

Commit 168dfe946f85b38a4e02db99879bdd636d16e4c6 in qpid-proton's branch 
refs/heads/master from Robert Gemmell
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=168dfe9 ]

PROTON-1224: support using newer versions of bouncycastle.

This closes #78
This closes #79


> [proton-j] use newer versions of BouncyCastle
> -
>
> Key: PROTON-1224
> URL: https://issues.apache.org/jira/browse/PROTON-1224
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-j
>Affects Versions: 0.14.0
>Reporter: Jem Day
>Assignee: Robbie Gemmell
> Fix For: 0.15.0
>
>
> The BouncyCastle project deprecated functionality used by the proton-j driver 
> in version 1.48. This causes run-time issues for us as our application 
> containers are using newer BC versions.
> Thanks for you patience with this, hopefully this is now cleaner PR, I have 
> closed the original PR #75
> Jem



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (PROTON-1224) [proton-j] use newer versions of BouncyCastle

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell updated PROTON-1224:
---
 Assignee: Robbie Gemmell
Affects Version/s: (was: 0.12.2)
   0.14.0
Fix Version/s: 0.15.0
  Summary: [proton-j] use newer versions of BouncyCastle  (was: 
Proton-J SSL uses deprecated Bouncy Castle functionality)

> [proton-j] use newer versions of BouncyCastle
> -
>
> Key: PROTON-1224
> URL: https://issues.apache.org/jira/browse/PROTON-1224
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-j
>Affects Versions: 0.14.0
>Reporter: Jem Day
>Assignee: Robbie Gemmell
> Fix For: 0.15.0
>
>
> The BouncyCastle project deprecated functionality used by the proton-j driver 
> in version 1.48. This causes run-time issues for us as our application 
> containers are using newer BC versions.
> Thanks for you patience with this, hopefully this is now cleaner PR, I have 
> closed the original PR #75
> Jem



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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