Skip to content

feat(spring): @EnableStormRepositories for switching on repository scanning#229

Merged
zantvoort merged 1 commit into
mainfrom
feat/enable-storm-repositories
Jul 11, 2026
Merged

feat(spring): @EnableStormRepositories for switching on repository scanning#229
zantvoort merged 1 commit into
mainfrom
feat/enable-storm-repositories

Conversation

@zantvoort

Copy link
Copy Markdown
Collaborator

Registering Storm repositories in plain Spring meant extending RepositoryBeanFactoryPostProcessor and overriding getRepositoryBasePackages(). That works, but it is not how Spring users expect to switch on a data library.

Fixes #201

What's included

  • @EnableStormRepositories(basePackages/basePackageClasses, ormTemplateBeanName, repositoryPrefix) in storm-spring, mirroring @EnableJpaRepositories. Without explicit packages, the annotated class's package is scanned. One annotation serves both language stacks (storm-kotlin-spring depends on storm-spring, so it is one transitive hop away for Kotlin users): the imported registrar binds repositories through the language stack present on the classpath — the Kotlin adapter when storm-kotlin-spring is available, the Java adapter otherwise.
  • Boot behavior: the annotation doubles as the explicit override — its registrar-provided post-processor makes the starter's auto-configured scanning back off through the existing @ConditionalOnMissingBean condition. Starter behavior without the annotation is unchanged.
  • Configuring constructors on both adapters: RepositoryBeanFactoryPostProcessor(basePackages, ormTemplateBeanName, repositoryPrefix) in Java and Kotlin (named/default arguments), so multi-template applications define one bean per repository set instead of one subclass per domain. Subclassing keeps working unchanged.

Verification

  • Full reactor green (13,706 tests).
  • storm-spring: explicit packages, basePackageClasses, prefix bean naming, and default-package scanning through plain AnnotationConfigApplicationContexts.
  • storm-kotlin-spring: the annotation on a Kotlin configuration registers the Kotlin adapter and repositories resolve through the KClass path.
  • Java starter: with the annotation present, AutoConfiguredRepositoryBeanFactoryPostProcessor backs off.

Docs: both language tabs of spring-integration.md lead with the annotation, with the constructor-bean form documented for multi-template setups (Multiple Data Sources section updated to match); CHANGELOG entry covers the annotation and the constructors.

…anning

Registering Storm repositories in plain Spring meant extending
RepositoryBeanFactoryPostProcessor and overriding
getRepositoryBasePackages(). That works, but it is not how Spring users
expect to switch on a data library.

- @EnableStormRepositories(basePackages/basePackageClasses,
  ormTemplateBeanName, repositoryPrefix) in storm-spring, mirroring
  @EnableJpaRepositories; without packages, the annotated class's
  package is scanned. The imported registrar binds repositories through
  the language stack on the classpath: the Kotlin adapter when
  storm-kotlin-spring is present, the Java adapter otherwise.
- In Spring Boot the annotation doubles as the explicit override: the
  registrar-provided post-processor makes the starter's auto-configured
  scanning back off. Starter behavior without the annotation is
  unchanged.
- The RepositoryBeanFactoryPostProcessor adapters gain configuring
  constructors (basePackages, ormTemplateBeanName, repositoryPrefix),
  so multi-template applications define one bean per repository set
  instead of one subclass per domain.

Fixes #201
@zantvoort zantvoort merged commit e637a87 into main Jul 11, 2026
7 checks passed
@zantvoort zantvoort deleted the feat/enable-storm-repositories branch July 11, 2026 20:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add @EnableStormRepositories for plain Spring setups

1 participant