Announcement Announcement Module
Collapse
No announcement yet.
Creating Spring integration Adapters at runtime Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Creating Spring integration Adapters at runtime

    Hi,
    How can I create all of the adapters in Spring Integration?

    Instead of putting the adapters configuration in xml file, Suppose I want to expose user Interface, user will provide the information for the inbound adapters configuration like jdbc, ftp etc. Once user submit the details then adapters shall get created and if those adapters not being used for certain amount of time, it shall get destroyed instead of being long-lived inside the container.

  • #2
    Hi!

    I suggest you create XML config and trigger creation of ApplicationContext.
    I think our DSLs may help you:
    https://github.com/SpringSource/spri...ion-dsl-groovy
    https://github.com/SpringSource/spri...tion-dsl-scala

    Take care,
    Artem

    Comment


    • #3
      Also take a look at the dynamic-ftp sample application where application context "snippets" are created (with properties) and destroyed on demand.

      For inbound adapters, the context must be made a child of the main (parent) context so it can send messages into a channel defined there. That is discussed in this thread.

      Comment


      • #4
        Originally posted by Gary Russell View Post
        Also take a look at the dynamic-ftp sample application where application context "snippets" are created (with properties) and destroyed on demand.

        For inbound adapters, the context must be made a child of the main (parent) context so it can send messages into a channel defined there. That is discussed in this thread.
        Thank you Gary. I will look into it. As mentioned above about DSLs, If I use those, will I get any extra benefit what Spring integration natively provides?

        Comment


        • #5
          Originally posted by Cleric View Post
          Hi!

          I suggest you create XML config and trigger creation of ApplicationContext.
          I think our DSLs may help you:
          https://github.com/SpringSource/spri...ion-dsl-groovy
          https://github.com/SpringSource/spri...tion-dsl-scala

          Take care,
          Artem
          I want develop a service to create/modify/delete inbound/outbound adapters at runtime for File, SFTP/FTP, mail, JDBC. As suggested to create the XML and trigger the applicationcontext to load the xml files. How/where shall I store the xml content I mean shall I keep the spring xml content into file as it is or any storage, because when I redeploy the application, already created adapters specific by users has to be loaded again. And I observed that groovy DSL generates the xml, One more thing I want to know is it possible to achieve using groovy dsl if I want to create flow from the given input from the user the flow would be like

          1. Get the file from ftp, as ftp inbound adapter it will drop into some local folder
          2. then from local folder using file inbound adapter drop to some other local folder/network folder

          Each flow shall creates a single spring xml. Again how can I modify/delete the existing xml file and reload it?
          It's not necessary services only for the flow like above mentioned but also to give the ability to create/modify/delete the inbound/outbound adapters at runtime, initially only for above mentioned 4 adapters.

          I think if spring groovy dsl helps me to create xml and I can use the same for ApplicationContext

          What I am thinking if I can develop a service like this then I can start with the user interface by exposing REST Endpoint using Spring MVC.

          What would be the best approach to achieve this?

          Comment


          • #6
            Hi!

            What would be the best approach to achieve this?
            Sound like you try to find this solution: http://www.springsource.org/spring-xd

            Comment


            • #7
              Originally posted by Cleric View Post
              Hi!


              Sound like you try to find this solution: http://www.springsource.org/spring-xd
              Thank you Cleric. I observed this soultion when it has been launched. I didn't see the code base when it has launched. Now I tried to browse the codebase. I think the stuff what I am looking for that, all things will not be necessary. Did you mean to take this approach to built what I am looking for? I think the module/source, spring-xd-shell, spring-xd-rest-client, spring-xd-rest-domain, these modules which will help me what I am looking. As mentioned above about what I am looking for, If I want to achieve the same and develop it, Could you please give me some pointers from where to start first?

              Comment


              • #8
                Originally posted by Gary Russell View Post
                Also take a look at the dynamic-ftp sample application where application context "snippets" are created (with properties) and destroyed on demand.

                For inbound adapters, the context must be made a child of the main (parent) context so it can send messages into a channel defined there. That is discussed in this thread.
                In the dynamic-ftp sample

                Code:
                private final LinkedHashMap<String, MessageChannel> channels =
                				new LinkedHashMap<String, MessageChannel>() {
                
                					private static final long serialVersionUID = 1L;
                
                					@Override
                					protected boolean removeEldestEntry(
                							Entry<String, MessageChannel> eldest) {
                						//This returning true means the least recently used
                						//channel and its application context will be closed and removed
                						boolean remove = size() > MAX_CACHE_SIZE;
                						if(remove) {
                							MessageChannel channel = eldest.getValue();
                							ConfigurableApplicationContext ctx = contexts.get(channel);
                							if(ctx != null) { //shouldn't be null ideally
                								ctx.close();
                								contexts.remove(channel);
                							}
                						}
                						return remove;
                					}
                
                				};
                The code above removes and closes the application-context which were created at run time. If customer defines the ftp inbound and cron expression at run time I mean the source of the feed & other related configuration and where application context will be child of the parent as suggested to use the channel on parent. And if customer wants the created ftp inbound at run-time to there until and unless customer modify and deletes it. How to handle this scenario? One more scenario if we redeploy the application, already created inbound adapters by customers has to be started again. Example : FTP Inbound/outbound where the use cases may be CRUD plus start/stop for the existing inbound/outbound adapters at run-time all these use cases are specific to, If customer modifies the configuration it has to be reloaded. Is there any simple/complex approaches so that I can achieve this use cases?
                Last edited by Gary Russell; Aug 21st, 2013, 07:08 AM.

                Comment


                • #9
                  That's just a sample; the removal was added later to show how to remove an old adapter. Instead of doing it automatically, simply put it in a method and invoke it on-demand using a <service-activator/> or <control-bus/>. Same thing for your second question.

                  Comment

                  Working...
                  X