Hi Vyacheslav,
You can get all parameters (CMIS and non-CMIS) like this:
CallContext context = getCallContext();
HttpServletRequest request = (HttpServletRequest)
context.get(CallContext.HTTP_SERVLET_REQUEST);
Map<String, String[]> parameters = (Map<String, String[]>)
request.getParameterMap();
This works with HTTP GET, POST, PUT, and DELETE.
- Florian
Hi Florian,
Thanks for pointing to example with TypeDefinition. I was looking hard
at "extension" parameter for binding methods and completely missed
that TypeDefinition interface and others extend ExtensionsData. That
solves my issues for many create/update scenarios. You also mentioned
extension mechanism for Browser and AtomPub bindings. Can you point to
any class/method/example for me to start looking at? Does such
mechanism work for HTTP GETs or only PUTs and POSTs? We currently
handle custom HTTP headers in CallContextHandler and
AuthenticationFilter but as you mentioned it is a bit awkward.
Regards,
Vyacheslav Pascarel
-----Original Message-----
From: Florian Müller [mailto:f...@apache.org]
Sent: Friday, July 22, 2016 12:42 PM
To: dev@chemistry.apache.org
Cc: Vyacheslav Pascarel <vpasc...@opentext.com>
Subject: Re: How to pass "extension data" for different bindings?
Hi Vyacheslav,
Your example is actually the exception. When you create a type you can
add extension data to almost every levels of the type definition and
it will be transferred to the server. That is supported by all
bindings.
But this has nothing to do extensions you find in the method
signatures.
The ExtensionData is only defined and only works for the Web Services
binding. The AtomPub binding and the Browser binding rely on the Atom
and HTTP extension mechanisms. For example, to create a folder with
the Browser Binding the client sends URL encoded form data. The CMIS
spec allows to add extra data (key-value pairs) to it. So,
protocol-wise that is supported.
You can extract this extra data with the OpenCMIS server framework.
There is no obvious method, but it is possible.
On the OpenCMIS client side we don't have support for this. (We don't
have real support for ExtensionData, either). There weren't many
requests in the past to implement something like this.
If you have a good idea how to add this without polluting the
interfaces (for example duplicating all methods), let us know.
If you have the same data, that you want to send with all requests,
have a look the authentication provider. It allows you to set HTTP
headers.
Not an elegant way, but it works with all bindings.
- Florian
Hi everyone,
I am trying to use pass some additional non-CMIS data from client to
server. For example, in case of creating a new type in the target ECM,
simple CMIS type definition may not be sufficient to pass all the
data. I was looking at using ExtensionsData since it is coming as an
input in almost every method on server side. But it seems that passing
ExtensionData is only supported by Web Services binding. The source
code on client for sending and on server for receiving does not do
anything for extension data. Sending extension data from server to
client seems to be supported by all bindings.
So my question: Is there a way to pass "extension data" without
resorting to Web Services binding?
I understand HTTP GET for Browser and AtomPub applies some
restrictions on sending data, but HTTP POST and PUT could include such
data. PUT & GET would suffice for a lot of scenarios while GET could
return extension data all the time if needed.
Regards,
Vyacheslav Pascarel
