Loading ...
Sorry, an error occurred while loading the content.

Re: [soapbuilders] JAX-WS 2.0 Final Release

Expand Messages
  • Doug Kohlert
    Steve, I believe that JAX-RPC and JAX-WS in glassfish both use the same version of SAAJ.
    Message 1 of 7 , Jun 6, 2006
    • 0 Attachment
      Steve,
      I believe that JAX-RPC and JAX-WS in glassfish both use the same version
      of SAAJ.

      Steve Loughran wrote:

      > On 6/6/06, Doug Kohlert <doug.kohlert@...
      > <mailto:doug.kohlert%40sun.com>> wrote:
      > > Steve,
      > > First, deployment options do not need to be encoded in sources, 109 has
      > > just defined resonable defaults that a DD is no longer necessary. You
      > > have the choice of adding some deployment characteristics to code but
      > > the DD can always override what is in the code so you should have no
      > > concernes there.
      >
      > seems good.
      >
      > > Second, yes both JAX-RPC and JAX-WS run side-by-side and in Glassfish,
      > > they do not share any code.
      >
      > How do they reconcile the need for JAXRPC to depend upon one version
      > of SAAJ and the JAXWS needing a different version?
      >
      > -steve
      >
      >
    • Steve Loughran
      ... OK. It looks like Axis1 is a bit too intimate with its implementation of SAAJ, so running stuff side-by-side is going to be trickier. Its an interestinf
      Message 2 of 7 , Jun 6, 2006
      • 0 Attachment
        On 6/6/06, Doug Kohlert <doug.kohlert@...> wrote:
        > Steve,
        > I believe that JAX-RPC and JAX-WS in glassfish both use the same version
        > of SAAJ.

        OK. It looks like Axis1 is a bit too intimate with its implementation
        of SAAJ, so running stuff side-by-side is going to be trickier.

        Its an interestinf feature of Java EE5, that by choosing to mandate
        support for legacy EJB and legacy SOAP, app servers are going to be
        far less nimble than they would otherwise be. Stil, hibernate+xfire
        hosts nicely on tomcat.

        What this does mean for soap stacks is that the legacy stacks are
        going to stick around. People are still going to code for them, and we
        are still going to encounter interop problems. Accordingly, nobody is
        going to be able to stop maintenance of the old stacks. I pity the end
        users who, in the open source world, are those maintainers.

        How did.NET 2.0 handle this transition to the new stack? Does the old
        one + WSE live on, or has the old API been bridged into the new
        world?

        -steve
      Your message has been successfully submitted and would be delivered to recipients shortly.