[
https://issues.apache.org/jira/browse/QPID-7311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15823081#comment-15823081
]
Keith Wall commented on QPID-7311:
----------------------------------
QPID-7623 captures the general problem you noticed.
On your other comments:
* The certificate downloading in a separate thread benefits the #doActivate
when a _x509Certificate is not already stored. Previously, the configuration
thread would be blocked whilst the certificate was being download. Now other
sibling objects can acquire their desired state whilst this on downloads.
* I did consider changing the semantics of #refreshCertificate so that is
merely requests the refresh, but in the end decided to stick with existing
behaviour.
* I think in the long term long running operations such as this one or, a
better example, Queue#clearQueue, should return a CancellableFutures. These
CancellableFutures should be exposed somehow to management so that operators
can see the long running operations that are in-flight and choose to cancel
them if they wish.
> [Java Broker] SiteSpecificTrustStore does not provide helpful error messages
> when protocol is missing
> -----------------------------------------------------------------------------------------------------
>
> Key: QPID-7311
> URL: https://issues.apache.org/jira/browse/QPID-7311
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
> Reporter: Lorenz Quack
> Assignee: Keith Wall
> Priority: Minor
> Fix For: qpid-java-7.0
>
>
> Currently, when creating a {{SiteSpecificTrustStore}} and the protocol is not
> specified in the URL the object will be created but put into ERRORED state.
> No indication as to what is wrong is given. Furthermore the URL is not
> editable rendering the newly created object utterly useless.
> On the Broker side a MalformedURLException is logged at INFO level giving the
> helpful information "no protocol".
> On the broker side we do not need a full stack trace.
> On the client side a error message would be preferable to creating an ERRORED
> object.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
