search

line / armeria

Your go-to microservice framework for any situation, from the creator of Netty et al. You can build any type of microservice leveraging your favorite technologies, including gRPC, Thrift, Kotlin, Retrofit, Reactive Streams, Spring Boot and Dropwizard.
https://armeria.dev
Apache License 2.0
4.83k stars 922 forks source link

Spring ArmeriaAutoConfiguration could look at spring server settings too #1834

Open anuraaga opened 5 years ago

anuraaga commented 5 years ago

Many of the knobs for controlling an armeria server using spring integration are under the armeria configuration namespace, often to give more flexibility to configure armeria (e.g., ports). But to make migrating an existing Spring server to armeria simpler, does it make sense to fallback to also looking at server configuration.

Reference: https://github.com/apache/incubator-zipkin/issues/2627

anuraaga commented 5 years ago

/cc @adriancole

trustin commented 5 years ago

I think it's doable if we set clear policy on what to do when a user specifies both server and armeria section. So far, we did not look into the server section because of ambiguity IIRC. Am I correct, @hyangtack ?

hyangtack commented 5 years ago

Yes, it would be possible, but I didn't do it because of the ambiguity between Spring Boot 2.x and 1.x, e.g. different package name, different class type for data unit, etc. However, I didn't look into it deeply at that time, so it'd be possible to find a simple way to do it. :-)

codefromthecrypt commented 5 years ago

agree that doing this implies maintenance when spring boot minor and major versions come out.

trustin commented 5 years ago

@adriancole wrote:

ex ideal world is I can paste something like this and no-one is the wiser that armeria is even in use. While it is nice that it is, for some beginners it won't do anything except confuse to speak at this abstraction https://www.baeldung.com/spring-boot-https-self-signed-certificate

(Copied from a Slack thread)

minwoox commented 3 years ago

We can start this by making AbstractArmeriaAutoConfiguration (with a different name) to extend AbstractConfigurableWebServerFactory. Currently, it's not possible because AbstractArmeriaAutoConfiguration is used for boot1 and boot2. We need to extract the common logic to a utility class and use them together in boot1 and boot2.