Announcement Announcement Module
No announcement yet.
Spring Web Services 2.1.3.RELEASE released Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring Web Services 2.1.3.RELEASE released

    Dear Spring community,

    I'm pleased to announce that Spring Web Services 2.1.3.RELEASE has been released!

    This is the latest GA release in the 2.1 release cycle. It mainly consists of bug fixes.

    Please see the changelog for more details.

    This release is currently available on our Maven release repository, and will be available on Maven Central and the download page shortly.

    For more information, refer to
    Last edited by Arjen Poutsma; Apr 16th, 2013, 04:13 PM.

  • #2
    Hello Arjen!

    Thanks for the Github move and for the release of the most important Java WebServices framework!

    Sorry for the thread hijacking but I have a very important question for you.
    I've been working for some time on a project which will allow to do several new things with Spring-WS:
    1. JSR-181 model of @WebService annotated interfaces - no dependency on JAX-WS however!
    2. Spring OXM based JAXB2 implementation which will allow to use javax.jws.soap.SOAPBinding.Use.ENCODED flag

    Why 1)? Because it's actually quite nice and isn't in contradiction with "contract-first" model although it might appear as that at first glance.

    Why 2)? I have long-term experience with web services since their "dark age" when every WSDL was generated from 1M$ tools and was always RPC-Encoded. Vanilla JavaEE advocates say that JAX-RPC is deprecated, but they're too busy speaking at conferences, they don't have time to work with legacy code and they probably think that legacy code will disappear a minute after JavaEE 7 will be released.

    Saying all that - I have a project at Github: I'd like to participate in extending Spring-WS with several new features such as WebService proxies (maybe useful for Spring-Integration - to allow e.g., conversion from RPC/Encoded to Doc/Literal?), WS-Policy or other...
    Also I'd like to put emphasis on interoperability between Spring-WS model and (much) older, but existing WebServices written using Axis1 or ASP.NET ASMX WebServices.

    I don't ask you to look at it or revise it anyway. May I ask you few questions?
    • Should I change the package names from to my own? Sorry for taking yours, but I wasn't thinking about it when I started
    • Were you thinking about some kind of spring-ws-ext project for e.g., 3.0.x timeline?
    • Should I quit doing it becaese I could have legal problems?

    Grzegorz Grzybek


    • #3
      Hi Gregorz,

      From reading your post it certainly looks interesting. Unfortunately I am currently traveling, and won't have time to look at the code until the week of the 29th. Feel free to ping me if I don't respond by the end of that week.

      Thanks for you help!



      • #4
        Thanks for reply!

        I work on this in my spare time (which I don't have that much....). I'm working on different areas when I have time (JSR-181 model, JAXB2-based Soap-Encoding marshalling, even Category-Theory approach to WebServices in Java). I'm writing down some researches but it's not a part of Github (yet).

        I just thought that allowing Spring-Ws users to access these legacy WebServices that are now accessible using Axis1 only would be a great help for them. And more politically - it would make Spring-WS more enterprise than JavaEE Deprecating/removing something is one side, but existing RPC/Encoded services (e.g., in SAP world) won't dissappear and surely woill live longer than JavaEE 6 and soon JavaEE 7 hype

        Grzegorz Grzybek


        • #5
          Hello Arjen!

          I'm also back from a trip. Here's a short plan without any time constraints. I have very little spare time, but I'd be very happy to make these "extensions":
          • “bind” extension – JAXB2 compliant Object/XML mapper
            • basic compliance – implementation of context, marshaller and unmarshaller
            • multi-ref encoding (outside any framework, such as SOAP 1.1 or 1.2 – there's a place for this in “jws” extension) which is a base for SOAP-Encoding of RPC/Encoded WebServices implemented in “jws” extension.
            • XSD - Java mapping using
            • Code generation – maybe later
          • “jws” extension – using JSR-181 annotations to create self-describing (in terms of XSD and WSDL) endpoints which fit into Spring-WS server-side framework and client-side WebServiceTemplate
            • @WebService/@WebMethod/@WebParam annotations are scanned to produce MethodEndpoints mapped and handled by standard Spring-WS mechanisms (EndpointAdapter, EndpointMapping)
            • @WebService annotated Java interface is an input to create type-safe proxy for WebService invocations (just like Axis1 client stubs configure and use javax.xml.rpc.Call objects)
            • both WebServiceTemplate (a little tweaked) at client-side and MethodArgumentResolver/MethodReturnValueHandler at server-side use standard org.springframework.oxm.[M|Unm]arshaller - “bind” extension provide it's own JAXB2 (un)marshaller
            • there's explicit notion of what I call “WebService invocation” which is something more than pure Spring-WS “payload” - it is payload + optional indication of WebService method + (maybe) some binding information (e.g., whether the “part” is bound to SOAP Body or Header). The invocation may represent both RPC and Document style WebService. I've found that RPC/Encoded is still a common problem in Enterprise WebServices - just look at Stackoverflow questions.
            • a Spring-WS endpoint mapping, which has found endpoints may be configured to respond to GET requests presenting a list of mapped endpoints/ports/services (just like CXF and Axis do)
            • Code generation both from JSR-181 annotations and from WSDL – maybe later, maybe as an Eclipse plugin
          • long-term goals:
            • “policy” extension – WS-Policy driven configuration of Spring-WS services (mainly for WS-Security configuration)
            • “proxy” extension – an extension to proxy both WebService invocations (just like “Soap Node” was designed) and their WSDLs (e.g., translation of “?wsdl” URIs) – I've done it many times in my commercial projects
            • “rm” extension – WS-Reliable Messaging if there's a need (I don't think so )
            • “vtd” extension – VTD-XML based MethodArgumentResolver/MethodReturnValueHandler

          So could you please tell me if I have to rename my packages from "" to something else (that was first natural choice, I thought later about possible consequences)?

          Do you have any plans that are similar/different than mine for Spring-WS 3.0?

          best regards
          Grzegorz Grzybek


          • #6
            Spring Web Services makes enforcing best practices easier.We can confidently use Spring-WS in our project. Thanks for great information and its release


            • #7
              That's nice