Announcement Announcement Module
No announcement yet.
SI initiator / startup program Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • SI initiator / startup program

    I've been working nicely through the sample apps, thank you for some great samples. They all work well.

    I noticed they all live from main() method. If I'm going into production, surely a main method isnt the correct way to manage my SI app? Anyone got any suggestions how one houses or contains or manages ones SI app?


  • #2
    If you look at the main() methods within the samples, most of them are just starting an ApplicationContext. Since the Spring Integration components will 'auto-start' by default (pollers, etc), that is usually all that is necessary. This is why we often describe Spring Integration as an "embedded message bus".

    Therefore, if your app is web-based, you can bootstrap the Spring Integration components by simply including those configuration files in the 'contextConfigLocation' parameter used by Spring's ContextLoaderListener (defined in web.xml).

    In some cases, a main() method could actually be sufficient (no web presence). However, another really nice solution, which also provides the benefits of OSGi-based deployment, is to run the Spring Integration application within the SpringSource dm Server. That works really well for web-apps also since it embeds Tomcat itself, but if you end up creating and deploying a WAR file that has no need for web-based endpoints, then a dm Server instance provides a lightweight alternative.


    • #3
      Hi Mark,

      Thanx for that info, appreciate it.
      We probably going to have to deploy our app to WebSphere. In which case, from what you saying, perhaps then just have a dummy servlet that basically starts everything up? Or, our EJB-injection thread from earlier should also suffice? Both will then be embedded solutions, providing SI with a 'home'? But is that neccessary to do? I'm happy to just use a main method, it seems too easy. What I'm trying to find out if it is in fact acceptable practice to just start is up via a main method? I just want to avoid complexity. Thats what I like about Spring. If it can live happily like that, even in a production environment, then I'm happy
      Last edited by dudleygb; Feb 12th, 2009, 01:28 AM. Reason: additional comments


      • #4
        Everything for startup happens in the constructor of the ApplicationContext. Where you call it is not up to us (could be inside the EJB). If you tear down the jvm we go down with it; it is considered polite to call context.close() first.

        That's all.


        • #5
          thanx iwein, i appreciate the info. I understand it's not up to you to dictate where the startup occurs, but like everything, theres a preferred and best practice way of doing things. I'm just really asking what you guys feel will be best for implementing SI. We are doing an integration project, so theres no web requirements. We may have to use EJB as a result of an external system constraint. I just really wanted to know which of the following options would be the most reliable or better for SI to live in.

          -Using a dummy servlet/webapp to initiate the process. Basically SI will then live in a servlet environment.
          -Using it within an EJB. SI will live in container.
          -SI living on its own in a JVM, started via main() method. (After all, Spring is its own container)
          -SI living in Spring server

          Just your thoughts and feeling please. Most appreciative,


          • #6
            In general, I think the best runtime configuration is to run SI from an OSGi bundle in dm Server. It is imo the best mix of flexibility and simplicity. So when starting from a blank sheet that's what I would do.

            However, it is never a good idea to add unnecessary complexity to your system. If you already have a container running for your EJB the simplest config is to run SI from within the EJB. If you have no compelling reasons to do otherwise you shouldn't.

            Depending on the external system constraint it may very well be possible to use Springs remoting or (even better) web services features to integrate, in which case nothing is stopping you from going for gold.

            I'm not trying to end this with a sales pitch, but you could go over this with a consultant to see what's best for your specific situation. If you ask for it you might get Mark or me over. I'd love to dig into the details of this one, but I guess it might be a problem if you shared your requirements on the internet

            Anyway, to get back to your point of best practices. I wasn't trying to be clever when I said "That's all". It really is, and I think we can be very proud of that. We don't need you to make any changes to your target environement other than adding the proper jar files and having the proper jvm.

            I do have a preference of runtime environements, but that is completely decoupled from the Spring components. As it should be. Building software is hard enough without us adding more requirements to your list right?


            • #7
              thanx iwein,

              so no to labour the point, but it is acceptable practice then to just let it run off a main method in a jvm, simple as that