qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Godfrey (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (QPID-7563) Implement Virtualhost centric REST interface
Date Tue, 20 Dec 2016 15:24:58 GMT

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

Rob Godfrey commented on QPID-7563:
-----------------------------------

{quote}
* 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.
{quote}
The way to test is to not put the DNS name in the HTTP request, but rather the name you want
to test with, se http://stackoverflow.com/questions/3390549/set-curl-to-use-local-virtual-hosts
for example for how to do this with cURL.
{quote}
* 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?
{quote}
We could, however I'm not sure that in practice this will be very expensive (in general there
will be 0 or 1 aliases I imagine) so I'm dubious as to the benefits of caching
{quote}
* 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
{quote}
Fixed
{quote}
* 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}
{quote}
No - BrokerQueryServlet just deliberately doesn't work through the virtual host view it makes
no sense to talk about a BrokerQuery when you are not allowed to know about the Broker :-)
{quote}
* StructureServlet
** There is a duplicate code for getting children and associated object. The duplicate code
can be moved into a separate method
{quote}
factored out the common code 

> 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: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org


Mime
View raw message