Spring beans & web behavior
Follow bean recreation, newly added components, MVC callbacks, advice, Jackson and constructor dependency boundaries.
Bean refresh has a lifecycle
After a supported class reload, Spring integration can destroy and recreate affected singletons, clear metadata caches and repair supported direct references. This differs from retaining the original instance after a method-body-only JVM redefinition.
Creation/destruction callbacks can run and mutable state can reset. External holders, local variables, arbitrary nested object graphs, static/final fields and every possible proxy shape are not a universal reference-repair surface.
New components and factory methods
A newly compiled component can register through direct/composed stereotypes using Spring’s name, scope and condition machinery. Singleton/prototype and lazy behavior follow native creation policy. Class-level profiles/conditions are checked at registration time.
This is not a repeat of startup scanning: imports, auto-configuration ordering, custom scan filters, web/custom scopes and scoped proxies remain outside that addition. Previously filtered components are not generally rediscovered by a later property/profile save.
Supported newly added @Bean factories can take reference beans, typed collections/maps, arrays, Optional, providers and direct @Value inputs. Alias names, direct selection metadata, lazy/prototype behavior, profiles and documented direct conditions have bounded support. Existing names are refused; removal only deletes Reclazz-owned registrations.
Lite and full configuration paths differ. Default configuration supports eligible overridable instance factories and container-backed inter-bean calls; static factories keep ordinary Java call semantics. Read the exact allowlist before using composed conditions, custom scopes or proxy shapes.
Endpoints, exception handling and binding
Supported structural controller changes rescan request mappings, including added endpoints. Plain controller/advice adapters can expose added @ExceptionHandler, @InitBinder and @ModelAttribute callbacks even on stock JVMs.
Spring retains handler selection, local priority, advice selectors/order and supported parameter conversion. Ambiguous handler mappings are rejected. Proxied/subclass receivers, inherited/generic/composed shapes, asynchronous/streaming added exception handlers and custom resolvers fall outside their documented adapter scope.
A hidden metadata delegate is visible to the framework. Custom argument/response code that requires the original declaring-class identity needs separate validation. Registered MVC interceptors have a distinct current-singleton routing path; arbitrary interceptor-registry rebuilding is not implied.
Transactions, caching, security and async
Supported added public service methods use the application’s real transaction/cache interceptors. Supported composed transaction/cache metadata and direct or bounded composed pre/post authorization are documented separately. Existing CGLIB references are covered in named tests; arbitrary extra advice shapes are refused.
Added direct public @Async service methods support void, Future and CompletableFuture return paths with the application’s executor/error handling. Method-security metadata and supported existing proxy chains are refreshed. An edited @Aspect pointcut updates supported mutable singleton proxies; a previously unproxied object is a separate limit.
These are scoped adapters, not permission to bypass an unknown proxy. Verify both success and denial/rollback/cache behavior relevant to the edit.
Scheduling, events and lifecycle callbacks
Supported added no-argument void @Scheduled methods register with Spring; later edits replace registrations and removal cancels them. Direct @EventListener additions accept one reference event input and void or one event-object return. Supported transaction/cache and void async combinations have separate allowlists.
Added direct void @TransactionalEventListener methods use Spring’s transaction phases on supported unproxied singletons. Added lifecycle callbacks initialize new instances after injection; each instance retains the added destroy callback it was initialized with through later edits and removal.
Jackson DTO shape changes
Within the documented Spring-managed mapper adapter, added getters, void setters and instance fields participate in JSON output/input on mutable DTOs. Saved annotations, aliases, naming/null rules and serializers/deserializers remain with Jackson. Later saves can rename, remove and restore properties.
Final added fields cannot be written. Constructor/record creators, builders, arbitrary mapper instances and other serializers are not covered by that addition. The native HTTP baseline uses Jackson 2.13.5.
Constructor-captured helper values
The source baseline contains a bounded ordinary helper → constructor-injected leaf-owner transaction, including one measured direct-child context shape. It refreshes supported constructor-captured values and writable singleton holders using native dependency registration.
It requires exact supported factory versions and plain definitions. Aliases, transitive/multiple dependents, proxies, factory products, annotated injection/lifecycle state and arbitrary parent hierarchies are excluded. Synthetic SDK-derived Spring graphs are not a live SAP tenant/cluster acceptance claim. JMS, Kafka and Rabbit have separately measured, bounded consumer transactions. The Rabbit helper/property path is limited to one root context, one plain local helper and leaf owner, one void literal-ID callback and standard native AUTO acknowledgment with nontransacted channels; see the pinned framework versions and exclusions in the technical reference.
Validation and HTTP security metadata
Reloading a constraint annotation alone can leave a provider serving cached validation metadata. The supported Hibernate Validator path clears owned metadata caches and discovers both javax and Jakarta factory names. Check a failing input and a valid control after a constraint edit; a different validator/provider shape needs its own acceptance.
An edited supported security configuration rebuilds its SecurityFilterChain beans and updates the existing FilterChainProxy, retaining inline ignoring chains. A failed rebuild can leave old rules serving, so class reload alone is not evidence that an authorization change is live. Verify allowed and denied requests. This differs from the added service-method security adapter.
Sources & version scope
Documentation source 1.4.0 · evidence baseline 75535bd · reviewed 19 October 2026. Check your installed artifact; source features may postdate a release.