chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Florian Müller <f...@apache.org>
Subject RE: CXF support as web services stack in opencmis
Date Fri, 22 Mar 2013 09:38:34 GMT
 Hi Oliver,

 We already have packages for WebSphere and WebLogic that use the native 
 JAX-WS stacks of these application servers. I can imagine another 
 package for CXF (and a matching OSGi bundle) for OpenCMIS.
 I haven't looked into the potential JAX-WS RI bug. But that should be 
 solvable with an extra CXF package.

 The AtomPub code doesn't use JAX-RS. The next release will even remove 
 the dependency on JAXB. All it requires is a StAX parser now.


 Thanks,

 Florian



> 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