Cannot retrieve content using the Java API

I have created a page, and found the page using

Content content = contentService.find(expandAll()).withId(id).fetch().get();

where id is the ContentId and expandAll() returns an array of all Content.Expansions. I am not concerned about performance because I am only finding one content, and I know the content exists because I am the one who created it. Just to get that out of the way.

So, I have three problems that are almost certainly related, and I simply cannot get around. First, content.getBody() returns an empty Map. It is not supposed to be empty, because there is content. Second, when I try to pass in a new ContentBody, ‘ContentService.update()’ throws an IllegalStateException “Request-local WebResourceAssembler has already been initialised”. And third, even when I simply omit the body altogether so that the update succeeds, when I visit the page it tells me there are unpublished changes.

Long story short - why is it so hard to update content using the ContentService ???

Addendum #1 - The REST API helped me past the first issue. It is not enough to expand “body”. You must actually expand “”.

Addendum #1A - Apparently, “” only works for the REST API. ContentService is still returning an empty Map.

So I have a question for the Atlassian developers

WHY did you mark the find methods deprecated, when the new methods do not return the same object as the original methods?

Are there ANY plans to document this new API, other than with javadoc?

Under the hood the REST API uses the ContentService

Have you tried with the following syntax ?

 return contentService.find(ExpansionsParser.parse("")).withId(ContentId.of(contentId)).fetch()
                .map(content -> Response.ok(content).build())
                .orElseThrow(notFound("content not found for id : " + contentId));

Now onto your questions:

WHY did you mark the find methods deprecated, when the new methods do not return the same object as the original methods?

I suspect you are talking about PageManager#get, CommentManager#get ... methods right ?
Those indeed do not return the same objects as the ContentService.
The purpose of that was to decouple our API layer from the data layer and abstract away the concept of Content, and also apply the permission checks by default so app developers won’t have to bother with that when accessing content through the API.

As far as plans to document our APIs other than with javadoc , we have set up this plugin here Bitbucket to showcase some of the API usages , the team should be adding more examples when time permits.

Hasnae (former Confluence person)

1 Like