All CMIS 1.1 methods should be marked with "@cmis 1.1" in the JavaDoc.
They should be easy to find.
Florian
Hi,
How about returning null in your code and setting a comment "TODO
CMIS
1.1" which you'll be able to find easily later on?
Florent
On Mon, Aug 26, 2013 at 11:42 AM,
<jorge.martin-cue...@ext.ec.europa.eu> wrote:
Good morning Florian,
Currently our goal is to implement CMIS 1.0 but in midterm we'll go
for CMIS 1.1.
If I throw an exception will be much faster to detect when we do the
jump to 1.1.
In the other hand, returning a null will rely on my memory to
remember to change this piece of code ;)
Regards.
Jorge MARTIN CUERVO
European Commission
DG TRADE
Unit A4
CHAR 02/077
B-1049 Brussels/Belgium
+32 2 298 86 27
jorge.martin-cue...@ext.ec.europa.eu
-----Original Message-----
From: Florian Müller [mailto:f...@apache.org]
Sent: Friday, August 23, 2013 5:45 PM
To: dev@chemistry.apache.org
Cc: MARTIN CUERVO Jorge (TRADE-EXT)
Subject: Re: CMIS 1.0 server is expecting CMIS 1.1 object type
feature
Hi Jorge,
Some layers above the converter we know which CMIS version is used.
For
the AtomPub binding we actually hand down that information to the
converter. The AtomPub converter skips CMIS 1.1 structures or warns
the
developer if CMIS 1.1 details are provided in a CMIS 1.0 context.
But
that is not meant to take away the responsibility from the
developer to
provide the correct data for the CMIS version of the current call.
We could have reworked the Web Services converter to do something
similar but that would have been a lot of work just for developer
convenience. There are also some edge cases where the converter
cannot
make a clear decision.
Because CMIS 1.0 is a subset of CMIS 1.1, OpenCMIS uses the same
interfaces and classes for both versions. If they are used in a
CMIS 1.0
context, all CMIS 1.1 features should return null. The developer
has to
ensure that.
Why do you want throw an exception if a CMIS 1.1 method is called?
As
long as you don't configure the CMIS 1.1 servlets, they don't do
any
harm.
- Florian
Hello all,
We are working on a CMIS repository server and we have been using
chemistry 0.8.0 for some time.
Recently we have upgraded to the latest version 0.10.0 and we have
found some unexpected behaviour.
Our goal is to comply with CMIS 1.0, so what I have made is to
throw
an exception in those parts of the code related to CMIS 1.1, eg:
In our class that implements
org.apache.chemistry.opencmis.commons.definitions.TYPEDEFINITION:
@Override
PUBLIC TypeMutability getTypeMutability() {
THROW NEW UnsupportedOperationException("getTypeMutability():
Operation not available. CMIS 1.1");
}
My surprise when I try to connect to the server and I get the
previous
exception.
In the class org.apache.chemistry.opencmis.commons.impl.WSCONVERTER
about line 980, we could see:
IF (typeDefinition.getTypeMutability() != NULL) {
TypeMutability typeMutability = typeDefinition.getTypeMutability();
At this point, I suppose you know the version of CMIS implemented
by
the server,
Is there any way to check the CMIS version before using
TypeMutability?
Regards.
JORGE MARTIN CUERVO
EUROPEAN COMMISSION
DG TRADE
Unit A4
CHAR 02/077
B-1049 Brussels/Belgium
+32 2 298 86 27
jorge.martin-cue...@ext.ec.europa.eu [1]
Links:
------
[1] mailto:jorge.martin-cue...@ext.ec.europa.eu
