chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Florian Müller <>
Subject Re: CXF support as web services stack in opencmis
Date Thu, 21 Mar 2013 23:31:18 GMT
Hi Oliver,

It is not about MTOM and streaming. All JAX-WS frameworks can do that 
today. It is about handling SOAP headers. The JAX-WS specification 
forces a JAX-WS implementation to load the whole message (including 
attachments) in memory when the SOAP headers should be touched. 
Therefore, the standard way of handling SOAP headers is not feasible for 
OpenCMIS. One big document can easily cause an Out Of Memory exception. 
That's not a specific problem of a specific JAX-WS implementation, but a 
JAX-WS specification problem and therefore all implementations.

All JAX-WS implementations have proprietary APIs to work around that. 
But if the CXF WS-SecurityPolicies implementation (which I don't know) 
uses the standard APIs then you probably will run into memory issues 
sooner or later. If you can handle that risk, CXF might work for you.

You are actually not the first, who wants to make CXF work. See this 
mail thread:

Making it work is not the problem. Making it work without the danger of 
a memory issue is difficult.

Another reason why CXF is not our first choice is, that its needs Jars 
in an endorsed directory. That's a deal-breaker for many projects that 
want to use OpenCMIS. Today, OpenCMIS requires Oracles JAX-WS RI 2.1.7. 
This is not the latest version of JAX-WS RI for the same reason. JAX-WS 
RI 2.2.x also needs Jars in an endorsed directory.

I don't want to stop you from making it work. Having CXF support would 
be great for OpenCMIS. So, please go ahead and provide a patch. But I 
don't see that CXF will become our preferred stack in the future.

- Florian

> Hi Florian
> Thanks for the feedback. CXF supports MTOM and streaming out-of-the-box without any implementation
specific dependencies. I think it should by quite easy to integrate CXF as a web services
stack in chemistry. The security part is then enforced by WS-SecurityPolicies without a lot
of API usage.
> I'll give it a try. Would you look into this if I raise a JIRA and apply a patch including
unit testing?
> Are there non resolvable issues do improve performance for the Web Services Binding?
> Thanks
> Oli
> ------
> Oliver Wulff
> Blog:
> ________________________________________
> From: Florian Müller []
> Sent: 21 March 2013 12:38
> To:
> Cc: Oliver Wulff
> Subject: Re: CXF support as web services stack in opencmis
>   Hi Oliver,
>   There is no active development around CXF support at the moment (see
>   [1] why).
>   But what you want is a custom authentication provider [2]. The easiest
>   way to build one is to copy the standard authentication provider code
>   [3] and modify it. We (SAP) have implemented SAML support for our
>   infrastructure. So that's doable. WS-Trust STS might be trickier, but
>   certainly possible.
>   Apart from that, you might want to consider using a different binding.
>   The Web Services binding is pretty slow compared to the other two
>   bindings.
>   - Florian
>   [1]
>   [2]
>   [3]
>> Hi there
>> I'm looking into the usage of opencmis to interact with a CMS system.
>> This worked fine with basic security. Currently, username/password is
>> supported with HTTP Basic Authentication or WS-Security
>> UsernameToken.
>> In our case, the CMIS client is deployed in a web application which
>> must sent requests on behalf of the web application user. So far, we
>> used SAML and the WS-Trust STS which is supported by Apache CXF.
>> I've spotted the following class CXFPortProvider but it is not
>> active. Is there any other work ongoing in supporting CXF and any
>> other WS-Security tokens?
>> Thanks
>> Oli

View raw message