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
