[
https://issues.apache.org/jira/browse/QPID-7496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15670926#comment-15670926
]
Alex Rudyy commented on QPID-7496:
----------------------------------
I reviewed the changes committed against this JIRA. In general they look good.
They improve and simplify the API of Virtual Host.
However, I have couple questions and comments about minor improvements which
can be made. Here they are:
* It looks like, at the moment, ConnectionValidators can only be used on
instances of QueueManagingVirtualHost(at least those extending
AbstractVirtualHost).
Theoretically RedirectingVirtualHost and BDBReplicaVH can also validate the
connections and even deny old client versions immediately, rather than
redirecting them to VH where they can be denied after redirect. If connection
validation can only happen on QueueManagingVirtualHost, than the type of
virtual host parameter in ConnectionValidator#validateConnectionCreation()
should be changed to QueueManagingVirtualHost. Otheriwse,
RedirectingVirtualHost and BDBReplicaVH might need to have attributes to
configure ConnectionValidators and corresponding implementation for execution
of ConnectionValidators. I am not sure what approach should be taken at the
moment.
* VirtualHost interface re-declared "getMessageStore" method which is already
defined on NamedAddressSpace (extended by VirtualHost). It looks like a
redundant declaration to me.
* VirtualHost#getBroker() is only called from
ConnectionVersionValidator#validateConnectionCreation() to get EventLogger. I
am wondering whether we really need this method on VirtualHost interface.
Perhaps, it can be simply replaced by getEventLogger. If
ConnectionValidator#validateConnectionCreation() is changed to only support
virtual host of type QueueManagingVirtualHost, then neither getBroker or
getEventLogger are required to be present on VirtualHost interface.
* VirtualHost extends NamedAddressSpace. Some methods there (like
getMessageStore, registerConnection, deregisterConnection, createMessageSource,
createMessageDestination, etc) are not really applicable to
RedirectingVirtualHost or BDBReplicaVH. It seems that NamedAddressSpace could
be refactored further to only include common methods between standard and
non-standard virtual hosts. I am not sure that this refactoring in the scope of
this JIRA but it seems it could be performed as part of this JIRA.
> [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]
