Spring Batch

MultiResourceItemReader should be more dynamic in nature

Details

  • Type: Sub-task Sub-task
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 2.0.0.M3
  • Component/s: Core
  • Description:
    Hide
    Currently MultiResourceItemReader is only suitable for reading resources that are set statically (in an application context) through the setResources property. In many batch jobs the path on which resources reside isn't know during development. Ideally you want to be able to set the resources for a MultiResourceItemReader dynamically. For instance by specifying a resource path in the JobParameters or in the ExecutionContext (during a previous step).

    Therefore I've created a dynamic version of MultiResourceItemReader that does exactly that; setting the resources property at runtime by utilizing the JobParameters / ExecutionContext. Perhaps this functionality can be integrated into MultiResourceItemReader? See the attached code for details.
    Show
    Currently MultiResourceItemReader is only suitable for reading resources that are set statically (in an application context) through the setResources property. In many batch jobs the path on which resources reside isn't know during development. Ideally you want to be able to set the resources for a MultiResourceItemReader dynamically. For instance by specifying a resource path in the JobParameters or in the ExecutionContext (during a previous step). Therefore I've created a dynamic version of MultiResourceItemReader that does exactly that; setting the resources property at runtime by utilizing the JobParameters / ExecutionContext. Perhaps this functionality can be integrated into MultiResourceItemReader? See the attached code for details.

Attachments

  1. Java Source File
    DynamicMultiResourceItemReader.java
    (4 kB)
    Richard Kettelerij
    05/Nov/08 5:59 PM

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Dave Syer added a comment - 06/Nov/08 1:14 AM
Moved to sub-task of BATCH-282 (a more generic approach, but I'll leave this one open until the parent is finished). In general if people want to implement this kind of thing we recommend an approach based on changing the thing that is injected into a reader/writer etc., rather than extending the existing components in spring-batch-infrastructure. Favour composition over inheritance. In this case it could be achieved by creating a factory for Resources[] that delays initialization until the step listener is called (like the StepExecutionResourceProxy).
Show
Dave Syer added a comment - 06/Nov/08 1:14 AM Moved to sub-task of BATCH-282 (a more generic approach, but I'll leave this one open until the parent is finished). In general if people want to implement this kind of thing we recommend an approach based on changing the thing that is injected into a reader/writer etc., rather than extending the existing components in spring-batch-infrastructure. Favour composition over inheritance. In this case it could be achieved by creating a factory for Resources[] that delays initialization until the step listener is called (like the StepExecutionResourceProxy).
Hide
Permalink
Richard Kettelerij added a comment - 06/Nov/08 1:32 AM
Thanks Dave, a more generic approach for all item reader/writers would be even better. I agree on the " composition over inheritance" part, however I think this use case (pulling the pattern form the parameters or execution context) is so common that it might as well be integrated into the MultiResourceItemReader. Now this isn't an issue since BATCH-282 is already thinking about a generic solution.
Show
Richard Kettelerij added a comment - 06/Nov/08 1:32 AM Thanks Dave, a more generic approach for all item reader/writers would be even better. I agree on the " composition over inheritance" part, however I think this use case (pulling the pattern form the parameters or execution context) is so common that it might as well be integrated into the MultiResourceItemReader. Now this isn't an issue since BATCH-282 is already thinking about a generic solution.
Hide
Permalink
Dave Syer added a comment - 24/Nov/08 9:50 AM
BATCH-282 provides alternative
Show
Dave Syer added a comment - 24/Nov/08 9:50 AM BATCH-282 provides alternative

People

Dates

  • Created:
    05/Nov/08 5:59 PM
    Updated:
    24/Nov/08 9:50 AM
    Resolved:
    24/Nov/08 9:50 AM
Atlassian JIRA (v4.1.2#531) | Report a problem | Request a feature | Contact administrators
Powered by a free Atlassian JIRA open source license for Spring Framework. Try JIRA - bug tracking software for your team.