chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jay Brown <>
Subject Re: Returned ObjectId on check in (WS vs. AtomPub)
Date Thu, 11 Apr 2013 16:21:12 GMT

In the case of FileNet P8 these two scenarios are often the same.

For p8 when you checkin a document the PWC becomes (or gets promoted) to
the new version.
This means that the ID of the PWC and the ID of the new version are
identical.  (Not sure if inMemory also does this)

So the p8 specific rules (because of this implementation detail) is that
whatever you checkin (both bindings) you will get back an id that is the
same as the (former) PWC. It is just not a PWC anymore, but now is the
latest version.

Jay Brown
Senior Engineer, ECM Development
IBM Software Group

  From:       Tim Webster <>                                  
  Date:       04/11/2013 04:46 AM                                                        
  Subject:    Returned ObjectId on check in (WS vs. AtomPub)                             

Hi All,

I've noticed that the ObjectId returned from a check-in operation is
different depending on the binding type used.

If atompub is used, the check in operation will always return the the 'new'
objectId (i.e. the object ID of the new version that is being created by
the check in).

If webservices is used, the check in operation will always return the
objectId of the Document that is being checked in.

I've tested both scenarios using the following inputs as the document to
check in:

- v1.0 of the document
- latest major version of the document
- PWC of the document

I initially thought this might be a bug in the CMIS repository
implementation I'm using (IBM FileNet P8), as the Chemistry client code
seems to just return what is returned from the server.  However the same
behavior exists in OpenCMIS InMemory Server as well.

It would be odd if this was a bug AND showing up in two different

I couldn't see anything in the spec regarding this, so am now wondering if
I've missed something or if in fact this is a problem with the Chemistry
client somehow.

Any thoughts?



  • Unnamed multipart/related (inline, None, 0 bytes)
View raw message