Spring Batch
  1. Spring Batch
  2. BATCH-1773

Step-scoped annotation based listener is not called

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Cannot Reproduce
    • Affects Version/s: 2.1.8
    • Fix Version/s: 2.2.0, 2.2.0 - Sprint 11
    • Component/s: None
    • Labels:
      None

      Description

      Whilst playing around with some spring batch examples, i noticed a strange behaviour, if you use a step scoped stepexecutionlistener with annotation e.g. @AfterStep, the method won't be used.

      To be sure i tested the 4 possibilities:

      • interface based listener
      • interface based listener scope="step"
      • annotation based listener
      • annotation based listener scope="step"

      the afterstep method of the last one annotation based listener scope="step" is not called

      it smells like a bug, but i might miss something here

      if you want to see the source, i created a simple listeners project in my github repo https://github.com/langmi/spring-batch-examples, listener projects lives in https://github.com/langmi/spring-batch-examples/tree/master/listeners

        Activity

        Hide
        Dave Syer added a comment -

        Looks like a bug to me. There is a test that is supposed to cover this in org.springframework.batch.core.listener.StepListenerFactoryBeanTests.testProxiedAnnotationsFactoryMethod(), but obviously the test doesn't go far enough. The problem is in MethodInvokerUtils - various places in there assume that a Proxy has a target which has a class that is analyzable directly to pull out the listener annotations, but it turns out that a step-scoped proxy has an extra level of indirection because the TargetSource is not a simple holder for the target. SimpleMethodInvoker could probably deal with the target source itself if it was given the chance, but the MethodInvokerUtils give up trying to find the target method before the invoker gets created. If you want to contribute a test case, please add it as a test case for MethodInvokerUtils and/or SimpleMethodInvoker.

        A workaround is to use the interface or not use step scope (as you have demonstrated adequately).

        Show
        Dave Syer added a comment - Looks like a bug to me. There is a test that is supposed to cover this in org.springframework.batch.core.listener.StepListenerFactoryBeanTests.testProxiedAnnotationsFactoryMethod(), but obviously the test doesn't go far enough. The problem is in MethodInvokerUtils - various places in there assume that a Proxy has a target which has a class that is analyzable directly to pull out the listener annotations, but it turns out that a step-scoped proxy has an extra level of indirection because the TargetSource is not a simple holder for the target. SimpleMethodInvoker could probably deal with the target source itself if it was given the chance, but the MethodInvokerUtils give up trying to find the target method before the invoker gets created. If you want to contribute a test case, please add it as a test case for MethodInvokerUtils and/or SimpleMethodInvoker. A workaround is to use the interface or not use step scope (as you have demonstrated adequately).
        Hide
        Michael Minella added a comment -

        I'm having a hard time reproducing this issue. I've created my own job and listener and it seemed to execute as expected so I pulled down the listener project as mentioned above. When I run a build, it executes the SimpleJobConfigurationTest#launchJob test. This test seems to load the simple-job.xml configuration which has the four scenarios as defined above modeled. However, when I run this locally (I cloned your repo), I get the following output (note the third line):

        2013-01-07 13:34:01,450 DEBUG main [de.langmi.spring.batch.examples.listeners.InterfaceStepListener] - <beforeStep>
        2013-01-07 13:34:01,453 DEBUG main [de.langmi.spring.batch.examples.listeners.InterfaceStepScopeListener] - <beforeStep>
        2013-01-07 13:34:01,517 DEBUG main [de.langmi.spring.batch.examples.listeners.AnnotationStepScopeListener] - <afterStep>
        2013-01-07 13:34:01,517 DEBUG main [de.langmi.spring.batch.examples.listeners.AnnotationStepListener] - <afterStep>
        2013-01-07 13:34:01,518 DEBUG main [de.langmi.spring.batch.examples.listeners.InterfaceStepScopeListener] - <afterStep>
        2013-01-07 13:34:01,518 DEBUG main [de.langmi.spring.batch.examples.listeners.InterfaceStepListener] - <afterStep>
        

        I realize this issue has been open for a while so I'm wondering if I'm either missing something or if it's been inadvertently fixed without realizing it. Unless someone has a test case that can replicate this issue, I think we're at a stand still.

        Show
        Michael Minella added a comment - I'm having a hard time reproducing this issue. I've created my own job and listener and it seemed to execute as expected so I pulled down the listener project as mentioned above. When I run a build, it executes the SimpleJobConfigurationTest#launchJob test. This test seems to load the simple-job.xml configuration which has the four scenarios as defined above modeled. However, when I run this locally (I cloned your repo), I get the following output (note the third line): 2013-01-07 13:34:01,450 DEBUG main [de.langmi.spring.batch.examples.listeners.InterfaceStepListener] - <beforeStep> 2013-01-07 13:34:01,453 DEBUG main [de.langmi.spring.batch.examples.listeners.InterfaceStepScopeListener] - <beforeStep> 2013-01-07 13:34:01,517 DEBUG main [de.langmi.spring.batch.examples.listeners.AnnotationStepScopeListener] - <afterStep> 2013-01-07 13:34:01,517 DEBUG main [de.langmi.spring.batch.examples.listeners.AnnotationStepListener] - <afterStep> 2013-01-07 13:34:01,518 DEBUG main [de.langmi.spring.batch.examples.listeners.InterfaceStepScopeListener] - <afterStep> 2013-01-07 13:34:01,518 DEBUG main [de.langmi.spring.batch.examples.listeners.InterfaceStepListener] - <afterStep> I realize this issue has been open for a while so I'm wondering if I'm either missing something or if it's been inadvertently fixed without realizing it. Unless someone has a test case that can replicate this issue, I think we're at a stand still.
        Hide
        Michael Lange added a comment -

        Works now for me too, i vote for closing the issue

        Show
        Michael Lange added a comment - Works now for me too, i vote for closing the issue

          People

          • Assignee:
            Michael Minella
            Reporter:
            Michael Lange
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: