@StepScope not working when XML namespace activated

[farnetto]

I believe the problem described in the last comment in #1569 still exists: #1569 (comment)

If the Spring Batch XML namespace is loaded with CoreNamespaceUtils, and then you try to define a @StepScope bean in Java e.g. in a Configuration or Component class, then the bean is proxied twice and you get an exception during batch execution:

java.lang.ClassCastException: com.sun.proxy.$Proxy173 cannot be cast to org.springframework.batch.item.support.AbstractItemCountingItemStreamItemReader
	at org.springframework.batch.item.support.AbstractItemCountingItemStreamItemReader$$FastClassBySpringCGLIB$$ebb633d0.invoke(<generated>) ~[spring-batch-infrastructure-4.2.5.RELEASE.jar:4.2.5.RELEASE]
	at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:218) ~[spring-core-5.2.13.RELEASE.jar:5.2.13.RELEASE]
	at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:771) ~[spring-aop-5.2.13.RELEASE.jar:5.2.13.RELEASE]
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:163) ~[spring-aop-5.2.13.RELEASE.jar:5.2.13.RELEASE]
	at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:749) ~[spring-aop-5.2.13.RELEASE.jar:5.2.13.RELEASE]
	at org.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:136) ~[spring-aop-5.2.13.RELEASE.jar:5.2.13.RELEASE]
	at org.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:124) ~[spring-aop-5.2.13.RELEASE.jar:5.2.13.RELEASE]
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186) ~[spring-aop-5.2.13.RELEASE.jar:5.2.13.RELEASE]
	at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:749) ~[spring-aop-5.2.13.RELEASE.jar:5.2.13.RELEASE]
	at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:691) ~[spring-aop-5.2.13.RELEASE.jar:5.2.13.RELEASE]
	at org.springframework.batch.item.file.FlatFileItemReader$$EnhancerBySpringCGLIB$$9569ac9c.open(<generated>) ~[spring-batch-infrastructure-4.2.5.RELEASE.jar:4.2.5.RELEASE]
	at org.springframework.batch.item.support.CompositeItemStream.open(CompositeItemStream.java:103) ~[spring-batch-infrastructure-4.2.5.RELEASE.jar:4.2.5.RELEASE]
	at org.springframework.batch.core.step.tasklet.TaskletStep.open(TaskletStep.java:311) ~[spring-batch-core-4.2.5.RELEASE.jar:4.2.5.RELEASE]
	at org.springframework.batch.core.step.AbstractStep.execute(AbstractStep.java:205) ~[spring-batch-core-4.2.5.RELEASE.jar:4.2.5.RELEASE]

I have a bean called scopedTarget.scopedTarget.reader in my context, which is obviously wrong.

The XML namespace creates an instance of StepScope under the name "org.springframework.batch.core.scope.internalStepScope" with autoProxy=true and AbstractBatchConfiguration.ScopeConfiguration creates an instance with autoProxy=false.

There is a check in BatchScopeSupport#postProcessBeanFactory if the bean name starts with the target name prefix, but the value of StepScope.TARGET_NAME_PREFIX doesn't catch it: stepScopedTarget.

Should StepScope.TARGET_NAME_PREFIX be corrected? I don't see where else it is used.

[farnetto]

pull request #3938

[hillebrandt]

Hi @benas
are there any plans when this issue will be worked on further? We are also affected by this issue in a project and get "scopedTarget.scopedTarget.[...]" beans and resulting exceptions on lookup. If I apply the change from the PR, everything apparently works again in the application.
It is not clear to me what the original purpose of the modified bean names "stepScopedTarget.[...] (or jobScopedTarget.[...]) was. If these are really useful, the implementation is in any case incomplete and inconsistent, since these names are never actually written.

[karnik]

Hi @benas, are there any plans to merge this pull request? we are also affected by this issue and the fix is working for us.

[fmbenhassine]

Yes, we are intending to address this issue and review the attached PR.

It is not clear to me what the original purpose of the modified bean names "stepScopedTarget.[...] (or jobScopedTarget.[...]) was

@hillebrandt The prefix has been changed from scopedTarget. to stepScopedTarget. in 241d9f1 when implementing the job scope. I think the intention was to differentiate step-scoped beans from job-scoped ones. But I need to dig deeper to understand the implication of that change.

That said, having a bean named scopedTarget.scopedTarget.reader as reported by @farnetto is obviously wrong. I planned to address this issue in the next release.

[raducoanda]

Hi @fmbenhassine

I believe the issue described by @farnetto is still present. We've encountered the same issue in our project, and was able to reproduce it also in a new project.

In our constellation we had an xml file using the batch namespace and a JavaConfig using the @EnableBatchProcessing annotation.

We're you able to find out why the strings stepScopedTarget. and jobScopedTarget. were picked in 241d9f1 ?

[anthochristen]

@fmbenhassine any reason the PREFIX wasn't changed for job scoped beans? We still see the duplicate proxy being created for job scoped one?

P.S:
Able to workaround by using @ImportedResources to load the XML definitions instead of using setSources in that case the XML resources are imported post bean definitions so the ScopeConfiguration kicks in and the CoreNamespaceUtils doesn't create duplicate proxies.
Is there any way to programatically inject the importedResources to a config class?

[fmbenhassine]

@anthochristen No, if the issue happens with job scoped beans, we should fix it as well. I see you created #4533, thank you for doing that. We will address the issue with the job scope there.