[
https://issues.apache.org/jira/browse/QPID-7563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15764316#comment-15764316
]
Alex Rudyy commented on QPID-7563:
----------------------------------
I reviewed the changes. The changes in general look good to me with some minor
comments below:
* The current implementation for VH centric REST API depends on external
configuration like DNS sub domain being configured. Thus, it could be difficult
to test it in a restricted environment where the privileges to configure
sub-domain are not available. Perhaps, adding an alternative way (not
dependning from external settings) to configure VH centric REST API would be
benefitial for testing use cases and local testing. For example, an http header
can be used to define the root name, or, root object can be saved in session
with special root selection service and used by the rest of REST servlets. It
seem that root name extraction can be encapsulated into special factory which
can be configured on HttpManagement rather then having it hardcoded as
{{request.getServerName()}}. That would make the solution easy testable.
* AbstractServlet
** Alias pattern matching is evaluated for every request. Would it be better to
cache the root object in session and invoke Port#getAddressSpace only when root
is not found in session?
* ApiDocsServlet
** doGet (old name doGetWithSubjectAndActor)
The "latest/" is added into category url link by default. Thus, when user
willcall the api doc servlet using
http://default.localhost:8080/apidocs/latest/ the link will be built
incorrectly. I think that "latest/" should be added into link only when
servletPathParts.length == 2. If version is specified (/apidocs/v6.1/) the
generated links are broken. Perhaps, request.getPathInfo() or
HttpManagementUtil.getPathInfoElements would be easier to use here.
** writeCategoryDescription
it does not need hierarchy parameter
* BrokerQueryServlet
** In VH root: VH query fails with : Invalid path
I think that getParent was meant to be implemented as
{code}
protected Broker<?> getParent(final HttpServletRequest request, final
ConfiguredObject<?> managedObject)
{
return managedObject instanceof Broker ? (Broker)managedObject :
HttpManagementUtil.getBroker(request.getServletContext()) ;
}
{code}
* StructureServlet
** There is a duplicate code for getting children and associated object. The
duplicate code can be moved into a separate method
> Implement Virtualhost centric REST interface
> --------------------------------------------
>
> Key: QPID-7563
> URL: https://issues.apache.org/jira/browse/QPID-7563
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
> Affects Versions: qpid-java-6.2
> Reporter: Keith Wall
> Assignee: Rob Godfrey
> Fix For: qpid-java-6.2
>
>
> For use-cases where the Broker to hosts a shared service where different
> applications are assigned to be different virtual hosts the broker should
> offer the ability to manage these virtualhosts independently. It should
> behave as if it were a chrooted prison.
> AMQP Management already offers this ability. The HTTP management interface
> should change to offer the same thing.
> The REST API of a virtualhost will service the only virtualhost's subtree.
> The formation of the service urls will reflect this structure.
> {{/virtualhost}} will be analogous to {{/broker}} and will service the
> virtualhost root. {{/queue/}} will serve all the queues defined on the
> virtualhost, {{/queue/<queuename>}} will serve only the names queue.
> To offer the virtualhost service, the HTTPPort will be changed to support
> VirtualHostAliases. As with an AMQPPort, with a HostNameAlias, a HTTP port
> will be capable of presenting an interface for any virtualhost whose name
> matches the hostname of the incoming request. A new alias type will support
> a one to one mapping between port and virtualhost interface.
> The scope of the initial work will be the REST API. It would be acceptable
> to leave the other services (SASL, structure, metadata) for a future JIRA.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
