Repository navigation
Conversation
| try { | ||
| legacy = findPort(applicationContext.getAutowireCapableBeanFactory()); | ||
| } catch (ShenyuException e) { | ||
| throw new ShenyuException("can not find port automatically: no embedded web server reported a bound port " |
| try { | ||
| webServerApplicationContextClass = Class.forName(WEB_SERVER_APPLICATION_CONTEXT_CLASS_NAME); | ||
| } catch (ClassNotFoundException e) { | ||
| //spring-boot web classes are not on the classpath: nothing to probe |
There was a problem hiding this comment.
1.catch exception maybe throw??
2.add log error
| return null; | ||
| } | ||
| final Class<?> webServerClass; | ||
| try { |
…istration when server.port=0 PortUtils.findPort reflected getPort() off the web-server factory config bean, so an embedded server started on server.port=0 reported its configured value 0 as the registration port. Discovery now reads the port the owned WebServer actually bound from the client's application context (walking up the parent chain so classic child contexts resolve to their owning server context), keeps the Boot 1.x/2.x factory and JMX external-container fallbacks for external deployments, and fails loudly instead of silently resolving a non-positive port. The client-wide register config now treats a positive advertised port as authoritative and otherwise resolves the bound port, instead of registering a configured 0 verbatim.
…vertised-port hint When no embedded server, no web-server factory bean and no external container connector is available, the context overload surfaced the bare legacy message. Rethrow it with the advertised-port diagnostic and the original cause attached, so operators get the actionable hint on every failure path, and cover it with a regression test.
94bb9bd to
4c3647b
Compare
Review responseThanks @moremind. All three comments are addressed in Long exception message (PortUtils.java:83). The two diagnostics now share one short constant, catch at PortUtils.java:184. I kept returning Two try blocks (PortUtils.java:188). Merged into a single Verification after the rebase: |
Fixes #8426.
PortUtils.findPortdiscovered the registration port by reflectinggetPort()off the web-server factory bean. A factory answers with itsconfigured port, so an embedded server started on
server.port=0— thestandard way to get a random free port — made every listener and the shared
register config register the literal port
0, and the gateway could notroute to the instance. The reflective branch always succeeded, so the
external-container fallback behind it was unreachable in embedded apps.
What changed
PortUtils.findPort(ApplicationContext)(new overload): asks the ownedWebServerfor the port it actually bound, walking up the context parentchain so classic child contexts resolve to their owning server context. A
management context is never in that chain and is never selected, and a
port is only accepted when positive — a factory configured for a random
port without a running owned server no longer resolves to a usable-looking
address. Both spring-boot types are resolved reflectively because
shenyu-client-coredeliberately has no compile-time spring-bootdependency. The legacy chain (Boot 2.x factory reflection, Boot 1.x
factory reflection, JMX external-container probe) is preserved behind it
for external deployments, and failure now raises a diagnostic that points
at the explicit advertised-port property instead of a bare "can not find
port automatically".
SpringMvcClientEventListenerandSpringWebSocketClientEventListeneruse the context overload. A positive advertised port stays authoritative
exactly as before.
ClientRegisterConfigImpl.getPortaligned with the same contract: apositive configured port is authoritative; an absent or non-positive one
resolves the actually bound port instead of registering a configured
0verbatim (previously a presence check, so
port=0leaked intoURIRegisterDTO/MetaDataRegisterDTO/api-doc payloads unchanged — nowire-format change, only the resolved value).
Registration, metadata and api-doc payloads all flow through these two
entry points, so the corrected port feeds every registration artifact;
heartbeat identities already read the bound server port directly
(
WebServerInitializedEvent) and stay consistent with it. A follow-upcommit also makes the total-discovery failure carry the advertised-port
diagnostic on every failure path, covered by a regression test.
Tests
PortUtilsTest(6): a real embedded Tomcat started on port 0 must reportits bound port (red on the old implementation — it reported the
configured 0); a fixed-port server control; child-context → owning server
context walk; a reactive embedded Tomcat (same
WebServerApplicationContextcontract, so Jetty/Undertow are covered by the interface); and
loud-failure instead of a silent zero.
ClientRegisterConfigImplTest(4, new): positive advertised port isauthoritative; configured
0and absent port resolve the bound port (redon the old implementation — errors / silent
0); zero resolution withouta running server fails loudly.
SpringMvcClientEventListenerTest: mocks updated to the context overload;the now-dead
getAutowireCapableBeanFactorystubs removed.Module results on the current master baseline:
shenyu-client-core111,shenyu-client-springmvc41,shenyu-client-spring-websocket29 — allgreen; checkstyle clean per module.
Follow-ups
shenyu-client-javacandidate(migration tracking [Task] Migrate Java client modules to shenyu-client-java with a versioned registration protocol #7602/[Task] Verify independent Java client against main repo admin/bootstrap #6366), as noted in the issue.
HTTP port-discovery path.