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