88fantasy opened a new pull request, #4496:
URL: https://github.com/apache/streampark/pull/4496

   ## What is the purpose of the change
   
   Six defects on the path that turns a saved Flink SQL application into a 
submitted job. They are independent of each other, but each one only becomes 
reachable after the previous is fixed, which is why they are together here — 
each was found by submitting a real Flink SQL job to a standalone cluster and 
fixing whatever failed next.
   
   Closes #4483
   Closes #4488
   Closes #4489
   Closes #4490
   
   ## Brief change log
   
   1. **`ClassLoaderUtils.runAsClassLoader` restores the caller's own context 
classloader** (#4489). It previously restored a `static final` field captured 
at class-initialisation time — whichever thread first loaded the class. On 
pooled threads that silently installs an unrelated classloader and leaves it 
there. `ORIGINAL_CLASS_LOADER` stays, since `cloneClassLoader()` still uses it.
   
   2. **`FlinkClientTrait.getCustomCommandLines` and 
`RemoteClient.getStandAloneClusterDescriptor` run under their own class's 
classloader** (#4483). Both call Flink classes bound to the Flink version 
bundled with this module, while the calling thread's context classloader is 
`FlinkShimsProxy`'s target-version shims classloader. Their internal 
`ServiceLoader` lookups therefore resolved providers from a different Flink 
version than the interfaces bundled here, throwing `ServiceConfigurationError: 
... not a subtype`.
   
   3. **Build-response getters carry `@JsonProperty`** (#4488). They do not 
follow JavaBean naming, so Jackson silently omitted them: every persisted build 
result lost `shadedJarPath`/`workspacePath`, and only `pass` appeared to 
survive — by the coincidence that its field default is already `true`. Method 
names are unchanged, so no caller is affected. The K8s and Docker build 
responses had the same defect and are fixed with it.
   
   4. **`SubmitRequest.userJarFile()` tolerates a null `shadedJarPath`** 
instead of passing it to `new File(...)`.
   
   5. **`streampark-console-service` depends on 
`streampark-flink-shims-base-v2`** (#4490), so `FlinkTableInitializerV2` 
reaches the console's `lib/`. Only the v1 module was declared, so every Flink 
2.x SQL job failed with `NoClassDefFoundError`.
   
   6. **`setUserClassPaths` is re-enabled for `FLINK_SQL` jobs only.** It was 
disabled wholesale for #3761, whose reported scenario is a different deploy 
mode; a SQL job needs its connector jars on the client classpath. Every other 
job type keeps the current behaviour.
   
   ## Verifying this change
   
   - Verified by submitting real Flink SQL jobs to a standalone Flink cluster, 
one defect at a time: each fix was built, deployed, and confirmed to make its 
specific failure disappear before the next one was investigated.
   - `ShadedBuildResponse` serialisation was checked by round-tripping it 
through a plain `ObjectMapper` in `jshell` against the built jar — 
`shadedJarPath` is absent from the JSON before the change and present after.
   - `mvn install` over `streampark-common`, `streampark-flink-client-api`, 
`streampark-flink-client-core` and `streampark-flink-packer` passes, 
spotless/checkstyle/scalastyle included.
   
   ## Does this pull request potentially affect one of the following parts
   
   - Dependencies (does it add or upgrade a dependency): **no**
   - The public API: **no** (method names and signatures unchanged; only 
annotations and call-site classloader scoping)
   - The runtime per-record code paths (performance sensitive): **no**
   - Anything that affects deployment: **yes** — 
`streampark-flink-shims-base-v2` is now packaged into the console distribution.
   
   ## Documentation
   
   - Does this pull request introduce a new feature? **no**
   


-- 
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