Hi Dan,
Thanks for your input.
And Peter Easton, who is from Soap over JMS spec group told me the new
version spec including this proposal should be released soon, I just
create CXF-3174[1] to track this issue and when the new version spec
released, I'll add implementation accordingly.
[1
On Tuesday 07 December 2010 9:14:27 pm Freeman Fang wrote:
> Hi Dan & Christian,
>
> Thanks for your comment, and it's true that the jms providers like
> Tibco EMS and Activemq allow compress messages a transport level.
> The problem is that the SOAP over JMS spec currently doesn't support
> the b
Hi Dan & Christian,
Thanks for your comment, and it's true that the jms providers like
Tibco EMS and Activemq allow compress messages a transport level.
The problem is that the SOAP over JMS spec currently doesn't support
the behavior for encoded(like gzip) message.
Fortunately, there's sa
Hi all,
most jms providers allow to compress messages on the transport level. I
guess this is a safe and unproblematic way.
For example in Tibco EMS you use the message property
JMS_TIBCO_COMPRESS=true to enable compression.
In activemq it seems to be doMessageCompression=true in the connectio
I would just say that once you configure in the GZIP interceptors and such,
you are kind of outside the SOAP/JMS spec. By default, the GZIP stuff is
negotiated anyway. If a non-CXF SOAP/JMS client sends a message, it wouldn't
have the Accept-Transfer-Encoding thing and thus the server woul
The Apache CXF team is proud to announce the availability of the latest
patches: 2.2.12 and 2.3.1
Apache CXF is an open source services framework. CXF helps you build and
develop services using front end programming APIs, like JAX-WS and JAX-RS.
These services can speak a variety of protocols
On Tuesday 07 December 2010 2:42:54 am Christian Schneider wrote:
> Hi all,
>
> this time the build server should be back to normal but the buildutils
> 2.3.1-SNAPSHOT was not found. As 2.3.1 is out I switched to this version.
> I hope this fixes the problem. If it does not work feel free to roll
Hi Willem,
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. † [Definition: A fault MUST be generated
with subcode unsupportedJMSMessageFormat when the arriv
Thanks to all! I look forward to to further enhancing CXF's security
story over the coming months.
Colm.
On Mon, Dec 6, 2010 at 6:13 PM, Daniel Kulp wrote:
>
> With 15 +1 votes and no other votes, this vote passes.
>
> Welcome aboard Colm!
>
> Dan
>
>
>
>
> On Thursday 02 December 2010 12:01:20
Hi Freeman,
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.
If the server doesn't support the gzip encoding, CXF client can adjust
itself, as this extension is not in the spec.
Hi,
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
11 matches
Mail list logo