chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Wulff <owu...@talend.com>
Subject RE: CXF support as web services stack in opencmis
Date Fri, 22 Mar 2013 06:31:51 GMT
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 [fmui@apache.org]
Sent: 22 March 2013 00:31
To: Oliver Wulff
Cc: dev@chemistry.apache.org
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 [fmui@apache.org]
> Sent: 21 March 2013 12:38
> To: dev@chemistry.apache.org
> 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
Mime
View raw message