Update - the problem I was having was against FileNet P8. I tried the same code against Alfresco 4.2f, and I also got strange behaviour (although different).
With Alfresco, if you explicitly set the mime type when you add the document, the mime type gets set OK, but the content is doesn't seem to be present (length of 0 in workbench). Also with Alfresco, if you set the mime type to 'application/octet-stream' it seems to override this with the actual correct mime type, and import the document successfully (content and all). So I'm a bit confused as to how all this is supposed to work. Should we not be setting the mime type ourselves? Why do the repository implementations seem to want to interfere with this? Again, this is mostly using a 'old' Word format document (.doc) and the application/msword mime type, of which our customers repositories are full of. Tim On Fri, Aug 29, 2014 at 5:09 PM, Tim Webster <tim.webs...@gmail.com> wrote: > Hi, > > I'm deriving the mime type of documents (using Apache Tika) and then > adding them to my CMIS repository using a Chemistry Java client. For some > reason, certain mime types seem to prevent the content from being added. > > The document gets added, but the mime type and content are empty. > > The biggest offender seems to be application/msword, and there seem to be > others. > > I've used the same code for the past couple of years to do this, and the > only thing I've changed is the value of the mime type in the ContentStream. > Previously, I used to just set everything to 'application/octet-stream'. > If I switch back to that, it works fine. The Tika libraries are doing > their job just fine, and returning the correct mime type. > > If I add the same document through the workbench, the document gets added, > and the mime type and content are totally fine. > > I've attached a screenshot of my CMIS workbench so you can see the effect. > > Anyone have any ideas? > > [image: Inline image 1] >
