[
https://issues.apache.org/jira/browse/HDDS-444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16621660#comment-16621660
]
Elek, Marton commented on HDDS-444:
-----------------------------------
Thanks [~bharatviswa] the question. Yes it was a question for me, too.
I implemented a few API on a very basic level just to give an pattern which
could be followed in the rest of the newbie jira. I don't think if they are
finished, especially as they have no acceptance tests. I created subtasks in
HDDS-434 even for theses endpoints to add all the missing headers and add
acceptance tests.
The other option is to remove these implementation. But 1) they can show an
example how the OzoneClient can be used (with Inject annotation) and 2) it
works well with aws cli, so I prefer to add it.
About the parameters (not sure If I understood the question well.): {volume} is
always a path parameter for us (as of now) this is just because we use the
volume in the endpoint-url:
{code}
aws s3 --endpoint-url http://localhost:9878/vol1 cp docker-config
s3://bucket/qwe/dir1/dir1/file2
{code}
>From aws cli point of view vol1 is not a parameter just part of a random
>endpoint url. But from our point of view this is part of the path so it can be
>used.
Long-term we plan to modify this behaviour to support both path style endpoint
and virtual-host style endpoint. For that this implementation could be changed.
> Add rest service to the s3gateway
> ---------------------------------
>
> Key: HDDS-444
> URL: https://issues.apache.org/jira/browse/HDDS-444
> Project: Hadoop Distributed Data Store
> Issue Type: Sub-task
> Reporter: Elek, Marton
> Assignee: Elek, Marton
> Priority: Major
> Labels: newbie
> Attachments: HDDS-444.001.patch, HDDS-444.002.patch,
> HDDS-444.003.patch
>
>
> The next step is after HDDS-441 is to add a rest server to the s3gateway
> service.
> For the http server the obvious choice is to use
> org.apache.hadoop.http.HttpServer2. We also have a
> org.apache.hadoop.hdds.server.BaseHttpServer which helps to create the
> HttpServer2.
> In hadoop usually the jersey 1.19 is used. I prefer to exclude jersey
> dependency from the s3gateway and add the latest jersey2. Hopefully it also
> could be initialized easily, similar to HttpServer2.addJerseyResourcePackage
> The trickiest part is the resource handling. By default the input parameter
> of the jersey is the JAX-RS resource class and jersey creates new instances
> from the specified resource classes.
> But with this approach we can't inject other components (such as the
> OzoneClient) to the resource classes. In Hadoop usually a singleton is used
> or the reference object is injected to the ServletContext. Both of these are
> just workaround and make the testing harder.
> I propose to use some lightweight managed dependency injection:
> # If we can use and JettyApi to instantiate the resource classes, that would
> be the easiest one.
> # Using a simple CDI framework like dagger, also would help. Dagger is very
> lightweight, it doesn't support request scoped objects just simple @Inject
> annotations, but hopefully we won't need fancy new features.
> # The most complex solution would be to use CDI or Guice. CDI seems to be
> more nature choice for the JAX-RS. It can be checked how easy is to integrate
> Weld to the Jetty + Jersey combo.
> The expected end result of this task is a new HttpServer subcomponent inside
> the s3gateway which could be started/stopped. We need an example simple
> service (for exampe a /health endpoint which returns with an 'OK' string)
> which can demonstrate how our own utilitites (such as OzoneClient) could be
> injected to the REST resources.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
