Skip to content
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

@Configurable does not work if method with configured classes as parameter exists [SPR-8502] #13148

Closed
spring-projects-issues opened this issue Jun 30, 2011 · 8 comments
Assignees
Labels
in: core in: test status: invalid

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Jun 30, 2011

Setya Nugroho D opened SPR-8502 and commented

To reproduce the problem, just run 'TestServiceInjection.java' unit test in the Eclipse project attachment to make it failed, then comment out method 'someMethod' in the test to make it passed.


Affects: 3.0.5, 3.1 M2

Reference URL: http://forum.springsource.org/showthread.php?110338-Strange-problem-with-Configurable

Attachments:

Issue Links:

  • #13167 @Entity objects are not enhanced by the load time weaver in certain situations

2 votes, 4 watchers

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jul 1, 2011

Setya Nugroho D commented

Log captured when the test failed

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jul 1, 2011

Setya Nugroho D commented

Log captured when the test passed

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jul 15, 2011

Chris Beams commented

Ramnivas, could you take a look at this issue? It has to do with @Configurable injection and what appears to be an oddity with AJ weaving - you're probably best suited to look it over. I've simplified Setya's original reproduction project to its most minimal form, and observing the failure is trivially easy. Just clone the spring-framework-issues repository locally and follow the instructions here: https://github.com/SpringSource/spring-framework-issues/tree/master/SPR-8502

Thanks! Any comments from your end would be appreciated. I realize you may not have time to actually fix the issue; feel free to reassign to me.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jul 20, 2011

Chris Beams commented

This issue seems very similar to #13167, but it is not yet clear that it is a duplicate per se.

See the reproduction projects for both issues to observe the similarities (README contains instructions)

https://github.com/SpringSource/spring-framework-issues/tree/master/SPR-8502
https://github.com/SpringSource/spring-framework-issues/tree/master/SPR-8523

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jul 21, 2011

Alexandros Karypidis commented

Hi,

I would like to provide some information that is present in the forum thread where we discussed this with Setya (the bug reporter). I think this information should be highlighted, as it may help with the resolution.

As far as I could tell when stepping through the code, it appears as if there is a "race condition" present that involves Spring's test runner integration for JUnit and the runtime-aspect weaver. What seems to be happening is that when the test runner loads the test class, the runtime weaver is NOT yet active.

As result, if there is a reference to a @Configurable class in the test class (e.g. because it is used as a method parameter) the class will be loaded immediately (during the test class loading), causing the weaving to NOT be performed.

If you remove all references to the @Configurable class from the members of the test class (i.e. no method in the test class uses it as a parameter, no field uses it as its type) then the JVM will defer loading of the @Configurable class until some code that uses it is actually executed (e.g. a method body with a local variable that is of the @Configurable class type). At that point the weaver is active and the problem does not occur.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Mar 22, 2012

albert kam commented

Vote +1.

I am having this situation also outside of test environment, using 3.1.1 here.
Just an existence of one method can make the autowiring fails in the domain classes annotated with @Configurable.
Commenting the method fixes the problem.

I am thinking of using manual autowiring with AutowireCapableBeanFactory as a workaround for now.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Mar 22, 2012

albert kam commented

I have some info that might be useful.
In my case, my code is something like this (sorry for the self created code prototyping here) :

@singleton
myClass {
method addUsers() {
call injected userService to create a new user
//AND here the NPE occurs,
//because the user object is annotated with @Configurable(preConstruction=true),
//which after getting instantiated, doesnt have it's dependencies autowired
}

main() {
instantiate the context
get the myClass instance from context
myClassInstance.addUsers()
}

// and the above error only happens if this method exists !
// notice that the main app doesnt even call this method
// commenting this method will solve the NPE problem
// the Book is also a domainObject annotated with @Configurable(preConstruction=true)
public Book testAddBook() { return null; }
}

Then i changed the public method into a private method :
private Book testAddBook() { return null; }

And hurray, the dependencies are autowired again into the domain objects, no more NPE.

It was working for me before because the method was private.
I didnt know that turning it into public could cause this.

I think it has something to do with other configurable domains, because i tried changing the method into returning void (not the @Configurable Book type), and the error didnt happen.

Hope this could help !

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Dec 26, 2018

Sébastien Deleuze commented

This issue if outdated, the provided test does not behave with Spring Framework 5 like it was with Spring Framework 3.1, so I am resolving it as invalid. Please comment with an updated repro project if it is still relevant.

@spring-projects-issues spring-projects-issues added type: bug status: invalid in: test in: core labels Jan 11, 2019
@spring-projects-issues spring-projects-issues removed the type: bug label Jan 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core in: test status: invalid
Projects
None yet
Development

No branches or pull requests

2 participants