Uploaded image for project: 'Spring Integration'
  1. Spring Integration
  2. INT-3769

Be more friendly with current Spring Integration

    Details

      Description

      I'm currently learning Spring Web Services and Spring Integration and I'm working with current versions of both (2.2.1 and 4.1.6 respectively).

      If I'm not missing something, the Inbound web service gateways of Spring Integration still rely on plain beans implementing the MessageEndpoint interfaces, so appropriate beans implementing EndpointMapping should be declared in the application context to point to the SI inbound gateway beans. On the other hand, current Spring WS:

      • in its documentation, only annotation based configuration for bean endpoint methods is documented (I had to look at spring-integrations-samples project on GitHub to fill in the gap regarding the MessageEndpoint bean declaration)
      • does not provide any namespace-based configuration for non annotation-based MessageEndpoint beans, which would be handy (you have to define beans manually in the application context)
      • a couple of MessageEndpoint implementation that would be very useful to be used with Spring Integration are deprecated (!!) in favour of the method-annotation based variants (which are not quite interchangeable, correct me if I'm wrong): org.springframework.ws.soap.server.endpoint.mapping.SoapActionEndpointMapping and org.springframework.ws.server.endpoint.mapping.PayloadRootQNameEndpointMapping

      So, it seems like current Spring WS is not very friendly towards Spring Integration.
      Please don't shoot at me if I'm saying nonsense.

        Issue Links

          Activity

          Hide
          mauromol Mauro Molinari added a comment -

          @Greg Turnquist: I don't want to insist, however... I don't think "recommendation" is the same as "deprecation" (of the non-recommended). I may be wrong (it's some time I don't look thoroughly at Spring Web MVC), but I can't remember Spring Web MVC deprecated the old Controller implementations, even if now we have @Controller.
          It's evident that when using plain Spring WS, the annotation approach is much simpler and flexible, but at the same time it might not be the only possible usage scenario, and Spring Integration (where the XML namespace approach is MUCH more effective IMHO) is an example.

          Also, if the problem is the use of interfaces, why not deprecating EndpointMapping as a whole, and the other UriEndpointMapping implementation then?

          Show
          mauromol Mauro Molinari added a comment - @Greg Turnquist: I don't want to insist, however... I don't think "recommendation" is the same as "deprecation" (of the non-recommended). I may be wrong (it's some time I don't look thoroughly at Spring Web MVC), but I can't remember Spring Web MVC deprecated the old Controller implementations, even if now we have @Controller . It's evident that when using plain Spring WS, the annotation approach is much simpler and flexible, but at the same time it might not be the only possible usage scenario, and Spring Integration (where the XML namespace approach is MUCH more effective IMHO) is an example. Also, if the problem is the use of interfaces, why not deprecating EndpointMapping as a whole, and the other UriEndpointMapping implementation then?
          Hide
          abilan Artem Bilan added a comment -

          See the reference URL on the matter, too.

          Show
          abilan Artem Bilan added a comment - See the reference URL on the matter, too.
          Hide
          abilan Artem Bilan added a comment -

          Well, guys, looking to your comments one more time I am 50X50 right now.

          Of course we are flexible and can accept any solution.

          If Greg doesn't want to de-deprecate them, we are forced to live with them until we implement INT-3771.
          From other side it would be easier to de-deprecate release Spring WS 2.2.2 and forget that extra work at least for now.

          Yes, I agree that Controller isn't deprecated even if we have @Controller already and Spring Integration HTTP module uses that! See HttpRequestHandlingController and HttpRequestHandlingMessagingGateway.

          The same state we have with SI-WS where our adapter implements MessageEndpoint directly for the reason described above.

          Greg, I might not know Spring WS so well and I'd like to see the workaround for those deprecated classes for SI.

          At least for me it looks like breaking change from S-WS side for all those guys who live with only XML configuration yet...

          Thanks

          Show
          abilan Artem Bilan added a comment - Well, guys, looking to your comments one more time I am 50X50 right now. Of course we are flexible and can accept any solution. If Greg doesn't want to de-deprecate them, we are forced to live with them until we implement INT-3771 . From other side it would be easier to de-deprecate release Spring WS 2.2.2 and forget that extra work at least for now. Yes, I agree that Controller isn't deprecated even if we have @Controller already and Spring Integration HTTP module uses that! See HttpRequestHandlingController and HttpRequestHandlingMessagingGateway . The same state we have with SI-WS where our adapter implements MessageEndpoint directly for the reason described above. Greg, I might not know Spring WS so well and I'd like to see the workaround for those deprecated classes for SI. At least for me it looks like breaking change from S-WS side for all those guys who live with only XML configuration yet... Thanks
          Hide
          arjen.poutsma Arjen Poutsma added a comment -

          Indeed, deprecating SoapActionEndpointMapping and PayloadRootQNameEndpointMapping was a breaking change, and that's why it was introduced in a major new version: Spring-WS 2.0, which is - as Greg pointed out - almost five years old. I find it slightly worrying that it has taken us this long to find out that Spring Integration, our sister project, is depending on these deprecated features. Might I suggest that SI's integration tests use Spring's DeprecatedBeanWarner in the future?

          At any rate, I do see the point of this discussion, and I do think that Spring-WS might have been too aggressive deprecating XML-based features. Looking at Spring-MVC, which is conceptually very similar to Spring-WS, we can see that the XML-based SimpleUrlHandlerMapping, which is comparable to SoapActionEndpointMapping and PayloadRootQNameEndpointMapping in Spring-WS, has not been deprecated as of Spring 4. In fact, the only classes in MVC that were formerly deprecated, and since have been removed, are the abstract Controller base classes such as the SimpleFormController.

          Therefore, I would suggest to de-deprecate SoapActionEndpointMapping and PayloadRootQNameEndpointMapping in Spring-WS in order to have this issue resolved, but also - and perhaps more importantly - to remain consistent with Spring-MVC.

          Show
          arjen.poutsma Arjen Poutsma added a comment - Indeed, deprecating SoapActionEndpointMapping and PayloadRootQNameEndpointMapping was a breaking change, and that's why it was introduced in a major new version: Spring-WS 2.0, which is - as Greg pointed out - almost five years old. I find it slightly worrying that it has taken us this long to find out that Spring Integration, our sister project, is depending on these deprecated features. Might I suggest that SI's integration tests use Spring's DeprecatedBeanWarner in the future? At any rate, I do see the point of this discussion, and I do think that Spring-WS might have been too aggressive deprecating XML-based features. Looking at Spring-MVC, which is conceptually very similar to Spring-WS, we can see that the XML-based SimpleUrlHandlerMapping , which is comparable to SoapActionEndpointMapping and PayloadRootQNameEndpointMapping in Spring-WS, has not been deprecated as of Spring 4. In fact, the only classes in MVC that were formerly deprecated, and since have been removed, are the abstract Controller base classes such as the SimpleFormController . Therefore, I would suggest to de-deprecate SoapActionEndpointMapping and PayloadRootQNameEndpointMapping in Spring-WS in order to have this issue resolved, but also - and perhaps more importantly - to remain consistent with Spring-MVC.
          Hide
          grussell Gary Russell added a comment -

          Thanks, Arjen; I concur with your conclusion.

          I find it slightly worrying...

          To be fair, the spring-integration-ws module doesn't use any deprecated classes directly, so compiler warnings and the DeprecatedBeanWarner would not help.

          We do pay close attention to deprecations in projects that SI depends on and eliminate such uses as soon as practical.

          In this case only the sample app pulls in a UriEndpointMapping which is not deprecated. So, we had no automated way of detecting the deprecation of the other endoint mapping classes.

          It is, indeed, interesting, that it has taken 5 years for someone such as Mauro Molinari to notice it.

          Show
          grussell Gary Russell added a comment - Thanks, Arjen; I concur with your conclusion. I find it slightly worrying... To be fair, the spring-integration-ws module doesn't use any deprecated classes directly, so compiler warnings and the DeprecatedBeanWarner would not help. We do pay close attention to deprecations in projects that SI depends on and eliminate such uses as soon as practical. In this case only the sample app pulls in a UriEndpointMapping which is not deprecated. So, we had no automated way of detecting the deprecation of the other endoint mapping classes. It is, indeed, interesting, that it has taken 5 years for someone such as Mauro Molinari to notice it.

            People

            • Assignee:
              abilan Artem Bilan
              Reporter:
              mauromol Mauro Molinari
            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: