Use protected for members in generated service classes

[DhairyasheelS]

Generated service classes are meant to be extended (e.g. ExtendedFooService extends FooService), but private fields and helper methods prevent clean subclassing. Switch them to protected so the generated services follow the open/closed principle.

Scope is limited to service classes:

• inject_template injected fields become protected, gated by the existing isController flag so REST controllers stay private (they use a parallel @RestController extension pattern, not inheritance)
• UserService fields and helper methods become protected
• updateIfPresent in the entity service implementation becomes protected

Class-level constants (private static final Logger) are left untouched.

Closes #33715

---

Please make sure the below checklist is followed for Pull Requests.

• All continuous integration tests are green
• Tests are added where necessary
• The JDL part is updated if necessary
• jhipster-online is updated if necessary
• Documentation is added/updated where necessary
• Coding Rules & Commit Guidelines as per our CONTRIBUTING.md document are followed
• If AI coding assistants (GitHub Copilot, Claude Code, Cursor, etc.) were used to produce significant parts of this PR, it is disclosed in the description above and credited via a Co-authored-by: trailer in the commit(s)
• I have personally reviewed, understood, and tested the changes — including any AI-generated code

When you are still working on the PR, consider converting it to Draft (below reviewers) and adding skip-ci label, you can still see CI build result at your branch.

[DhairyasheelS]

Hi !! @vw98075 can you trigger CI/CD please? i want to verify all tests

[DhairyasheelS]

Hi @vw98075 @DanielFran !! — the 3 red sample jobs on this PR don't look code-related and I can't re-run them myself. Could you take a look / re-run when you have a moment?

Summary: all 3 failures are Node 24 jobs that crash during generate-sample, before any Java is compiled:

FATAL ERROR: v8::ToLocalChecked Empty MaybeLocal
 node::cjs_lexer::Parse(...)
 cjsPreparseModuleExports (node:internal/modules/esm/translators)
Aborted (core dumped) jhipster.cjs generate-sample ...
Process completed with exit code 134

Exit 134 = SIGABRT — a Node require(esm) native V8 crash, not generated-code behavior.

Evidence it's not this PR's change (private → protected in service templates):

• The generated store microservice compiled and passed tests right before the crash (BUILD SUCCESSFUL, :test green).
• All 3 failures are on Node 24; the require(esm) crash workaround in the sample workflows is only applied to Node 22 (if: startsWith(matrix.node-version, '22')). One Node-24 sample passed, so it's flaky/non-deterministic.
• React's matrix + all monoliths + several microservices are green, exercising the same template paths.

Questions:

1. Could you re-run the 3 failed jobs?
2. Is this a known Node-24 flake, and would it help to extend the require(esm) workaround to Node 24 (separate PR)? Happy to open one if useful.

Thanks!

[DhairyasheelS]

Hi @vw98075 !! 👋

Could you please take a look at the failing checks? I don't believe they are related to the changes in this PR.

Check 1 — Vue / check-vue (Required): This failed in just 3 seconds with a matrix configuration result of "failure" and an empty outputs object. This looks like a transient CI infrastructure issue rather than anything introduced by this PR.

Check 2 — Vue / ms-vue-eureka-jwt-couchbase-hazelcast: The backend integration tests failed because the Couchbase container was unavailable during the test run (BUCKET_NOT_AVAILABLE / UnambiguousTimeoutException). Spring could not load the ApplicationContext because Couchmove timed out trying to acquire DATABASE_CHANGELOG_LOCK. Again, this appears to be a flaky CI/infrastructure issue unrelated to the PR changes (which only add protected modifiers to generated service class members).

Could someone re-run the failed checks or confirm whether these are known flaky tests? Thank you! 🙏

[DhairyasheelS]

hi @vw98075 !! Could you please take a look at the failing checks? I don't believe they are related to the changes in this PR.