Re: CXF support as web services stack in opencmis

[Florian Müller]

OpenCMIS doesn't rely on generic JAX-WS. It uses RI classes to make use 
of certain features. We have never stated that it works with other 
implementations and explicitly said that it doesn't work with CXF. We 
even have specific packages for WebSphere and WebLogic to use their 
native stacks.

The sad truth is that JAX-WS implementations behave so differently when 
it comes to attachments and streaming that we need specific code for 
each of them.

Most OpenCMIS users don't use the Web Services binding anyway and 
therefore don't have an issue. The other bindings are significantly 
faster and require fewer dependencies.

But I have to revisit the Web Services code anyway for the CMIS 1.1 
implementation. There have to be some major code changes, if we don't 
want a lot of duplicated code for CMIS 1.0 and CMIS 1.1. I will 
reevaluate CXF for this.


- Florian


On Mar 22, 2013, at 12:00 PM, Florian Müller<f...@apache.org>  wrote:

Hi Daniel,

Thanks for the clarifications. The foundation of the OpenCMIS Web Services code 
has been written in 2009. We evaluated CFX at this point and concluded that we 
have to go with RI. CXF couldn't handle attachments in the way we needed it. It 
looks like a lot has changed since then.

But even if the content is buffered in a temporary file, this is an issue - at 
least on the client side. Two real world examples:
- There are business requirements not to store any confidential documents 
unencrypted on a hard disk. A temporary file would violate this.

Actually, CXF DOES have settings to allow the temp files to be completely 
encrypted.   :-)

- A document could be a 4GB video file. Apart from the performance penalty of 
buffering it on disk, the client has to have enough free temp space.

Yea.  That's still an issue.     That said, after thinking about it, I *THINK* 
(I'd have to verify), that the last attachment is not buffered to disk, it 
remains streaming.   I don't know enough about the CMIS stuff to know if 
multiple attachments are sent or not.

True content streaming is not a nice-to-have; it's a real requirement. Storing 
the content on disks prevents Out Of Memory exceptions, but opens another can 
of worms.

Right.   Going with the implementation specific API's is certainly the most 
reliable, but the way OpenCMIS does that is not reliable.

We have seen OpenCMIS not working in CXF environments. Depending on the 
classloading, setting the javax.xml.ws.spi.Provider helps in some cases to 
coexist there. It's not a silver bullet, though.
I'm not sure auto detection helps here. As a developer I want full control and 
either I consciously flip a switch or deploy another Jar. Otherwise finding the 
cause of different behaviors becomes rather difficult. I also have to know 
which dependency Jars I have to deploy in the first place.

If you need that level of control, you CANNOT rely on the JAX-WS API's (or 
generated service objects actually).   You'd need to drop down to the 
implementations direct API's to make sure you get the appropriate 
implementation.   Otherwise, you would always be relying on things like 
classpath ordering and system properties and also opening up the possibility to 
cause other applications running in the same VM to break.   For example, within 
Karaf (OSGi), if CXF is installed first, you would ALWAYS be getting CXF.   
Your /META-INF/... stuff would not be looked at.   However, if your client 
bundle is installed first, you would break anything that require CXF (unless 
they are using CXF's API's directly or spring or blueprint, which admittedly is 
the recommend approach in OSGi).

As I already said, CXF support would be great. I had to work around a lot of RI 
quirks to make it work for all OpenCMIS scenarios. My gut feeling tells me that 
CXF is just different and still needs some extra work.

"Different" is likely the right word.

Dan


- Florian





On Mar 21, 2013, at 7:31 PM, Florian Müller<f...@apache.org>  wrote:

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.
Actually, that's not true.   The JAX-WS specification does not
dictate that.   It dictates that the entire SAAJ model must be
created, but not that attachments need to be loaded into memory.
Different JAX-WS stacks do different things with this.   I think the
RI does resolve the MTOM stuff first which does load it in memory.
For CXF, the attachments are pulled off the stream, but stored in tmp
files on disk, not in memory.    The MTOM nodes are left "as is" in
the SAAJ model.   Thus, you just get the contents of the SOAP part of
the mime multipart in memory, not the full thing.

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.
No, not true.   That said, I'd still use the proprietary API's if
just dealing with application level headers.   For the stuff Oli needs
related to SAML and security, I'd let the stack handle it the way it
needs to handle it.

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.
For CXF, we CURRENTLY would still need the full SAAJ model (but see
above about the attachments) for the SOAP part.   We're working on a
WSS4J 2.0 version that would allow streaming with WS-Security which
would resolve even that issue.   That's a bit off though.

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.
There is nothing that the RI does to mitigate this that CXF doesn't also do.

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.
Uhmm…   Another mis-conception.   If we required that, then CXF
wouldn't work very well for anyone using Maven on Java 6.   :-)

Seriously, CXF does not require anything to be endorsed unless you
need the 2.2 specific API's and such.   If only the the 2.1 API's are
found on the classpath and you only use the 2.1 API's, youi are fine.
The CXF code generator by default does generate 2.2 code (per spec
requirement).  However, we do have flags to have it generate 2.1
restricted code.    Most of our examples now set that flag so they
work "out of the box" without any sort of endorsed jars, even on
java6.

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.
I'm wondering if it would be all possible or preferable to have some
level of auto detection of which stack is being used after the "new
XYZService(…)" calls (or after the getXYZPort() calls) and handle the
various things more automatically.   Right now, if the CXF jars are on
the classpath prior to the Chemistry one, you would still end up using
CXF anyway.

Dan



- 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 [f...@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