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

Rob Godfrey commented on QPID-7496:
-----------------------------------

* ConnectionValidators - I don't think it makes sense for 
RedirectingVirtualHost or BDBReplicaHA to perform connection validation - 
basically those sorts of vhosts simply redirect (and validation should be done 
on the destination host) or refuse (in which case there is no point in 
validating first), so changing the interface of ConnectionValidator makes sense.
* getMessageStore() on VirtualHost - agreed will remove
* VirtualHost#getBroker() - I will move to QueueManagingVirtualHost
* NamedAddressSpace - this interface represents the minimum interface currently 
required by an AMQPConnection object.  I factored it out of VirtualHost when I 
introduced the notion of the "synthetic" virtual host "$management" for AMQP 
management.  Rather than removing from the interface, it probably makes more 
sense for both Redirecting and BDBReplica virtual hosts to extend a "non 
connection accepting" virtual host or something, where these methods are 
defined in the base class to throw the appropriate exceptions.  I think if we 
ever create a third similar type this might be worthwhile.  I'm not sure there 
is a huge benefit in doing it right now though.


> [Java Broker] Reduce the implementation burden of creating non-standard 
> virtual hosts
> -------------------------------------------------------------------------------------
>
>                 Key: QPID-7496
>                 URL: https://issues.apache.org/jira/browse/QPID-7496
>             Project: Qpid
>          Issue Type: Improvement
>          Components: Java Broker
>            Reporter: Rob Godfrey
>
> Currently in order to implement a virtual host, many attributes/operations 
> need to be provided.  For non-standard virtual hosts (such as replica virtual 
> hosts, or redirecting virtual hosts) these attributes/operations make no 
> sense.
> We should introduce an interface that represents the "standard" notion of 
> virtual host (one which manages queues/exchanges) and move as much of the 
> implementation burden onto this interface as possible



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

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to