[fix][fn] Fix JavaInstanceStarter inferring type class name error

[jiangpengcheng]

Fixes #19885

Master Issue: #xyz

PIP: #xyz

Motivation

JavaInstanceStarter still cannot infer type class name

Modifications

1. create a new FunctionCacheManager in JavaInstanceStarter to create the function class loader and pass this fnCache to ThreadRuntimeFactory's constructor method.
2. create a new constructor method for ThreadRuntimeFactory, which add a fnCache parameter so that it can reuse the fnCache created in JavaInstanceStarter
3. make ThreadRuntime#loadJars public so it can be called in the JavaInstanceStarter
4. use the function class loader to infer type class instead of the instance class loader(which cannot load the user's function class)
5. check whether userConfigs is null before calling userConfigs.containsKey
6. use functionDetailsBuilder.getSink().getClassName() to load sink class instead of functionDetailsBuilder.getClassName() since this one is always org.apache.pulsar.functions.api.utils.IdentityFunction
7. use functionDetailsBuilder.getSource().getClassName(), classLoader to load source class instead of functionDetailsBuilder.getClassName() since this one is always org.apache.pulsar.functions.api.utils.IdentityFunction

Verifying this change

• Make sure that the change passes the CI checks.

(Please pick either of the following options)

• This change is a trivial rework / code cleanup without any test coverage.

(or)

This change is already covered by existing tests, such as (please describe tests).

(or)

This change added tests and can be verified as follows:

(example:)

• Added integration tests for end-to-end deployment with large payloads (10MB)
• Extended integration test for recovery after broker failure

Does this pull request potentially affect one of the following parts:

If the box was checked, please highlight the changes

• Dependencies (add or upgrade a dependency)
• The public API
• The schema
• The default values of configurations
• The threading model
• The binary protocol
• The REST endpoints
• The admin CLI options
• The metrics
• Anything that affects deployment

Documentation

• doc
• doc-required
• doc-not-needed
• doc-complete

Matching PR in forked repository

PR in forked repository: jiangpengcheng#7

[nlu90]

@jiangpengcheng Could you add more details for the actual modifications you made in this PR?

[jiangpengcheng]

@jiangpengcheng Could you add more details for the actual modifications you made in this PR?

Sure, Updated

[jiangpengcheng]

/pulsarbot rerun-failure-checks

[codecov-commenter]

Codecov Report

Merging #19896 (5ff88fb) into master (1e44ba1) will increase coverage by 37.52%.
The diff coverage is 25.00%.

@@              Coverage Diff              @@
##             master   #19896       +/-   ##
=============================================
+ Coverage     24.42%   61.94%   +37.52%     
- Complexity      291     3507     +3216     
=============================================
  Files          1603     1859      +256     
  Lines        124343   136750    +12407     
  Branches      13571    15034     +1463     
=============================================
+ Hits          30369    84709    +54340     
+ Misses        89490    44264    -45226     
- Partials       4484     7777     +3293     

Flag	Coverage Δ
inttests	24.32% <0.00%> (-0.11%)	⬇️
systests	25.11% <25.00%> (?)
unittests	59.24% <12.50%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
.../pulsar/functions/runtime/JavaInstanceStarter.java	0.00% <0.00%> (ø)
...functions/runtime/thread/ThreadRuntimeFactory.java	68.23% <30.00%> (+68.23%)	⬆️
...pulsar/functions/runtime/thread/ThreadRuntime.java	50.40% <100.00%> (+50.39%)	⬆️

... and 1384 files with indirect coverage changes

[github-actions]

The pr had no activity for 30 days, mark with Stale label.