Skip to content

Callback interfaces such as LoadTimeWeaverAware should allow for local overriding [SPR-13892] #18466

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
spring-projects-issues opened this issue Jan 26, 2016 · 4 comments
Labels
status: bulk-closed An outdated, unresolved issue that's closed in bulk as part of a cleaning process

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Jan 26, 2016

Andrei Ivanov opened SPR-13892 and commented

Trying to inject a custom LoadTimeWeaver into a LoadTimeWeaverAware fails, as it initially gets injected but then the LoadTimeWeaverAwareProcessor comes along and injects the default loadTimeWeaver.

<context:load-time-weaver />

<bean class="org.springframework.orm.jpa.persistenceunit.DefaultPersistenceUnitManager">
	<property name="defaultPersistenceUnitName" value="compositePU" />
	<property name="packagesToScan">
		<list>
			<value>com.test.module1.entity</value>
			<value>com.test.module2.entity</value>
		</list>
	</property>
	<property name="properties">
		<props>
			<prop key="eclipselink.composite-unit">true</prop>
		</props>
	</property>
	<property name="loadTimeWeaver">
		<bean class="CustomLoadTimeWeaver" />
	</property>
</bean>

Affects: 4.2.4

Issue Links:

0 votes, 5 watchers

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

This is so far by design: You can either populate such a setter manually or set up a context-wide reference, not both at the same time. If there is a context-wide LoadTimeWeaver to share, it actually takes precedence. This is the same for other *Aware interfaces.

In your case, you'd have to set up your "loadTimeWeaver" bean as your custom class manually, instead of using <context:load-time-weaver>.

@spring-projects-issues
Copy link
Collaborator Author

Andrei Ivanov commented

Hm, I think it's a bit unfortunate.
I would consider the context-wide reference to be the default when there isn't a specific reference specified.
That would also work with the convention over configuration principle as well.

If I have a lot of beans using the default weaver and just one that needs a special weaver it means I have to manually set them all instead of just that one bean (in this case, a specific weaver for JPA) :(
And I don't even know what other infrastructure beans I might have that require the default weaver.

@spring-projects-issues
Copy link
Collaborator Author

Andrei Ivanov commented

Any chance to turn this into a more generic improvement request regarding local overriding of injected properties by post-processors? :)

@spring-projects-issues spring-projects-issues added status: waiting-for-triage An issue we've not yet triaged or decided on type: enhancement A general enhancement and removed type: enhancement A general enhancement labels Jan 11, 2019
@rstoyanchev rstoyanchev added status: bulk-closed An outdated, unresolved issue that's closed in bulk as part of a cleaning process and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels Jan 11, 2019
@spring-projects-issues
Copy link
Collaborator Author

Bulk closing outdated, unresolved issues. Please, reopen if still relevant.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: bulk-closed An outdated, unresolved issue that's closed in bulk as part of a cleaning process
Projects
None yet
Development

No branches or pull requests

2 participants