Announcement Announcement Module
Collapse
No announcement yet.
Tasklet's role moving to Step? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Tasklet's role moving to Step?

    I have get the latest trunk, and found out that 'different type of Tasklet' have now become 'different type of Step'. In fact originally I planned to do some interception between each tasklet iteration (something like making a 'decorator tasklet') for my own logging but seems I have to give up the idea :P

    just curious why current direction is adopted as I feel the way at m4 seems alright and easy for developer to extend (it seems that changing the Step is not that easy)

  • #2
    This was a design decision that was made to simplify development of jobs. Tasklets still exist, but now they only represent custom processing concerns. The item oriented processing paradigm was made the responsibility of the steps ItemOrientedStep and ChunkStep while custom processing is handled by injecting a tasklet into a a TaskletStep. The tasklet step is the equivalent of the old paradigm - i.e. every step uses a tasklet - except instead of having an ItemOrientedTasklet we now have an ItemOrientedStep, removing a level of abstraction and permitting easier configuration and more opportunities for defining custom item processing strategies.

    Comment


    • #3
      You misunderstand. The concept of using different types of tasklets hasn't changed. Just use the "TaskletStep" class as your step.

      The only thing that's changed is that the ItemOrientedTasklet was eliminated in favor of an ItemOrientedStep and ChunkedStep.

      You can also add interceptors by having your tasklet implement the ItemStream interface.

      Comment


      • #4
        I stand corrected - currently TaskletStep doesn't register item streams, so that won't work for interception --- this may change before RC1.

        Comment

        Working...
        X