Armeria: Umbrella issue for 1.0.0

[trustin]

• [ ] More per-service settings with fluent route mapping. #1649
  
  
  
  • [x] This revamps the routing and path mapping API to allow a non-annotated service to accept certain methods or media types.
  
  
  • [ ] Related: More convenient decoration #199 (w.r.t specifying multiple decorators)
  
  
  • [x] Provide a way to configure content previewing to the specific service #1619
  
  
  • [ ] HTTP header/parameter-based path mapping #1207
  
  
• [x] Separate messages for AggregatedHttpMessage request / response #1702
• [x] Add a StreamMessage subscription option that notifies cancellation to onError() #1700
• [x] Add boolean shutdownOnStop parameter to ServerBuilder.blockingTaskExecutor() #1685
• [ ] Immutable HttpHeaders and Cookies #1567
• [ ] Make sure all safely retriable exceptions are wrapped by UnprocessedRequestException
  
  
  
  • [x] Change to return UnprocessedRequestException in RetryingClient #1653
  
  
  • [x] Wrap socket connect failures and more with UnprocessedRequestException
  
  
  • [x] Make sure UnprocessedRequestException always has a cause.
  
  
  • [ ] Add a section about UnprocessedRequestException in RetryingClient documentation #1395
  
  
• [ ] Provide a way to build a generic RetryStrategy. #1634
  
  
  
  • This may replace some static factory methods.
  
  
• [ ] Make it more configurable to extract the client IP address behind reverse-proxies #1631
• [x] Decorate a service by path mapping #582
• [ ] Create an abstraction for a LoggingContext containing request properties #1510
• [x] Difficult to request from an absolute URL with HttpClient #1143
• [ ] Provide an extension point in LoggingClient/Service for constructing a log message #1103
  
  
  
  • Do a final review on the current way of message sanitization in LoggingClient/Service. Can we make it any better, especially in terms of performance and flexibility?
  
  
• [ ] EndpointGroup design issues #1084
  
  
  
  • [ ] Disparity between HttpHealthCheckedEndpoint and HttpClient can be confusing. #1913
  
  
  • [ ] HealthCheckedEndpointGroup should probably wait for connectTimeout before throwing exception. #1910
  
  
• [ ] A user may get the wrong RequestContext when contexts are nested #1083
• [ ] Allow resetting the request timeout with the same value #740
• [ ] Revisit the blockingTaskExecutor-related API
  
  
  
  • [ ] Make a blockingTaskExecutor a SchedulerExecutorService. #2269
  
  
  • [ ] Make ServerConfig.blockingTaskExecutor context-aware #46
  
  
• [ ] Revisit ServiceRequestContext.logger(). Do we really need it?
• [ ] Tidy up the API
  
  
  
  • [ ] Remove all deprecated elements
  
  
  • [ ] Check all services and clients with public constructors.
  
  
  • Avoid exposing public constructors; provide a builder and/or factory methods, unless it is very simple.
  
  
• [x] Remove HttpData.offset / length? #1771
• [ ] Provide a utility class for extracting HTTP parameters #1862
  
  
  
  • [ ] Consider multipart request in advance, although we don't need to implement it in 1.0.
  
  
• [ ] Tidy up the build process for backward compatibility
  
  
  
  • [ ] Consider adopting NullAway into the build process #1680
  
  
  • [ ] Fail the build if API compatibility is broken
  
  
• [x] Make sure all examples have a Main class and are runnable from Gradle.
  
  
  
  • [x] :examples:annotated-http-service does not have a main class. #1647
  
  
• [ ] Clear out all remaining discussions
  
  
  
  • [ ] Using 'builder()' factory method instead of constructor #1719
  
  
• [ ] Add new aliases(get|post|head..) for (doGet|doPost|doHead..) methods in AbstractHttpService #1923

[minwoox]

Currently, we use RpcXX classes such as RpcRequest, RpcResponse, RpcService, RpcClient, etc. for Thrift only. Because the name includes Rpc, the users expect that the gRPC module uses the same classes which is not true and they usually end up with a surprise.

I wonder if we have to address this issue which will bring a lot of API changes before 1.0.0. These are some of the ways that I can think of to solve that:

• Rename the RpcXX classes to ThriftXX to distinguish Thrift and gRPC.
  
  
  
  • The easiest way. There are not so many changes except just names.
  
  
• Abstract RpcRequest and RpcResponse use them in Thrift and gRPC together.
  
  
  
  • I'm not even sure if it's possible also if it's a good idea. gRPC uses ClientCall, ServerCall and listener for sending request and receiving response. gRPC supports streaming and Thrift doesn't. Because nature is different, it could harm Armeria and make it worse to use.
  
  
• Just leave it as it is since no one complains about it.

These are just my improvisatory thought and please give an idea if you have. /cc @anuraaga

[trustin]

Consider deprecating *RegistrationBeans in Spring integration module and let users use the configurator which gives the most freedom. WDYT, @imasahiro @kojilin ?

[anuraaga]

I think I originally designed that API internally - and I vaguely recall realizing spring offers both registration beans and customizer ones so thought having both is idiomatic. I haven't used Spring in a long time though so could be misremembering or things could have changed.

[trustin]

Added two more discussion items:

• Using 'builder()' factory method instead of constructor #1719
• ~Renaming newDecorator() to decorator() #1718~

[trustin]

Let me close this issue and set 1.0.0 to milestone for the issues which will affect the API design.

[trustin]

https://github.com/line/armeria/milestone/151