Major Description
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.