@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 ?