Announcement Announcement Module
No announcement yet.
Gateway not working with RC1.0 Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Gateway not working with RC1.0

    we have used SI 1.0.0.M6 version about one months ago , but this week I found that particular module is completely not working , we use SI Gateway to communicate with a external SMS service. when I search I found SI xmlschema have changed and message-creator,message-mapper attributed not there , we use following configuration.

    <si:gateway id="smsSender"

    In our POM file still we use 1.0.0M6 version and context file use following namesapace uri

    I just look at the RC1.0 documentation but can not find any gateway ( like HTTP ,WS gateways does not match with our requirements) .

    1.) Is there any way to keep my code as it is with M6 version , if so how to handle namespce problem for SI context ...?

    2.) with RC1.0 how can I update above configuration to use POJO based message-creator,message-mapper .....?

    3.) Can we expect such changes in future also ....?

    we already deliver our module to client , so this is becoming a bit of serious problem to us .
    Last edited by sagara; Nov 6th, 2008, 09:56 PM.

  • #2
    Im also in a similar situation that I have to refractor all my code after the latest realease which consumes lot of time and energy!On the other hand the documentation is far better than b4. Will be nice if they inform us about any changes in future that too beforehand?? When is final realease expected??? So that I dnt have to change my code again
    Last edited by ashleyvijay; Nov 6th, 2008, 03:25 AM.


    • #3
      We're looking into this specific problem. It could very well be that the current solution is not optimal, but you'll have to wait for Mark to make a statement on that.

      Just to be clear about this, a milestone means that the developers have reached a state in the project that they would like to share with other developers to get them to share their ideas. Based on those ideas the code will evolve into the next milestone. If the evolution requires the API to change, features to be removed that will happen and you shouldn't expect an apology. When the code reaches a certain stability and it isn't expected that features will be dropped you will see a release candidate. If the release candidate has issues they will be fixed, but it is not the expectation of the developers that considerable new features will be needed. Developers are sometimes wrong, so that's why there is a release candidate or even multiple RC's before there is a final release. It is not recommended to start large scale development on a milestone. Also it is not recommended to go into production before the final release.

      I think it is very brave to go into production off a milestone release. There might be important business reasons for you to do so, so I will not tell you it's a foolish thing to do. In fact making profit always involves taking risks, so if the potential profit is high, you're probably very right to have taken that risk.

      However, as there are no business reasons for us to take responsibility (as far as I know), I wish you the best of luck.

      We care deeply about the technology, but we only care about your profit if we can have a slice. Fair enough?


      • #4
        Thanks for the clarification.By the way we dnt expect any apologies for the change but its just tht it would be better if we r informed way b4 the realse so tht v dnt run into problems like this
        Originally posted by ashleyvijay View Post
        When is final realease expected???
        Would appreciate if could answer the quote??
        Last edited by ashleyvijay; Nov 6th, 2008, 04:47 AM.


        • #5
          Version information (including projected dates) is available in JIRA:

          Dates may change based on a number of factors: feedback we receive on the RC including bugs, other projects that we depend upon, other projects that depend upon us, etc. In other words, the dates in JIRA cannot be considered a contract. However, we are pretty confident in the dates that are posted there now, so you can expect the final release fairly soon.

          Iwein's description of the Milestone and Release Candidate is very important to consider. It is never advisable to go into production with a pre-Final version. A Milestone version is even riskier, because almost anything *can* change. However, it's also important to understand that the changes we have made have always been based upon what we think will make the project as good as it can be. If we renamed an XML element, it's for consistency or clarity. If we remove some strategy you were using, it's because we believe it was redundant and that there is a better way to accomplish the same thing. Most of these decisions are based upon user feedback combined with a lot of thought and a huge amount of development effort. The bottom line is that we are trying to provide the best possible 1.0 Final version, and that means we have had to be flexible during the Milestone phases. Now, that we are at the Release Candidate, you should expect much less change as we lead up to the 1.0 Final release. There may be a few additions, but removals and/or changes to what we consider the "public API" will only be made if we really feel that is absolutely necessary.

          Finally, I encourage you to read the descriptions at:
          If you feel that you need the level of support on the right-hand side, then you should contact SpringSource to learn about the service offerings:

          I will address the specific questions raised above in another reply shortly.



          • #6
            Thank u so much for the reply. If I work with RC1 now will it be easy/managable to upgrade to RC2 and the final realease (except for the bug fixes ofcourse) or more changes expected to come??


            • #7
              1.) Is there any way to keep my code as it is with M6 version , if so how to handle namespce problem for SI context ...?
              To continue using M6, you simply need to add the schema files to your XML Catalog in the IDE as described in this thread:

              2.) with RC1.0 how can I update above configuration to use POJO based message-creator,message-mapper .....?
              The reason we dropped these is to avoid the confusion of providing multiple ways of accomplishing the same thing and also to clearly focus on the "best practice" approach as what we will have to support and extend in the future. Therefore, the Gateway has been simplified. You should only specify the "request-channel" and "service-interface". The Message will be created with the payload simply being whatever object is passed as an argument to the gateway method. If you need to modify that Message, then add a Transformer after the Gateway. Ultimately, each component should have a single well-defined role, and in this case we felt that the "message-creator" and "message-mapper" were overlapping with the role of a Transformer.

              3.) Can we expect such changes in future also ....?
              Hopefully this is more clear after the description above. Things may change in the RC before Final but it will be much less likely than during the Milestone phase.

              we already deliver our module to client , so this is becoming a bit of serious problem to us .
              As mentioned above, I would definitely never advise going into production with a non-Final release and especially not a Milestone.

              Hope that helps.


              • #8
                HI Mark ,
                I’m always appreciate about your work in SI , I started this thread to solve specific technical problems now we are facing , I really don’t meant to point out any one for this , I’m also involving some of open source projects ,so I know how this works …..So guys you are doing excellent job.

                To see the success of any open source project ,and it’s require to have good community , About M6 I’m also noted there are some stuff little complex and need to be changed in future , and there are some good features that we need to keep .

                In my point of view “SimpleMessagingGateway” is a one of excellent feature of SI, when I introduce it to my team, they all are agreed with me , we heavily used it .But with 1.0RC AFAIK there is no way to configure “SimpleMessagingGateway” using context file as usual way , documentation does not discuss about generic case ( but with your post I think I can handle it now ) . And when i saying future changes , i meant about backward compatibility.

                With your last post I understand some of the points regarding message-creator, message-mapper, I can agree with you. But as a user I like to this Gateway concept because it define single entry point to communicate from our domain logic to SI with POJOs.

                Thanks for your help,


                • #9
                  Thank you.

                  It seems that we have inadvertently removed the coverage of the 'gateway' element while updating the Reference Documentation. We removed some out-of-date items, but I think this had been included in one of those sections. I have just added an issue for RC2 to add this back to the documentation:

                  In the meantime, you can check out the example in the CafeDemo within the 'org.springframework.integration.samples' module:

                  You will notice that only the service-interface is provided there. This also demonstrates the @Gateway method-level annotation support:

                  So, even though we removed the creator/mapper support (since we believe Transformer is the right tool for that job), the Gateway is still supported, and we will update the documentation for RC2.

                  Thanks again,