Skip to content

Use protected for members in generated service classes - #33919

Open
DhairyasheelS wants to merge 3 commits into
jhipster:mainfrom
DhairyasheelS:protected-service-members
Open

Use protected for members in generated service classes#33919
DhairyasheelS wants to merge 3 commits into
jhipster:mainfrom
DhairyasheelS:protected-service-members

Conversation

@DhairyasheelS

@DhairyasheelS DhairyasheelS commented Jun 27, 2026

Copy link
Copy Markdown

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.

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 jhipster#33715
@DhairyasheelS

Copy link
Copy Markdown
Author

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

…ontainers

The Couchbase Testcontainer reports "started" once its management API is
up, but the KV service can still be warming up on loaded CI runners.
Couchmove's first lock-document read then hits an UnambiguousTimeoutException
(BUCKET_NOT_AVAILABLE), which fails the couchmove bean and takes down the
whole Spring context on the first test, cascading into
"ApplicationContext failure threshold exceeded" errors on every other test
in the class (reproduced locally: Tests run 28, Errors 3 on the
ms-vue-eureka-jwt-couchbase-hazelcast gateway sample).

Add a retry-with-backoff around couchmove.migrate(), a longer container
startup timeout, and looser kv_timeout/connect_timeout on the Couchbase
connection string to cover the warm-up gap.
…to-configured ClusterEnvironment

Spring Boot's Couchbase auto-configuration always builds a
ClusterEnvironment from spring.couchbase.env.* properties, and the SDK
throws IllegalArgumentException ("Can't use a pre-built ClusterEnvironment
with a connection string that has parameters") if the connection string
also carries query params. Set the connect/key-value timeouts via
spring.couchbase.env.timeouts.* dynamic properties instead.

Verified locally: gateway ci:backend:test on ms-vue-eureka-jwt-couchbase-hazelcast
now passes (Tests run: 124, Failures: 0, Errors: 0), where it previously
failed with "ApplicationContext failure threshold exceeded".
@DhairyasheelS

Copy link
Copy Markdown
Author

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

@DhairyasheelS

Copy link
Copy Markdown
Author

Hi @vw98075 @DanielFran !! CI is now fully green , no merge conflicts — let me know if anything else is needed for review.

@DhairyasheelS

Copy link
Copy Markdown
Author

Hi @DanielFran @vw98075 !! CI is now fully green , no merge conflicts — let me know if anything else is needed for review.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Change Private Methods and Private fields to Protected in Generated Java Service Classes

1 participant