oscerd commented on PR #1927:
URL: 
https://github.com/apache/camel-spring-boot/pull/1927#issuecomment-5581117616

   Good questions, and the second one has a concrete answer that I think turns 
into work.
   
   **Other components exposing an endpoint**
   
   I would draw the line at "who chose the bind address" rather than "does it 
listen". `camel-metrics` and `camel-health` do not open a socket themselves; 
they are SPIs and the runtime's management layer serves them. Components that 
do open one, like platform-http, undertow, jetty or netty-http, take the host 
from the endpoint the route author wrote, or from the application's own 
`server.address`. The user picked that.
   
   What made this starter different is that it injected a *second* listener 
nobody asked for and chose `0.0.0.0` on the user's behalf. By that test it was 
the only case in camel-spring-boot: `management.server.port` and 
`management.server.address` appear nowhere else, and the other two 
`EnvironmentPostProcessor` implementations touch no management properties. So I 
would not extend it to the endpoint components.
   
   **Other runtimes**
   
   Here you are right, and both siblings still have the old behaviour.
   
   `camel-quarkus`, 
`extensions/observability-services/runtime/src/main/resources/application.properties`
 on current main:
   
   ```properties
   quarkus.management.enabled=true
   quarkus.management.port=9876
   ```
   
   There is no `quarkus.management.host`, and Quarkus defaults it to `0.0.0.0`. 
That is the same shape as what we just fixed: an injected management listener 
on 9876, reachable from anywhere, that the user never asked to expose.
   
   `camel-main`, `HttpManagementServerConfigurationProperties` on current camel 
main:
   
   ```java
   @Metadata(defaultValue = "0.0.0.0")
   private String host = "0.0.0.0";
   @Metadata(defaultValue = "8080")
   private int port = 8080;
   ```
   
   serving `/observe/info`, `/observe/health` and `/observe/jolokia`. That one 
is arguably wider than the Spring Boot case, because the same server can also 
carry the dev console, upload, download and send, several of which already 
carry `@Metadata(security = "insecure:dev")` — so we already treat them as 
sensitive, we just do not bind them anywhere safe by default.
   
   So after this PR the three runtimes disagree: Spring Boot binds loopback, 
Quarkus and Main bind all interfaces, for the same `/observe/*` surface. Given 
that harmonised defaults are the whole point of `camel-observability-services`, 
that seems worth fixing rather than leaving.
   
   Happy to open the two follow-up issues if you and @Croway agree that is the 
right direction, or to leave them to whoever owns those runtimes.
   
   _Comment by Claude Code on behalf of Andrea Cosentino._


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to