2.3.5 changes to @Resource behavior?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

2.3.5 changes to @Resource behavior?

longwa
Testing with a snapshot build for 2.3.5 and seeing some weirdness with beans that are using @Resource annotations. In one case, we had a tagLib which was using @Resource fooService and spring seemed to want to match anything of type Object (which of course failed since 70 things matched it).

Are there any known or intentional changes to auto wiring in the upcoming 2.3.5 stuff? I have another case where a service is using @Resource and Spring was trying to instantiate an abstract domain class for injection (???)

Just trying to head off any potential issues.

-Aaron
Reply | Threaded
Open this post in threaded view
|

Re: 2.3.5 changes to @Resource behavior?

longwa
Ok, I see the change now.

In 2.3.4, if you have bean with an @Resource annotation and the target of that dependency was not available by name (probably because it wasn't mocked by the test case), it would just not inject that dependency and the test would still work.

In 2.3.5, if you have something annotated with @Resource (Grails bean or non-grails, doesn't matter), it seems that you MUST have that bean available, by name, or Spring wants to try and fallback to auto-wire by type. 

What that means for us is that we need to add more @Mock() lines to tests that might instantiate one of the beans using @Resource to ensure those dependencies are available by name.

Not sure if this was an intended change but it might have the potential to break existing tests.


On Fri, Jan 10, 2014 at 3:43 PM, Aaron Long <[hidden email]> wrote:
Testing with a snapshot build for 2.3.5 and seeing some weirdness with beans that are using @Resource annotations. In one case, we had a tagLib which was using @Resource fooService and spring seemed to want to match anything of type Object (which of course failed since 70 things matched it).

Are there any known or intentional changes to auto wiring in the upcoming 2.3.5 stuff? I have another case where a service is using @Resource and Spring was trying to instantiate an abstract domain class for injection (???)

Just trying to head off any potential issues.

-Aaron

Reply | Threaded
Open this post in threaded view
|

Re: 2.3.5 changes to @Resource behavior?

Lari Hotari

This is the change in 2.3.5:
http://jira.grails.org/browse/GRAILS-10968
git commit: https://github.com/grails/grails-core/commit/8c8da73b175991e9420e359719530216da3d0af2

@PostConstruct, @PreDestroy and @javax.annotation.Resource annotations were ignored in unit tests previously. That has been a bug.

This is the source code for @javax.annotation.Resource autowiring logic:
https://github.com/spring-projects/spring-framework/blob/v3.2.6.RELEASE/spring-context/src/main/java/org/springframework/context/annotation/CommonAnnotationBeanPostProcessor.java#L437
It does look like it fallbacks to auto-wire by type.

Lari


      10.01.2014 22:57, Aaron Long wrote:
Ok, I see the change now.

In 2.3.4, if you have bean with an @Resource annotation and the target of that dependency was not available by name (probably because it wasn't mocked by the test case), it would just not inject that dependency and the test would still work.

In 2.3.5, if you have something annotated with @Resource (Grails bean or non-grails, doesn't matter), it seems that you MUST have that bean available, by name, or Spring wants to try and fallback to auto-wire by type. 

What that means for us is that we need to add more @Mock() lines to tests that might instantiate one of the beans using @Resource to ensure those dependencies are available by name.

Not sure if this was an intended change but it might have the potential to break existing tests.


On Fri, Jan 10, 2014 at 3:43 PM, Aaron Long <[hidden email]> wrote:
Testing with a snapshot build for 2.3.5 and seeing some weirdness with beans that are using @Resource annotations. In one case, we had a tagLib which was using @Resource fooService and spring seemed to want to match anything of type Object (which of course failed since 70 things matched it).

Are there any known or intentional changes to auto wiring in the upcoming 2.3.5 stuff? I have another case where a service is using @Resource and Spring was trying to instantiate an abstract domain class for injection (???)

Just trying to head off any potential issues.

-Aaron


Reply | Threaded
Open this post in threaded view
|

Re: 2.3.5 changes to @Resource behavior?

longwa
Thanks Lari. Makes sense, just caught me by surprise and wasn't immediately obvious what was going on.


On Sat, Jan 11, 2014 at 1:44 PM, Lari Hotari <[hidden email]> wrote:

This is the change in 2.3.5:
http://jira.grails.org/browse/GRAILS-10968
git commit: https://github.com/grails/grails-core/commit/8c8da73b175991e9420e359719530216da3d0af2

@PostConstruct, @PreDestroy and @javax.annotation.Resource annotations were ignored in unit tests previously. That has been a bug.

This is the source code for @javax.annotation.Resource autowiring logic:
https://github.com/spring-projects/spring-framework/blob/v3.2.6.RELEASE/spring-context/src/main/java/org/springframework/context/annotation/CommonAnnotationBeanPostProcessor.java#L437
It does look like it fallbacks to auto-wire by type.

Lari



      10.01.2014 22:57, Aaron Long wrote:
Ok, I see the change now.

In 2.3.4, if you have bean with an @Resource annotation and the target of that dependency was not available by name (probably because it wasn't mocked by the test case), it would just not inject that dependency and the test would still work.

In 2.3.5, if you have something annotated with @Resource (Grails bean or non-grails, doesn't matter), it seems that you MUST have that bean available, by name, or Spring wants to try and fallback to auto-wire by type. 

What that means for us is that we need to add more @Mock() lines to tests that might instantiate one of the beans using @Resource to ensure those dependencies are available by name.

Not sure if this was an intended change but it might have the potential to break existing tests.


On Fri, Jan 10, 2014 at 3:43 PM, Aaron Long <[hidden email]> wrote:
Testing with a snapshot build for 2.3.5 and seeing some weirdness with beans that are using @Resource annotations. In one case, we had a tagLib which was using @Resource fooService and spring seemed to want to match anything of type Object (which of course failed since 70 things matched it).

Are there any known or intentional changes to auto wiring in the upcoming 2.3.5 stuff? I have another case where a service is using @Resource and Spring was trying to instantiate an abstract domain class for injection (???)

Just trying to head off any potential issues.

-Aaron