Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
From: Daniel Kulp <dkulp@apache.org>
To: dev@cxf.apache.org
Subject: Re: [DISCUSS] Is there anyway to enable gzip encoding works with SOAP
 over Java Message Service 1.0
Date: Tue, 7 Dec 2010 14:39:39 -0500
User-Agent: KMail/1.13.5 (Linux/2.6.36; KDE/4.5.3; x86_64; ; )
Cc: Freeman Fang <freeman.fang@gmail.com>
References: <F0CA180A-534F-42E8-99EC-7312F8DFD065@gmail.com>
 <4CFE32F5.2080404@gmail.com> <781BBDF0-B3DA-49E7-BE18-6CFE56E5E707@gmail.com>
In-Reply-To: <781BBDF0-B3DA-49E7-BE18-6CFE56E5E707@gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201012071439.39998.dkulp@apache.org>


I would just say that once you configure in  the GZIP interceptors and such=
,=20
you are kind of outside the SOAP/JMS spec.   By default, the GZIP stuff is=
=20
negotiated anyway.   If a non-CXF SOAP/JMS client sends a message, it would=
n't=20
have the Accept-Transfer-Encoding thing and thus the server would just resp=
ond=20
back in the normal non-gzip form anyway.    Completely compliant.

Dan


On Tuesday 07 December 2010 8:24:00 am Freeman Fang wrote:
> Hi Willem,
>=20
> Actually what my real concer  is the chapter 2.4 in the spec
> 2.4 The JMS Message Body
> The contents of the JMS Message body MUST be the SOAP payload as a JMS
> BytesMessage or TextMessage. =E2=80=A0 [Definition: A fault MUST be gener=
ated
> with subcode unsupportedJMSMessageFormat when the arriving message
> format is not BytesMessage or TextMessage. =E2=80=A0 ]
>=20
> The bytes or characters of the JMS Message payload correspond to the
> MIME format as indicated by the definition of the contentType
> property. In this way, the SOAP node determines the proper formatting
> of the SOAP payload irrespective of the underlying JMS message type,
> and specifies an appropriate value for the contentType property which
> describes it to the receiving SOAP node. Specifically, if the payload
> is formatted as a MIME multipart message, then the first byte or
> character encountered in the JMS Message body MUST be the start of the
> MIME boundary for the start of the first part =E2=80=94 what MIME Part One
> [IETF RFC 2045] section 2.5 calls a "Body Part". =E2=80=A0 If the message=
 is
> formatted as "text/xml" or "application/soap+xml", then the first byte
> or character of the JMS Message body MUST be the start of a conforming
> XML document. =E2=80=A0
>=20
>=20
>=20
> Regards
>=20
> Freeman
>=20
> On 2010-12-7, at =E4=B8=8B=E5=8D=889:13, Willem Jiang wrote:
> > Hi Freeman,
> >=20
> > I think as there is no Content-Encoding/Accept-Encoding "JMS Message
> > Properties" defined in the specs, we are safe to extends the gzip
> > support in soap over jms.
> >=20
> > If the server doesn't support the gzip encoding, CXF client can
> > adjust itself, as this extension is not in the spec.
> >=20
> > Just my 2 cents.
> >=20
> > On 12/7/10 7:30 PM, Freeman Fang wrote:
> >> Hi,
> >>=20
> >> Recently with [1]CXF-3146, I make an improvement to let gzip encoding
> >> works over jms transport, but it's only applicable with cxf 2.2
> >> branch,
> >> as the jms transport with cxf 2.2 is a kind of proprietary
> >> implementation.
> >> Since cxf 2.3, cxf implements the soap over jms spec[2] which ensure
> >> interoperability between the implementations of different Web
> >> services
> >> vendors. With this spec, seems there's noway we can enable gzip
> >> encoding
> >> over jms. I previously thought the main barrier is there's no
> >> Content-Encoding/Accept-Encoding "JMS Message Properties" defined
> >> in the
> >> specs, but "JMS Message Properties" in the spec isn't exclusive so
> >> that
> >> seems we could have extend it to make at least both cxf client/server
> >> over jms understand gzip encoding. But finally I realize that the
> >> below
> >> part in the spec is the real reason we can't use gzip encoding.
> >>=20
> >> 2.4 The JMS Message Body
> >>=20
> >> The contents of the JMS Message body MUST be the SOAP payload as a
> >> JMS
> >> BytesMessage or TextMessage. =E2=80=A0 [Definition: A fault MUST be
> >> generated
> >> with subcode unsupportedJMSMessageFormat when the arriving message
> >> format is not BytesMessage or TextMessage. =E2=80=A0 ]
> >>=20
> >> The bytes or characters of the JMS Message payload correspond to the
> >> MIME format as indicated by the definition of the contentType
> >> property.
> >> In this way, the SOAP node determines the proper formatting of the
> >> SOAP
> >> payload irrespective of the underlying JMS message type, and
> >> specifies
> >> an appropriate value for the contentType property which describes
> >> it to
> >> the receiving SOAP node. Specifically, if the payload is formatted
> >> as a
> >> MIME multipart message, then the first byte or character
> >> encountered in
> >> the JMS Message body MUST be the start of the MIME boundary for the
> >> start of the first part =E2=80=94 what MIME Part One [IETF RFC 2045]
> >> section 2.5
> >> calls a "Body Part". =E2=80=A0 If the message is formatted as "text/xm=
l" or
> >> "application/soap+xml", then the first byte or character of the JMS
> >> Message body MUST be the start of a conforming XML document. =E2=80=A0
> >>=20
> >>=20
> >>=20
> >> Is my understanding correct? Or is there any way we can implement the
> >> gzip encoding without breaking the spec?
> >>=20
> >> Any comment is welcome.
> >>=20
> >> [1]https://issues.apache.org/jira/browse/CXF-3146
> >> [2]http://www.w3.org/TR/soapjms/
> >>=20
> >> Thanks
> >>=20
> >> Freeman

=2D-=20
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog