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
