chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: CXF support as web services stack in opencmis
Date Fri, 22 Mar 2013 13:31:24 GMT

On Mar 21, 2013, at 7:31 PM, Florian Müller <> 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

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:
> 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.


> - 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:
>> ________________________________________
>> From: Florian Müller []
>> Sent: 21 March 2013 12:38
>> To:
>> 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]
>>  [2]
>>  [3]
>>> 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

Daniel Kulp -
Talend Community Coder -

View raw message