chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Florent Guillaume ...@nuxeo.com>
Subject Re: CMIS 1.0 server is expecting CMIS 1.1 object type feature
Date Mon, 26 Aug 2013 09:56:54 GMT
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-CUERVO@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-cuervo@ext.ec.europa.eu
>
> -----Original Message-----
> From: Florian Müller [mailto:fmui@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-cuervo@ext.ec.europa.eu [1]
>>
>>
>>
>> Links:
>> ------
>> [1] mailto:jorge.martin-cuervo@ext.ec.europa.eu
>



-- 
Florent Guillaume, Director of R&D, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
http://www.nuxeo.com   http://www.nuxeo.org   +33 1 40 33 79 87

Mime
View raw message