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:
http://mail-archives.apache.org/mod_mbox/chemistry-dev/201208.mbox/%3C503E653C.9050903%40apache.org%3E
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: http://owulff.blogspot.com
________________________________________
From: Florian Müller [[email protected]]
Sent: 21 March 2013 12:38
To: [email protected]
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]
http://mail-archives.apache.org/mod_mbox/chemistry-dev/201206.mbox/%3C4FDF8B71.9020108%40apache.org%3E
[2]
http://chemistry.apache.org/java/developing/client/dev-client-bindings.html#OpenCMISClientBindings-CustomAuthenticationProvider
[3]
https://svn.apache.org/repos/asf/chemistry/opencmis/trunk/chemistry-opencmis-client/chemistry-opencmis-client-bindings/src/main/java/org/apache/chemistry/opencmis/client/bindings/spi/StandardAuthenticationProvider.java
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
