Announcement Announcement Module
No announcement yet.
Wrap file inbound and outbound channel adapters in custom adpater Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Wrap file inbound and outbound channel adapters in custom adpater

    Hi all,

    I am relatively new to spring integration so bear with me.

    I am finding myself writing lots of boilerplate configuration which, at a high level:

    - reads files from a directory (file-inbound-channel-adapter)
    - moves file to an archive directory (file-outbound-gateway)
    - pushes file to a queue for processing (file-outbound-gateway)
    - reads each line in the file, builds objects for each line in the file and filters out any lines that do not meet a certain criteria (transformer)
    - pushes resulting objects to a channel (transformer)

    I always have to declare an inbound-channel-adapter, an outbound-gateway and a transformer.

    Is there anyway I can wrap this task up in a custom adapter, such that I could declare something like this in my configuration:

    <beans:bean id="myTransformer" class="com.custom.transformer.MyTransformer" />
    Basically meaning I don't have to declare the same inbound-channel-adapter and outbound-gateways for each directory I want to process files from (the transformer will differ based on file type).

    Is this a reasonable idea? Or is it against the usual patterns..?


  • #2
    Technically from the aspect of usage patterns each adapter represents an identifiable/addressable path of the message flow (e.g., from named directory to named directory in your case), so if you have multiple directories that you want to process files from then you'll identify multiple inbound-adapters. The same goes for the outbound. That's why we have routers that could help you route to a specific adapter/endpoint.
    However, if you simply want to use the same configuration but make it work with different directories, you may want to consider property placeholder where directory name is identified as ${some.dir} and you have a property file where you actually resolve the placeholder


    • #3
      Thanks for the prompt reply.

      Yes, I agree. On reflection this is probably more of a build / context file issue, the current setup is a bit of a mess...time to review I think!