Hi Florian
I understand what you mean. Dealing with soap headers for instance in
JAX-WS handlers requires a dom model representation of the message
(SAAJ) which is an issue with large messages.
I haven't implemented the WS-SecurityPolicies part but as far as I
remember, the DOM representation is built for the soap headers only.
CXF specific interceptors handle then adding the soap headers. That
should be fine.
CXF only requires the JAX-WS 2.2 and JAXB 2.2 libraries in the
endorsed directory if you want to use the new APIs of JAX-WS 2.2 [1]
which doesn't seem to be the case.
I'm a little bit worried about Ashish's statements about a potential
bug in JAX-WS RI. Is this confirmed?
*"**Also, note the wrapper style is not always available, the WSDL
criteria specified in Section 2.3.1.2 ("Wrapper Style") of the
specification must be met or only non-wrapper style will be
generated.**"*
JAX-WS RI has a bug, as in - it does not strictly follow Section
2.3.1.2
("Wrapper Style") of the specification, and hence generates the
query
method differently.
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.
Fine with me. It would be great to have a pluggability option for web
services stack implementations (and propably JAX-RS/AtomPub which is
supported by CXF as well) as customers might have made strategic
decisions on an implementation.
Just thinking out load, if we had such kind of adaption options in
OpenCMIS, it might make sense to have different libraries/bundles for
OSGi compatibilty. Right now, the osgi bundle seems to support JAX-WS
RI only.
Thanks
Oli
[1] http://cxf.apache.org/docs/23-migration-guide.html
________________________________________
From: Florian Müller [[email protected]]
Sent: 22 March 2013 00:31
To: Oliver Wulff
Cc: [email protected]
Subject: Re: CXF support as web services stack in opencmis
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
